도서특징

소프트웨어 구현에 대한 실무서! Software Development 잡지의 Jolt Award 두 번 수상에 빛나는 책! 프 로그래밍에 대한 최고의 실무적인 지침서로 널리 알려진 스티브 맥코넬의 Code Complete 제 1판은, 10년이 넘는 기간 동안 개발자들이 더 나은 소프트웨어를 만드는 데 도움을 주었다. 이제 이 고전적인 책은 소프트웨어 구현에 대한 예술과 과학을 설명하기 위해서 최신의 기법들과 수백 개의 새로운 예제 코드가 포함되어 개정되었다. 연구와 학계, 그리고 상업적인 기법들에 있는 지식들을 바탕으로, 맥코넬은 가장 효율적인 기법과 반드시 알아야 하는 원칙들을 이 실용적인 지침서에서 종합적으로 다루었다. 이 책은 여러분의 실무 경험이나 개발 환경, 또는 프로젝트의 크기에 상관없이 도움이 되는 정보를 제공하고 여러분의 사고를 자극함으로써 가장 품질이 뛰어난 코드를 작성하는 데 도움을 줄 것이다. Code Complete 제 1판도 매우 훌륭한 소프트웨어 공학 서적이었지만, 제 2판은 그보다 더 훌륭하다. - Ralph Johnson, 일리노이 대학, Design Patterns 공동 집필자 "초보 개발자나 숙련된 개발자 모두에게 Code Complete 제 2판은 프로그래밍에 대해서 생각할 수 있는 최고의 방법을 가르쳐준다." - Jeffrey Richter(www.wintellect.com), Applied Microsoft .NET Framework Programming 저자 "소프트웨어 구현에 관한 최고의 지침서 - 프로그래머가 무인도에 갈 때 반드시 가져가야 할 책" - Diomidis Spinellis, Code Reading: The Open Source Perspective 저자 "스티브 맥코넬은 최신 기술을 수행하고 계몽할 수 있는 몇 안 되는 전문가 중 한 명이다." - John Vlissides, IBM Research, Design Patterns 공동 저자 "스티브 맥코넬은 어느 누구보다도 소프트웨어 구축에 대해서 잘 알고 있다. 그런 그가 그의 모든 통찰력과 실무에서의 경험을 이 한 권의 책에 담았다는 것이 우리에게는 행운이다." - Alan Cooper, “비주얼 베이직의 아버지”, About Face 공동 저자 【 이 책의 내용 】 복잡성은 최소화하고, 창조성은 최대화할 수 있도록 설계한다. 협력 개발의 이점을 얻는다. 오류를 줄이고 찾아내기 위해서 방어적인 프로그래밍 기법들을 적용한다. 리팩토링 가능한 코드를 만들고 안전하게 수행한다. 프로젝트에 맞는 구현 습관들을 사용한다. 문제를 빠르고 효율적으로 디버깅한다. 치명적인 구현 상의 문제점을 초기에 정확하게 해결한다. 프로젝트의 시작 단계, 중간 단계, 그리고 마무리 단계에서 품질을 고려한다.

저자소개

Steve McConnell은 개발 분야에 있어서 가장 뛰어난 저자이자 대변인 중 한 명으로 인정받고 있다. 그는 Construx Software의 수석 소프트웨어 엔지니어이며, Software Development 잡지의 Jolt Award를 수상한 Code Complete과 Rapid Development, 그리고 Software Project Survival Guide와 Professional Software Development의 저자이다. 【 저자·역자 Prolog 】 처 음 Code Complete 제2판의 번역을 맡게 되었을 때, 이렇게 유명하고 잘 정리된 책을 어떻게 우리 글로 작성할 것인지에 대해서 굉장히 큰 부담감을 느꼈지만, 책을 정독해 나가면서 우리 글로 바꾸는 것도 의미 있는 작업이겠다는 확신을 가질 수 있었다. 여 러분은 이 책이 초보자를 위한 책이라고 생각하는가? 역자는 전혀 그렇게 생각하지 않는다. 물론, 초보자들에게도 유익한 내용들을 많이 다루고 있지만, 이 책을 통해서 얻을 수 있는 것들은 초보자보다는 중급 이상의 프로그래머들일 것이라고 확신하고 있다. 가끔 이 책의 제1판을 보고 너무 쉬운 내용을 다루고 있다거나 기술적인 내용들을 깊이 있게 다루고 있지 않다는 표면적인 이유를 들어 이 책의 수준을 폄하하는 사람들을 보게 된다. 물론, 이 책은 기술 서적이 아니다. 그렇다고 다분히 이론적인 부분만을 강조하고 있는 책도 아니다. 이 책은 실무 프로그래머에게 도움이 될 수 있는 이론적인 내용들을 실무적인 내용에 맞게 맥코넬의 언어로 쓰여진 것이다. 그가 말했듯이, 우리가 실무에서 행하고 있는 여러 가지 습관들에 관한 내용들은 전 세계의 학자들이나 숙련된 프로그래머들에 의해서 정리된 것들이 대부분이다. 우리에게 주어진 선택권은 그러한 자료들을 일일이 찾아보면서 어떤 것들이 자신의 환경에 맞는지 확인해 보는 수고를 하거나, 그러한 자료들을 일목요연하게 정리한 이 책을 보는 방법이 있다. 여러분은 어떤 방법을 선택할 것인가? 이 책을 번역하면서 가장 어려웠던 부분은 (모든 외국 서적들이 그렇듯이) 저자의 문화를 이해하는 것이었다. 사실 번역본이 주어나 동사를 우리 글로 바꾸는 수준이라면 어느 누구도 번역본을 사려고 하지 않을 것이다. 역자의 가장 큰 의무는, 저자의 문화를 우리의 문화로 바꾸어 독자들의 이해를 돕는 것이라고 생각한다. 따라서 번역을 진행하면서 다소 이해하기 어렵다고 생각된 부분들에는 '역자 주'를 제공하여 이해를 도왔으며, 때로는 우리가 쉽게 이해할 수 있는 문장으로 대체하기도 하였다. 역자는 언제나 AS 정책을 가장 중요하게 생각한다. 이 책이 출판되더라도 언제나 AS 정신으로 독자들에게 봉사할 준비가 되어 있다. 따라서 어색한 번역이 있거나 내용에 문제가 있다고 생각되는 부분들이 있다면, 언제든지 역자의 메일로 보내주기 바란다. 역자 서우석

독자서평

기본을 다지는데 많은 도움을 주는 책..

- 오광섭님, 2008-03-08 작성    오광섭님의 모든서평 I 블로그

94년도에 출간되어 10년이 넘도록 많은 감동을 주었던 첫번째 에디션이 내용이 보강되고 시대에 맞도록 수정되어 2004년도에 10년만에 새로 출간되었다.. 아마 10주년 기념으로 개정판을 기획한 것 같다.. 책은 나오자 마자 구입을 했고 번역본은 1년후에 국내에 출간되었지만, 이제서야 책을 집어들고 읽어보고 있다.. 역시 책은 사두기만 해서는 도움이 안된다.. 속독이라도 한번은 읽어줘야 제값을 발휘하지..   사 실 원작이 워낙에 좋아 개정판이 시대의 흐름에 맞춰 나왔다고는 하나 소스코드 샘플이 자바로 바뀐 정도, 내용도 크게 바뀌지 않았다고 이야기 할 수 있을지도 모른다.. 안정된 소프트웨어를 만들기 위해 설계, 구현, 테스트 하는 전반에 걸친 내용이 10년이 지났다고 해서 크게 바뀌지는 않았을 것 같다는 생각도 들기도 하고.. 하지만, 큰 틀이 바뀌지 않았다는 것이지 많은 패러다임의 변화가 있었으므로 개정판이 갖는 의미는 크다고 할 수 있다.. 물론, 개정판을 끝까지 다 읽어봐야 확실히 말할 수 있겠지만..   Steve McConnell의 수많은 명저들 중에서 프로그래머들에게 실질적으로 가장 도움이 되는 책이 바로 이 책이다.. 초급자 뿐만 아니라 중급 이상의 프로그래머들도 이 책을 통해 더 현명한 프로그래머들의 습관이나 사고방식을 전수 받을 수 있다.. 알고보면 뻔한 이야기인 것 같아도, 시행착오를 거치며 알아내야 하는 것들이 꽤 되지 않는가..   개정판으로 나오면서 내용도 훨씬 더 요약 및 정리가 잘 되어 책도 좀 더 얇아진 것 같다.. 프로그래밍 완전정복 이라는 좀 우스운 제목으로 소개된 국내 번역서는 그 두께가 얼마나 두껍던지 읽어보기도 부담 스럽던데 비하면 훨씬 좋다..   프 로그래머들이라면 꼭 한번 읽어볼만한 책이다.. 개정판이 나왔으니 굳이 두번 읽을 필요 없이 개정판을 읽는 것이 더 좋겠지.. 원서를 구입해서 번역서를 읽어보지는 못했으나 요즘 번역서들의 질을 보면 염려할 필요는 없을 것이다.. (불과 몇년전만 해도 번역서 사기가 겁나던 시절이 있었다.. 대표적으로 날아라 삼각형~ 휴지통으로~)

어떤 책인지 궁금해서

- 정재열님, 2007-04-26 작성    정재열님의 모든서평 I 블로그

개발자라면 한번쯤 읽어야한다고 해서 사보고 있는데..   짜투리 시간에 간혹 보고 있긴한데 분량 탓인지 전부 보기 앉아있기엔 제가 게을러서   힘들거 같아서 필요한 부분만 보고 있어요..   내용은 괜찮은거 같네요..    저처럼 생각없이 코딩하는 초짜에 개발에 깊이를 모르는 사람은 지루한 부분도   있다는거..  ^^*   두고두고 봐야할듯한데 잘 안 봐질듯한.....

재미있네요

- 허재호님, 2007-03-26 작성    허재호님의 모든서평 I 블로그

개발자로서 갖춰야 할 개념들과 구조적 지식들을   저자 자신이 초반부에 설명한 것처럼 비유를 통해서 꽤 재미있게 쓴 책입니다.   물론, 부분에 따라서는 딱딱한 부분도 있지만...   그동안 문득문득 떠오르던 여러가지 궁금증들을 해결할 수 있었고,   쉽사리 넘어갔던 나만의 고질적인 부분도 많이 발견할 수 있었던 기회가 되었다고 생각합니다.

참고로... 말하지만...

- 허승호님, 2007-02-06 작성    허승호님의 모든서평 I 블로그

게으른 개발자 - 내가 초급자라면 -> 괜찮은데 책 내용이 너무 쓸데없이 길어~ 뎅장 내가 초중급자 라면 -> 어디서 많이 본거 같은데 내가 중급자 라면 -> 알고는 잇는데 왜 내가 하지 않고 있지?   < 현재의 나 내가 중고급자 라면 -> 이걸로 밥먹고 살기 힘들군 내가 고급자 라면 -> 책 바꿀까? 근데 이거 어디서 어디서 빼꼇지?    본천(본인이 천재라고 생각하는) 개발자 - 내가 초급자라면 -> 아주 좋아 근데 이 내용을 내가 다 기억할까? 내가 초중급자 라면 -> 필요한 것만 보자 내가 중급자 라면 -> 난 항상 이런 패턴으로 일하고 있잖아 내가 중고급자 라면 -> (하루만에 대충보고...)누구에게 팔까? 내가 중고급자 라면 -> 빌게이츠도 이책 봤을까?     헉! 책 가격 내려갔다.. 내가 다른 사이트서 이책 샀나?   쓸데없는 내용만 적어서 ㅎㅎ   책 내용 좋아요~ 볼만하고 괜찮아요~ 초급자가 봐도 무난하고 새록새록 머리속으로 들어오는거 같아요 ㅎㅎ~

기본이되는 책

- 최영진님, 2006-11-17 작성    최영진님의 모든서평 I 블로그

프로그래머중에 이책이 없는 사람이 별로 없는 책인듯

개인 개발 습관 및 개발 방법론 모두에 통용되는 바이블

- 김익주님, 2006-10-10 작성    김익주님의 모든서평 I 블로그

책을 보면 책 출판지를 보면 Microsoft 라고 되어 있음을 알수 있다. 그동안 MS 책을 많이 보아온 터라 좀 관료적인(?) 책이지 않을까 싶었다.   책을 받아 본 순간 분량이 장난 아닌 수준 ^^   하지만 책장을 펼치고 목차를 본 순간. 개발에 필요한 내용들이 처음부터 끝까지 전반적인 내용에 대해서 모두 포괄하는 것을 보고 책 분량이 그리 크지 않다는 생각을 하게되었다.   사실 이 책을 모두 정독을 하고 개발을 하라고 추천하고 싶지는 않다. 너무 방대한 내용과 분량때문이다. 하지만 옆에 꼭 놔 두고 개발하는데 있어서 궁굼한점들이 있는 사람들은 이 책을 열어 목차를 보면 모든 문제가 해결될 것이라고 나는 생각한다.   물론 특정 세부적인 기술적 문제에 대한 해답을 주지는 않는다. 개발론과 개발 습관 등에 걸쳐 어느 정도 규모가 되는 프로젝트를 한다면 꼭 필요하다.   정말 괜찮은 책으로 개인마다 한 권씩 있으면 좋은 책이며, 부담된다면 프로젝트를 하는 팀에서는 반듯이 한 권씩을 가지고 일을 하라고 강력히 추천하고픈 책이다.

1판과 그리 다르지는...

- 박정진님, 2006-09-16 작성    박정진님의 모든서평 I 블로그

2002년 월드컵 시즌에 1판을 선배의 권유로 10일에 걸쳐 읽은 기억이 난다. (책을 빨리 읽는 편이기에 이 책은 무척 오래동안 읽은 편에 속해 기억하고 있다. - 두께가 만만찮았다-_-)   어찌보면 베개로 쓰일만한 두께에 오직 코드에 대한 내용만 꽉꽉 차있다. (설계나 분석하고는 전혀 상관없다고 저자는 밝히지만 후에 풍선효과-_-로 많은 도움이 되는 책이다. )   McConnell의 책은 전체적으로 균형점을 잘 찾는다는 느낌이 있다.(궁합이 잘 맞는지도-_-) McConnell의 책중 첫번째로 읽은 책이었고 감동받아 다른 모든 McConnell을 읽게 만든 책이기도 하다. (그리고 다른 책들도 모두 훌륭했다. 그 자기 회사 자랑하는 책(?)은 좀 그랬지만-_-)   그 러나 책이 쓰여진 시기가 시기니 만큼 종종 지금과는 어울리지 않는다거나(물론 저자는 나름대로 원칙을 말하는게 아니라 권장을 하고 있다.) 이런것까지 굳이 신경쓸 필요 없잖아-_- 라고 생각되는 항목이 있긴 하지만 두께에 걸맞을 저자의 많은 경험과 지식이 들어있다.   2판이 나오자 마자 읽었는데.. 2판과 1판은 많이 바꼈다고 하지만 그리 바뀐 내용은 많지 않은 듯 하다..   어쨋거나 다른 사람들이 자주 칭찬하는 책이라 ... -_)

이 책은 95%의 완성도를 가지고 있다.

- 임은천님, 2006-06-02 작성    임은천님의 모든서평 I 블로그

이 책에 대한 정보를 얻게 된 건 okjsp.pe.kr이라는 곳을 통해서 였다. 허광남 님께서 프로그래머라면 꼭 한 번쯤은 읽어 봐야 하는 내용이라고 하셨는데, 이제서야 읽어 보게 되었다.   이 책을 읽는데는 비록 7일이라는 긴 시간이 걸렸지만, 이 책을 다른 책처럼 빠르게 읽지 않고, 내용을 곱씹으면서 천천히 읽었던 것은 내가 개발자로써 살아갈 것이고, 앞으로 아키텍트가 될 것이기 때문이었다.   주 요 내용의 초점이 [[  구  현  ]]에 집중되어 있다. 그래서 이 책의 제목이 Code Complete 인 것이다. 이전 판을 보지는 않았지만, 이 책의 내용으로 봐서는 이 전 책도 상당한 두께와 상당한 완성도를 가지고 있을 거라고 생각이 된다.   실질적인 개발 프로세스를 따라서 개발자로써 프로젝트를 바라보는 관점을 제공해 줄 뿐 아니라, 중급 개발자를 고급 개발자로 이끌 수 있는 엄청 나게 많은 정신적이고 물질적인 측면의 도움을 준다.   초 반부는 아키텍쳐 단계부터 글의 내용이 시작이 되기 때문에 이 책 전에 읽었던 TDD의 구현 방식과는 정반대의 이야기가 나오기 때문에 약간은 거부반응을 느꼈다. 혹여나 오탈자가 있을까 주의깊게 보았으나, 이 책의 역자분께서 너무나도 열심히 주석을 달아주셨을 뿐만 아니라, 거의 잘못된 해석도 없어서 무척 만족스러운 책이었다.   초반부에 거부반응을 느낀 건 Kent Beck이라는 이름이 자주 나오며, 이 책의 저자가 약간은 Kent Beck에서 비판적인 생각을 가지고 있기 때문이라고 생각이 된다. 그래서 불만을 가지기도 했지만, 전체적으로 개발 프로세스에 대해서 다루고 있는 이만한 책이 없을 뿐더러, 이 책에서 다루고 있는 각각의 프로세스 별 IEEE 표준이라거나 참고 자료는 엄청나게 많은 도움이 될 수 있다는 생각이 든다.   다 만, 이 책의 저자도 사람이기 때문에 예제의 많은 부분이 Visual Basic로 되어 있다는 점과 Visual Basic을 상당히 감싸고, C#을 감싼다는 느낌이 간혹 들긴 하지만.. 전반적으로 개발자로써 필요한 부분들을 다양한 관점에서 바라보고 있고, 또한 다양한 기사와 책에 대한 참고, 그리고 잠깐씩 나오는 개발자들의 한 마디의 말들(격언처럼)을 읽다 보면, [구현]에 대해서 정말 많은 것을 생각하도록 해준다.   각종 논문이나 조사들로 부터 얻은 참고 자료라던가, 각각의 컴파일러의 성능 분석을 위해서 거의 억 대에 가까운 테스트를 한 점 등은 저자가 이 책에 얼마나 공을 들였는지를 깨닫게 해준다.(아마도 저자는 마이크로소프트의 수석 아키텍트 정도 될 것 같다.)   간혹 부하 직원이 이런 식으로 코드를 작성하면 자른다(?) 라는 식의 이야기를 하기도 하지만, 전반적으로 하나라도 더 알려 주고 싶어서 이런 저런 이야기를 많이 했다는 생각이 든다.   하 향식 설계 방식과 상향식 설계 방식에 대해서 좀 더 자세하게 깨달을 수 있었으며, PPP에 대해 알게 된 것은 크나큰 소득이었다고 보인다. 물론 세부 검토니 다양한 단계의 테스트 등에 대해서는 책의 앞 뒤가 상반된 내용을 약간 담고 있을 수 밖에 없는데   저자의 말처럼 "공학은 이런 프로세스의 단계를 조율하는 것"이라는 것에 동의한다.   이전에 읽었던 TDD에서의 프로세스에 장점이 있긴 하겠지만, 저자가 말하는 프로세스에 대한 생각은 좀 더 높은 수준이었고, 각 각의 프로젝트마다 맞는 프로세스가 있을 거라는 생각을 하게 되었다. 저자가 수행하는 프로젝트가 거대한 프로젝트일 경우가 많을 것이기 때문에 하향식 설계 방식과 저자의 수행 방식에는 약간의 차이가 있을 거라고 생각된다.   그 외의 모델에 대해서도(T형이니 하이브리드형) 설명을 빼놓지는 않았다. 개발자 뿐만 아니라 경영에 관심 있으신 분들도 꼭 읽어 봐야 하며, 관리자라면 정말 꼭 읽어 봐야 하는 책이 아닌가 싶다.   이 책을 읽기 전까지 개발자의 인성이나 성격, 지식, 인내, 끈기 등의 특성들에 대해서는 생각해 보지 않았으나, 어떤 환경에서 더 좋은 개발 생산성이 나타나며, 또 어떻게 해야지 더 뛰어난 개발자, 관리자가 될 수 있는 지 이 책 한 권에서 얻을 수 있다고 감히 장담해 본다.   물론 약간 두꺼운 책이기 때문에 읽기 꺼려질 수도 있으나, 개발에 대한 전반적인 프로세스와 현재 나의 위치를 파악해 보고, 앞으로 어떤 방향으로 공부할 것이며, 개발자로써 살아갈 것인지 생각하도록 해주는 책이므로 아직 안 읽어 봤다면 꼭 읽어 보길 바란다.   이 책에 대해서 몇 가지 비판을 할 수 있는 점은   1. 전체 언어에 적용되는 이야기처럼 말을 하고 있으나 다른 언어에서는 적용이 안되는 예제이거나 개념일 수 있다는 점 2. 약간&nbspMS를 두둔하며, 저자가 추진했던 MS의 큼직한 프로젝트들의 경험은 일반적인 객체 지향 프로그래밍과 안 맞을 수 있다는 점   정도 밖에 없을 듯 하다.

복음서와 같은책

- 조종호님, 2006-04-21 작성    조종호님의 모든서평 I 블로그

맨처음 책을 보시면 방대한 분량에 혀를 내두르실 겁니다.   이책은 무작정 읽어서는 수면제가 되기 일수입니다.   일단 몇개 쉬운 단원, 혹은 평소 관심이 많았던 분야에 대한 단원을 읽으시면서 이책을 보는 방법을 습득하셔야 합니다. 이후, 재미 없지만 봐둬야 할것같은 단원을 보시고, 별로 보고 싶지 않은(그러면서도 어려운) 단원은 이전까지 습득한 코드컴플리트 읽는방법을 토대로 읽으시면 되실듯 합니다.   워낙 수많은 소프트웨어 방법론들이 나와서 그냥 책읽듯이 하시면 저자가 무슨말을 하고싶은건가?하는 의문이 들수도 있습니다.   방법론에는 단순히 소프트웨어구현에 대한 방법뿐만이 아니라 일정수립, 위험요소 관리, 팀 협력방법등 소프트웨어 개발에 대한 포괄적인 방법이 설명되어 있습니다.   맥 코넬의 코드컴프릿은 그의 또다른 유명한 저서들 ("professional 소프트웨어 개발" 등등)과는 달리 그의 철학에 맞지않는 개발방법들에 대해서도 꼼꼼히 설명함으로써 소프트웨어 개발 전반적인 방법들을 전파하고, 프로그래머들 각자의 철학에 맞게 습득하도록 도와줍니다.   실용주의 프로그래머와 함께 항상 곁에 둬야할 책이라고 생각합니다.

무게가 있는 책

- 김희환님, 2006-02-10 작성    김희환님의 모든서평 I 블로그

무게가 있는 책이 아닐까 하네요..   뚜꺼워서 무겁고기도 하지만.. 내용적인 부분에서도 무게를 담고 있다고 할 수 있죠..   초보가 보기에는 좀 난해하고 어려운 개념이라고 할 수 있고요..   어느정도 프로그램을 접해보시고.. 설계와 디버깅의 중요성을 느끼시는 분들께 .. 추천하는 책이라고 할 수 있겠죠..   책의 내용이 너무 방대하여.. 솔직히 책을 드는 순간 아니 멀리서 보는 순간부터.. 압박이 느껴지는데..   실무 경험이 있으신 분들은 필요한 부분을 볼 수 있도록.. 구성은 되있다고 할 수 있고요.. 초보 경험자들은 처음부터.. 천천히 단계단계 읽는게 좋을 듯 하네요.   전 초보라서 단계단계 읽기는 하는데.. 솔직히 다른 책 보고 뭐 공부하다 보니.. 많이는 못 보았구요..   책의 내용적인 부분을 이해하는데 조금 애를 먹기는 하지만.. 생각과 발상의 전환을 불러 일으키고 있다고 생각합니다...

강력한 포스가 느껴지는책.

- 양이호님, 2005-09-06 작성    양이호님의 모든서평 I 블로그

처음 받아보고 느낌 감정은 우와~~ 대단하다이다..   거의 모든내용이 총망라 되어있다고 해도 과언이 아닌책인것이다.   이책의 체크리스트라던지 최소한 이해를 하고 있다고 한다면   당신의 직장내에서의 가치는 더욱더 상승하게 되는 책일것이다.   지금 시기상으로 이책이 나온걸 정말 감사히 생가한다..   수시로 읽어보면 좋은 책일듯싶다...   아직 보지도 못했지만 처음 느낌이 너무 강렬해서 한마디 적었다. PS..... 본이 아니게 거의 반말체인데 처음 시작을 이렇게 끈으니 더이상 컨트롤이 안되네요. 어째든 강력추천하는 책임니다.

깊이있는 프로그래머가 되기 위한 완벽한 길...

- 김중곤님, 2005-07-25 작성    김중곤님의 모든서평 I 블로그

언젠가.. IT 업계에서 가장 영향력 있는 인물 3명을 꼽은 적이 있는데, 빌게이츠, 리누스 토발즈,  그리고 바로 이책의 저자인 스티브 맥코넬 이다.   그리고 스티브 맥토넬의 책중에서 가장 많이 알려지고, 또 프로그래머에게 가장 직접적이고 실무적인(?) 내용으로 쓰여진 책이 바로 이 Code Complete 이다. 이 책의 무게와 깊이가 어느 정도인지 대충 감이 올것이다.   세상의 프로그래머는 두 종류의 프로그래머로 나눌 수 있을 것이다. Code Complete 을 아는 개발자와 모르는 자..   이 책에서 제공하는 체크리스트만 따라 수행할 수 있는 개발자라면, 프로그래머 업계에서 말하는 "35세까지만 프로그래밍 할수 있다라는 벽"을  충분히 허물 수 있을 것이다. 그리고, 프로그래머라는 직업을 단순히 현재 먹고살기 위한 직업으로만 생각하고 있는게 아니라, 이 업계에서 뼈를 묻을 생각을 가지고 있는 개발자라면, 디버깅 어플리케이션을 쓴 존 로빈스 처럼 이 책을 한 번 두번 그리고 매년 읽도록 해보자... 우리들 지식이 늘어남에 따라 깨달음도 틀릴것이고 새로운 것을 다시 느낄 수 있을 것이다.   단순 프로그래머가 아니라면 분명 '프로페셔널 소프트웨어 개발'이라는 책과 함께 이 책 또한 꼭 읽어둬야 할 것이다.

기획도서 (이 도서는 아래의 기획리스트에 선정되었습니다)

[게릴라 이벤트] 명서 5종 최고 40% 할인! [총 5종]

강컴 Choice [총 303종]

독자서평

기본을 다지는데 많은 도움을 주는 책..

- 오광섭님, 2008-03-08 작성    오광섭님의 모든서평 I 블로그

94년도에 출간되어 10년이 넘도록 많은 감동을 주었던 첫번째 에디션이 내용이 보강되고 시대에 맞도록 수정되어 2004년도에 10년만에 새로 출간되었다.. 아마 10주년 기념으로 개정판을 기획한 것 같다.. 책은 나오자 마자 구입을 했고 번역본은 1년후에 국내에 출간되었지만, 이제서야 책을 집어들고 읽어보고 있다.. 역시 책은 사두기만 해서는 도움이 안된다.. 속독이라도 한번은 읽어줘야 제값을 발휘하지..   사 실 원작이 워낙에 좋아 개정판이 시대의 흐름에 맞춰 나왔다고는 하나 소스코드 샘플이 자바로 바뀐 정도, 내용도 크게 바뀌지 않았다고 이야기 할 수 있을지도 모른다.. 안정된 소프트웨어를 만들기 위해 설계, 구현, 테스트 하는 전반에 걸친 내용이 10년이 지났다고 해서 크게 바뀌지는 않았을 것 같다는 생각도 들기도 하고.. 하지만, 큰 틀이 바뀌지 않았다는 것이지 많은 패러다임의 변화가 있었으므로 개정판이 갖는 의미는 크다고 할 수 있다.. 물론, 개정판을 끝까지 다 읽어봐야 확실히 말할 수 있겠지만..   Steve McConnell의 수많은 명저들 중에서 프로그래머들에게 실질적으로 가장 도움이 되는 책이 바로 이 책이다.. 초급자 뿐만 아니라 중급 이상의 프로그래머들도 이 책을 통해 더 현명한 프로그래머들의 습관이나 사고방식을 전수 받을 수 있다.. 알고보면 뻔한 이야기인 것 같아도, 시행착오를 거치며 알아내야 하는 것들이 꽤 되지 않는가..   개정판으로 나오면서 내용도 훨씬 더 요약 및 정리가 잘 되어 책도 좀 더 얇아진 것 같다.. 프로그래밍 완전정복 이라는 좀 우스운 제목으로 소개된 국내 번역서는 그 두께가 얼마나 두껍던지 읽어보기도 부담 스럽던데 비하면 훨씬 좋다..   프 로그래머들이라면 꼭 한번 읽어볼만한 책이다.. 개정판이 나왔으니 굳이 두번 읽을 필요 없이 개정판을 읽는 것이 더 좋겠지.. 원서를 구입해서 번역서를 읽어보지는 못했으나 요즘 번역서들의 질을 보면 염려할 필요는 없을 것이다.. (불과 몇년전만 해도 번역서 사기가 겁나던 시절이 있었다.. 대표적으로 날아라 삼각형~ 휴지통으로~)

어떤 책인지 궁금해서

- 정재열님, 2007-04-26 작성    정재열님의 모든서평 I 블로그

개발자라면 한번쯤 읽어야한다고 해서 사보고 있는데..   짜투리 시간에 간혹 보고 있긴한데 분량 탓인지 전부 보기 앉아있기엔 제가 게을러서   힘들거 같아서 필요한 부분만 보고 있어요..   내용은 괜찮은거 같네요..    저처럼 생각없이 코딩하는 초짜에 개발에 깊이를 모르는 사람은 지루한 부분도   있다는거..  ^^*   두고두고 봐야할듯한데 잘 안 봐질듯한.....

재미있네요

- 허재호님, 2007-03-26 작성    허재호님의 모든서평 I 블로그

개발자로서 갖춰야 할 개념들과 구조적 지식들을   저자 자신이 초반부에 설명한 것처럼 비유를 통해서 꽤 재미있게 쓴 책입니다.   물론, 부분에 따라서는 딱딱한 부분도 있지만...   그동안 문득문득 떠오르던 여러가지 궁금증들을 해결할 수 있었고,   쉽사리 넘어갔던 나만의 고질적인 부분도 많이 발견할 수 있었던 기회가 되었다고 생각합니다.

참고로... 말하지만...

- 허승호님, 2007-02-06 작성    허승호님의 모든서평 I 블로그

게으른 개발자 - 내가 초급자라면 -> 괜찮은데 책 내용이 너무 쓸데없이 길어~ 뎅장 내가 초중급자 라면 -> 어디서 많이 본거 같은데 내가 중급자 라면 -> 알고는 잇는데 왜 내가 하지 않고 있지?   < 현재의 나 내가 중고급자 라면 -> 이걸로 밥먹고 살기 힘들군 내가 고급자 라면 -> 책 바꿀까? 근데 이거 어디서 어디서 빼꼇지?    본천(본인이 천재라고 생각하는) 개발자 - 내가 초급자라면 -> 아주 좋아 근데 이 내용을 내가 다 기억할까? 내가 초중급자 라면 -> 필요한 것만 보자 내가 중급자 라면 -> 난 항상 이런 패턴으로 일하고 있잖아 내가 중고급자 라면 -> (하루만에 대충보고...)누구에게 팔까? 내가 중고급자 라면 -> 빌게이츠도 이책 봤을까?     헉! 책 가격 내려갔다.. 내가 다른 사이트서 이책 샀나?   쓸데없는 내용만 적어서 ㅎㅎ   책 내용 좋아요~ 볼만하고 괜찮아요~ 초급자가 봐도 무난하고 새록새록 머리속으로 들어오는거 같아요 ㅎㅎ~

기본이되는 책

- 최영진님, 2006-11-17 작성    최영진님의 모든서평 I 블로그

프로그래머중에 이책이 없는 사람이 별로 없는 책인듯

개인 개발 습관 및 개발 방법론 모두에 통용되는 바이블

- 김익주님, 2006-10-10 작성    김익주님의 모든서평 I 블로그

책을 보면 책 출판지를 보면 Microsoft 라고 되어 있음을 알수 있다. 그동안 MS 책을 많이 보아온 터라 좀 관료적인(?) 책이지 않을까 싶었다.   책을 받아 본 순간 분량이 장난 아닌 수준 ^^   하지만 책장을 펼치고 목차를 본 순간. 개발에 필요한 내용들이 처음부터 끝까지 전반적인 내용에 대해서 모두 포괄하는 것을 보고 책 분량이 그리 크지 않다는 생각을 하게되었다.   사실 이 책을 모두 정독을 하고 개발을 하라고 추천하고 싶지는 않다. 너무 방대한 내용과 분량때문이다. 하지만 옆에 꼭 놔 두고 개발하는데 있어서 궁굼한점들이 있는 사람들은 이 책을 열어 목차를 보면 모든 문제가 해결될 것이라고 나는 생각한다.   물론 특정 세부적인 기술적 문제에 대한 해답을 주지는 않는다. 개발론과 개발 습관 등에 걸쳐 어느 정도 규모가 되는 프로젝트를 한다면 꼭 필요하다.   정말 괜찮은 책으로 개인마다 한 권씩 있으면 좋은 책이며, 부담된다면 프로젝트를 하는 팀에서는 반듯이 한 권씩을 가지고 일을 하라고 강력히 추천하고픈 책이다.

1판과 그리 다르지는...

- 박정진님, 2006-09-16 작성    박정진님의 모든서평 I 블로그

2002년 월드컵 시즌에 1판을 선배의 권유로 10일에 걸쳐 읽은 기억이 난다. (책을 빨리 읽는 편이기에 이 책은 무척 오래동안 읽은 편에 속해 기억하고 있다. - 두께가 만만찮았다-_-)   어찌보면 베개로 쓰일만한 두께에 오직 코드에 대한 내용만 꽉꽉 차있다. (설계나 분석하고는 전혀 상관없다고 저자는 밝히지만 후에 풍선효과-_-로 많은 도움이 되는 책이다. )   McConnell의 책은 전체적으로 균형점을 잘 찾는다는 느낌이 있다.(궁합이 잘 맞는지도-_-) McConnell의 책중 첫번째로 읽은 책이었고 감동받아 다른 모든 McConnell을 읽게 만든 책이기도 하다. (그리고 다른 책들도 모두 훌륭했다. 그 자기 회사 자랑하는 책(?)은 좀 그랬지만-_-)   그 러나 책이 쓰여진 시기가 시기니 만큼 종종 지금과는 어울리지 않는다거나(물론 저자는 나름대로 원칙을 말하는게 아니라 권장을 하고 있다.) 이런것까지 굳이 신경쓸 필요 없잖아-_- 라고 생각되는 항목이 있긴 하지만 두께에 걸맞을 저자의 많은 경험과 지식이 들어있다.   2판이 나오자 마자 읽었는데.. 2판과 1판은 많이 바꼈다고 하지만 그리 바뀐 내용은 많지 않은 듯 하다..   어쨋거나 다른 사람들이 자주 칭찬하는 책이라 ... -_)

이 책은 95%의 완성도를 가지고 있다.

- 임은천님, 2006-06-02 작성    임은천님의 모든서평 I 블로그

이 책에 대한 정보를 얻게 된 건 okjsp.pe.kr이라는 곳을 통해서 였다. 허광남 님께서 프로그래머라면 꼭 한 번쯤은 읽어 봐야 하는 내용이라고 하셨는데, 이제서야 읽어 보게 되었다.   이 책을 읽는데는 비록 7일이라는 긴 시간이 걸렸지만, 이 책을 다른 책처럼 빠르게 읽지 않고, 내용을 곱씹으면서 천천히 읽었던 것은 내가 개발자로써 살아갈 것이고, 앞으로 아키텍트가 될 것이기 때문이었다.   주 요 내용의 초점이 [[  구  현  ]]에 집중되어 있다. 그래서 이 책의 제목이 Code Complete 인 것이다. 이전 판을 보지는 않았지만, 이 책의 내용으로 봐서는 이 전 책도 상당한 두께와 상당한 완성도를 가지고 있을 거라고 생각이 된다.   실질적인 개발 프로세스를 따라서 개발자로써 프로젝트를 바라보는 관점을 제공해 줄 뿐 아니라, 중급 개발자를 고급 개발자로 이끌 수 있는 엄청 나게 많은 정신적이고 물질적인 측면의 도움을 준다.   초 반부는 아키텍쳐 단계부터 글의 내용이 시작이 되기 때문에 이 책 전에 읽었던 TDD의 구현 방식과는 정반대의 이야기가 나오기 때문에 약간은 거부반응을 느꼈다. 혹여나 오탈자가 있을까 주의깊게 보았으나, 이 책의 역자분께서 너무나도 열심히 주석을 달아주셨을 뿐만 아니라, 거의 잘못된 해석도 없어서 무척 만족스러운 책이었다.   초반부에 거부반응을 느낀 건 Kent Beck이라는 이름이 자주 나오며, 이 책의 저자가 약간은 Kent Beck에서 비판적인 생각을 가지고 있기 때문이라고 생각이 된다. 그래서 불만을 가지기도 했지만, 전체적으로 개발 프로세스에 대해서 다루고 있는 이만한 책이 없을 뿐더러, 이 책에서 다루고 있는 각각의 프로세스 별 IEEE 표준이라거나 참고 자료는 엄청나게 많은 도움이 될 수 있다는 생각이 든다.   다 만, 이 책의 저자도 사람이기 때문에 예제의 많은 부분이 Visual Basic로 되어 있다는 점과 Visual Basic을 상당히 감싸고, C#을 감싼다는 느낌이 간혹 들긴 하지만.. 전반적으로 개발자로써 필요한 부분들을 다양한 관점에서 바라보고 있고, 또한 다양한 기사와 책에 대한 참고, 그리고 잠깐씩 나오는 개발자들의 한 마디의 말들(격언처럼)을 읽다 보면, [구현]에 대해서 정말 많은 것을 생각하도록 해준다.   각종 논문이나 조사들로 부터 얻은 참고 자료라던가, 각각의 컴파일러의 성능 분석을 위해서 거의 억 대에 가까운 테스트를 한 점 등은 저자가 이 책에 얼마나 공을 들였는지를 깨닫게 해준다.(아마도 저자는 마이크로소프트의 수석 아키텍트 정도 될 것 같다.)   간혹 부하 직원이 이런 식으로 코드를 작성하면 자른다(?) 라는 식의 이야기를 하기도 하지만, 전반적으로 하나라도 더 알려 주고 싶어서 이런 저런 이야기를 많이 했다는 생각이 든다.   하 향식 설계 방식과 상향식 설계 방식에 대해서 좀 더 자세하게 깨달을 수 있었으며, PPP에 대해 알게 된 것은 크나큰 소득이었다고 보인다. 물론 세부 검토니 다양한 단계의 테스트 등에 대해서는 책의 앞 뒤가 상반된 내용을 약간 담고 있을 수 밖에 없는데   저자의 말처럼 "공학은 이런 프로세스의 단계를 조율하는 것"이라는 것에 동의한다.   이전에 읽었던 TDD에서의 프로세스에 장점이 있긴 하겠지만, 저자가 말하는 프로세스에 대한 생각은 좀 더 높은 수준이었고, 각 각의 프로젝트마다 맞는 프로세스가 있을 거라는 생각을 하게 되었다. 저자가 수행하는 프로젝트가 거대한 프로젝트일 경우가 많을 것이기 때문에 하향식 설계 방식과 저자의 수행 방식에는 약간의 차이가 있을 거라고 생각된다.   그 외의 모델에 대해서도(T형이니 하이브리드형) 설명을 빼놓지는 않았다. 개발자 뿐만 아니라 경영에 관심 있으신 분들도 꼭 읽어 봐야 하며, 관리자라면 정말 꼭 읽어 봐야 하는 책이 아닌가 싶다.   이 책을 읽기 전까지 개발자의 인성이나 성격, 지식, 인내, 끈기 등의 특성들에 대해서는 생각해 보지 않았으나, 어떤 환경에서 더 좋은 개발 생산성이 나타나며, 또 어떻게 해야지 더 뛰어난 개발자, 관리자가 될 수 있는 지 이 책 한 권에서 얻을 수 있다고 감히 장담해 본다.   물론 약간 두꺼운 책이기 때문에 읽기 꺼려질 수도 있으나, 개발에 대한 전반적인 프로세스와 현재 나의 위치를 파악해 보고, 앞으로 어떤 방향으로 공부할 것이며, 개발자로써 살아갈 것인지 생각하도록 해주는 책이므로 아직 안 읽어 봤다면 꼭 읽어 보길 바란다.   이 책에 대해서 몇 가지 비판을 할 수 있는 점은   1. 전체 언어에 적용되는 이야기처럼 말을 하고 있으나 다른 언어에서는 적용이 안되는 예제이거나 개념일 수 있다는 점 2. 약간&nbspMS를 두둔하며, 저자가 추진했던 MS의 큼직한 프로젝트들의 경험은 일반적인 객체 지향 프로그래밍과 안 맞을 수 있다는 점   정도 밖에 없을 듯 하다.

복음서와 같은책

- 조종호님, 2006-04-21 작성    조종호님의 모든서평 I 블로그

맨처음 책을 보시면 방대한 분량에 혀를 내두르실 겁니다.   이책은 무작정 읽어서는 수면제가 되기 일수입니다.   일단 몇개 쉬운 단원, 혹은 평소 관심이 많았던 분야에 대한 단원을 읽으시면서 이책을 보는 방법을 습득하셔야 합니다. 이후, 재미 없지만 봐둬야 할것같은 단원을 보시고, 별로 보고 싶지 않은(그러면서도 어려운) 단원은 이전까지 습득한 코드컴플리트 읽는방법을 토대로 읽으시면 되실듯 합니다.   워낙 수많은 소프트웨어 방법론들이 나와서 그냥 책읽듯이 하시면 저자가 무슨말을 하고싶은건가?하는 의문이 들수도 있습니다.   방법론에는 단순히 소프트웨어구현에 대한 방법뿐만이 아니라 일정수립, 위험요소 관리, 팀 협력방법등 소프트웨어 개발에 대한 포괄적인 방법이 설명되어 있습니다.   맥 코넬의 코드컴프릿은 그의 또다른 유명한 저서들 ("professional 소프트웨어 개발" 등등)과는 달리 그의 철학에 맞지않는 개발방법들에 대해서도 꼼꼼히 설명함으로써 소프트웨어 개발 전반적인 방법들을 전파하고, 프로그래머들 각자의 철학에 맞게 습득하도록 도와줍니다.   실용주의 프로그래머와 함께 항상 곁에 둬야할 책이라고 생각합니다.

무게가 있는 책

- 김희환님, 2006-02-10 작성    김희환님의 모든서평 I 블로그

무게가 있는 책이 아닐까 하네요..   뚜꺼워서 무겁고기도 하지만.. 내용적인 부분에서도 무게를 담고 있다고 할 수 있죠..   초보가 보기에는 좀 난해하고 어려운 개념이라고 할 수 있고요..   어느정도 프로그램을 접해보시고.. 설계와 디버깅의 중요성을 느끼시는 분들께 .. 추천하는 책이라고 할 수 있겠죠..   책의 내용이 너무 방대하여.. 솔직히 책을 드는 순간 아니 멀리서 보는 순간부터.. 압박이 느껴지는데..   실무 경험이 있으신 분들은 필요한 부분을 볼 수 있도록.. 구성은 되있다고 할 수 있고요.. 초보 경험자들은 처음부터.. 천천히 단계단계 읽는게 좋을 듯 하네요.   전 초보라서 단계단계 읽기는 하는데.. 솔직히 다른 책 보고 뭐 공부하다 보니.. 많이는 못 보았구요..   책의 내용적인 부분을 이해하는데 조금 애를 먹기는 하지만.. 생각과 발상의 전환을 불러 일으키고 있다고 생각합니다...

강력한 포스가 느껴지는책.

- 양이호님, 2005-09-06 작성    양이호님의 모든서평 I 블로그

처음 받아보고 느낌 감정은 우와~~ 대단하다이다..   거의 모든내용이 총망라 되어있다고 해도 과언이 아닌책인것이다.   이책의 체크리스트라던지 최소한 이해를 하고 있다고 한다면   당신의 직장내에서의 가치는 더욱더 상승하게 되는 책일것이다.   지금 시기상으로 이책이 나온걸 정말 감사히 생가한다..   수시로 읽어보면 좋은 책일듯싶다...   아직 보지도 못했지만 처음 느낌이 너무 강렬해서 한마디 적었다. PS..... 본이 아니게 거의 반말체인데 처음 시작을 이렇게 끈으니 더이상 컨트롤이 안되네요. 어째든 강력추천하는 책임니다.

깊이있는 프로그래머가 되기 위한 완벽한 길...

- 김중곤님, 2005-07-25 작성    김중곤님의 모든서평 I 블로그

언젠가.. IT 업계에서 가장 영향력 있는 인물 3명을 꼽은 적이 있는데, 빌게이츠, 리누스 토발즈,  그리고 바로 이책의 저자인 스티브 맥코넬 이다.   그리고 스티브 맥토넬의 책중에서 가장 많이 알려지고, 또 프로그래머에게 가장 직접적이고 실무적인(?) 내용으로 쓰여진 책이 바로 이 Code Complete 이다. 이 책의 무게와 깊이가 어느 정도인지 대충 감이 올것이다.   세상의 프로그래머는 두 종류의 프로그래머로 나눌 수 있을 것이다. Code Complete 을 아는 개발자와 모르는 자..   이 책에서 제공하는 체크리스트만 따라 수행할 수 있는 개발자라면, 프로그래머 업계에서 말하는 "35세까지만 프로그래밍 할수 있다라는 벽"을  충분히 허물 수 있을 것이다. 그리고, 프로그래머라는 직업을 단순히 현재 먹고살기 위한 직업으로만 생각하고 있는게 아니라, 이 업계에서 뼈를 묻을 생각을 가지고 있는 개발자라면, 디버깅 어플리케이션을 쓴 존 로빈스 처럼 이 책을 한 번 두번 그리고 매년 읽도록 해보자... 우리들 지식이 늘어남에 따라 깨달음도 틀릴것이고 새로운 것을 다시 느낄 수 있을 것이다.   단순 프로그래머가 아니라면 분명 '프로페셔널 소프트웨어 개발'이라는 책과 함께 이 책 또한 꼭 읽어둬야 할 것이다.

도서목차

Part 1 기초 수립 Chapter 1 소프트웨어 구현으로의 초대 1.1 소프트웨어 구현이란 무엇인가? 1.2 소프트웨어 구현이 중요한 이유는 무엇인가? 1.3 이 책을 읽는 방법 요점 정리 Chapter 2 소프트웨어 개발의 이해를 돕기 위한 비유 2.1 비유의 중요성 2.2 소프트웨어 비유의 사용 방법 2.3 일반적인 소프트웨어 비유 소프트웨어 글쓰기 : 코드 작성하기 소프트웨어 농사 : 시스템 키우기 소프트웨어 조개 양식 : 시스템 증대(accretion) 소프트웨어 건축 공사 : 소프트웨어 구축 소프트웨어 기법의 적용 : 지능적인 도구 상자 비유들의 결합 참고 자료 요점 정리 Chapter 3 준비는 철저하게 : 선행 조건 3.1 선행 조건의 중요성 선행 조건이 현대적인 소프트웨어 프로젝트에 적용되는가? 불완전한 준비의 원인 구현 전에 선행 조건을 수행하기 위한 필수적인 논의 3.2 소프트웨어의 종류 결정 선행 조건에서의 반복적인 접근 방법이 갖는 효과 반복적인 방법과 순차적인 방법의 선택 3.3 문제-정의 선행 조건 3.4 요구 사항 선행 조건 왜 공식적인 요구 사항이 필요한가? 견고한 요구 사항에 대한 미신 구현중에 요구 사항 변경 다루기 3.5 아키텍처 선행 조건 전형적인 아키텍처의 구성 요소 3.6 선행 조건에 소요되는 시간 참고 자료 요점 정리 Chapter 4 구현 시 결정해야 할 핵심적인 사항들 4.1 프로그래밍 언어 선택 언어 설명 4.2 프로그래밍 규약 4.3 기술적인 흐름의 파악 언어로의 프로그래밍 예제 4.4 주요 구현 방법론의 선택 요점 정리 Part 2 고급 코드 생성하기 Chapter 5 구현 설계 5.1 설계의 문제점 설계는 불명확한 문제이다 결과는 정돈되었을 지라도, 설계는 엉성한 프로세스이다 설계는 트레이드오프와 우선순위에 관한 것이다 설계에는 제약이 따른다 설계는 다양성을 지닌다 설계는 발견적 학습 과정이다 설계는 창발적이다 5.2 설계의 핵심 개념 소프트웨어의 기본적인 기술적 의무 : 복잡성 관리 바람직한 설계의 특징 설계 수준 5.3 빌딩 블록의 설계 : 발견적 학습 실세계의 객체를 찾아라 일관성 있는 추상화를 구성하라 세부 사항들을 캡슐화하라 상속이 설계를 단순화할 수 있을 때 상속하라 비밀을 숨겨라(정보 은닉) 변경될 것 같은 영역을 규명하라 느슨한 결합을 유지하라 일반적으로 널리 사용되는 설계 패턴을 찾아라 다른 발견적 학습 발견적 접근 방법을 위한 지침 5.4 설계 방법 반복 분할 정복 하향식과 상향식 설계 접근 방법 실험적인 프로토타이핑(prototyping) 협력적인 설계 설계를 얼마나 해야 할까? 설계 작업 기록하기 5.5 유명한 방법론에 대한 의견 참고 자료 요점 정리 Chapter 6 클래스 다루기 6.1 클래스 기초 : 추상 데이터 형(ADT) ADT가 필요한 예 ADT 사용 시의 혜택 ADT의 더 많은 예 비 객체 지향 프로그래밍 환경에서 여러 개의 데이터 인스턴스를 ADT로 다루기 ADT와 클래스 6.2 좋은 클래스 인터페이스 좋은 추상화 좋은 캡슐화 6.3 설계와 구현 문제 포함(“has a” 관계) 상속(“is a” 관계) 멤버 함수와 데이터 생성자 6.4 클래스를 작성하는 이유 피해야 할 클래스 클래스 작성의 이유에 대한 요약 6.5 언어에 따른 문제 6.6 클래스를 넘어서 : 패키지 참고 자료 요점 정리 Chapter 7 고급 루틴 7.1 루틴을 작성하는 타당한 이유 루틴으로 작성하기에는 너무 단순해 보이는 연산 루틴 작성의 이유에 대한 요약 7.2 루틴 수준에서의 설계 7.3 좋은 루틴 이름 7.4 루틴의 길이에 대한 문제 7.5 루틴의 매개변수를 사용하는 방법 7.6 함수 사용 시 특별히 고려해야 할 사항들 함수를 사용할 할 때와 프로시저를 사용할 때 함수의 리턴 값 설정 7.7 매크로 루틴과 인라인 루틴 매크로 루틴 사용의 한계 인라인 루틴 요점 정리 Chapter 8 방어적인 프로그래밍 8.1 타당하지 않은 입력으로부터 프로그램의 보호 8.2 어설션(Assertion) 자신만의 어설션 메커니즘 구축하기 어설션 사용 지침 8.3 오류 처리 기법 견고성 대 정확성 오류 처리를 위한 고수준 설계 8.4 예외 8.5 오류에 의해서 발생하는 손해를 막기 위한 방책 방책과 어설션 간의 관계 8.6 디버깅 보조 도구 제품의 제약 사항들을 개발 버전에 무의식적으로 적용하지 않는다 디버깅 보조 도구의 초기 사용 공격적인 프로그래밍을 사용하라 디버깅 보조 도구를 제거하기 위한 계획 8.7 제품 코드 안에 남는 방어적인 프로그래밍 코드 정하기 8.8 방어적인 프로그래밍에 대해서 방어적이 되는 것 참고 자료 요점 정리 Chapter 9 의사코드 프로그래밍 프로세스 9.1 클래스와 루틴을 작성하는 단계에 대한 요약 클래스 작성 단계 루틴을 작성하는 단계 9.2 전문가를 위한 의사코드 9.3 PPP를 사용한 루틴 구현 루틴을 설계한다 루틴의 코드를 작성한다 코드를 검사한다 미해결된 부분을 정리한다 필요한 만큼 단계를 반복한다 9.4 PPP의 대안 요점 정리 Part 3 변수 Chapter 10 변수 사용 시 일반적인 문제 10.1 데이터 사용 능력 데이터 사용 능력 테스트 데이터 형에 대한 참고 자료 10.2 변수 선언을 쉽게 만드는 방법 암시적 선언 10.3 변수의 초기화에 대한 지침 10.4 범위 변수에 대한 참조를 지역화하라 변수의 “수명”을 가능한 한 짧게 유지한다 범위를 최소화하기 위한 일반적인 지침 범위의 최소화에 대한 설명 10.5 지속성 10.6 바인딩 시간 10.7 데이터 형과 제어 구조 간의 관계 10.8 변수를 한 목적으로만 사용하는 방법 요점 정리 Chapter 11 변수 이름의 효과 11.1 좋은 이름에 대한 고려사항 명명(naming) 시 가장 중요한 고려사항 문제 지향성(Problem Orientation) 최적의 이름 길이 범위가 변수 명에 미치는 효과 변수 이름에서의 계산값 한정자 변수 이름의 일반적인 반의어들 11.2 데이터의 특정 타입에 대한 명명 루프 인덱스의 명명 상태 변수의 명명 임시 변수의 명명 불린 변수의 명명 열거 형의 명명 상수의 명명 11.3 명명 규약의 효과 왜 규약을 가지는가? 언제 명명 규약이 필요한가? 형식화 정도 11.4 비형식적인 명명 규약 언어에 독립적인 규약을 위한 지침 특정 언어의 규약을 위한 지침 혼합 언어 프로그래밍에서 고려할 사항 명명 규약 샘플 11.5 표준화된 접두사들 사용자 정의 축약형 의미적 접두사 표준화된 접두사의 장점 11.6 읽기 쉬운 짧은 이름 일반적인 축약 지침 음성 축약 축약어에 대한 의견 11.7 피해야 할 이름의 종류 요점 정리 Chapter 12 기본 데이터 형 12.1 일반적인 숫자 12.2 정수 12.3 부동소수점 12.4 문자와 문자열 C 언어에서의 문자열 12.5 불린(Boolean) 변수 12.6 열거 형 만약 언어가 열거 형을 지원하지 않는다면? 12.7 명명된 상수 12.8 배열 12.9 새로운 형 만들기(형 별명) 왜 새로운 형을 생성하는 예제들이 파스칼이나 에이다로 작성되었는가? 새로운 형을 만들기 위한 지침들 요점 정리 Chapter 13 특이한 데이터 형 13.1 구조체 13.2 포인터 포인터를 이해하는 패러다임 포인터 사용 팁 C++ - 포인터 포인터 C - 포인터 포인터 13.3 전역 데이터 전역 데이터를 사용할 때 발생하는 일반적인 문제점 전역 데이터를 사용하는 이유 최후의 수단으로만 전역 데이터를 사용하라 전역 데이터 대신 접근 루틴의 사용 전역 데이터를 사용할 때의 위험 요소를 줄이는 방법 참고 자료 요점 정리 Part 4 명령문 Chapter 14 직선형 코드 구성하기 14.1 순서가 중요한 명령문 14.2 순서가 중요하지 않은 명령문 코드를 하향식으로 읽을 수 있도록 작성하기 연관된 명령문 그룹화하기 요점 정리 Chapter 15 조건문 사용 15.1 if 문 if-then 명령문 연속적인 if-then-else 문 15.2 case 문 가장 효율적인 case 순서의 선택 case 문 사용 팁 요점 정리 Chapter 16 루프 제어 16.1 루프의 종류 선택 while 루프를 사용하는 시기 Loop-With-Exit 루프를 사용하는 시기 for 루프를 사용하는 시기 foreach 루프를 사용해야 할 시기 16.2 루프의 제어 루프 진입하기 루프의 중간 부분 처리하기 루프의 종료 종결점 확인 루프 변수 사용 루프가 얼마나 길어야 할까? 16.3 루프를 쉽게 작성하는 법 - 안에서부터 밖으로 16.4 루프와 배열의 대응 요점 정리 Chapter 17 특이한 제어 구조들 17.1 여러 곳에서 리턴하는 루틴 17.2 재귀적 용법 재귀적 용법의 예 재귀 호출 사용 팁 17.3 goto 문 goto 문의 사용을 반대하는 의견 goto 문의 사용을 찬성하는 의견 가짜 goto에 대한 논쟁 오류 처리와 goto 문 goto 문과 else 절에서 공유하는 코드 goto 문의 사용법 요약 17.4 특이한 제어 구조에 대한 전망 참고 자료 요점 정리 Chapter 18 테이블을 활용하는 방법 18.1 테이블을 활용할 때 일반적으로 고려해야 할 사항들 테이블을 활용한 기법의 두 가지 문제점 18.2 직접 접근 방식 월별 일 수 예제 보험료 예제 유연한 메시지 형식 예제 참조 키 조작하기 18.3 인덱스 접근 방식 18.4 단계적 접근 방식 18.5 테이블 참조 방법의 다른 예제들 요점 정리 Chapter 19 제어와 관련된 일반적인 문제 19.1 불린 표현식 불린 테스트에서 true와 false 사용하기 복잡한 표현식을 단순하게 만들기 불린 표현식을 긍정문으로 작성하기 괄호를 사용하여 이해하기 쉬운 불린 표현식 만들기 불린 표현식 평가 방법의 이해 숫자의 크기 순서대로 수치 표현식 작성하기 0을 비교하는 방법 불린 표현식과 관련된 일반적인 문제들 19.2 복합문(블록) 19.3 널 명령문 19.4 지나치게 깊은 중첩 구조의 처리 깊은 중첩 구조를 줄이는 기법 요약 19.5 프로그래밍의 기초 : 구조적 프로그래밍 구조적 프로그래밍의 세 가지 요소 19.6 제어 구조와 복잡도 복잡도가 얼마나 중요한가? 복잡도를 줄이기 위한 일반적인 방법 복잡도 측정의 활용 다른 종류의 복잡도 요점 정리 Part 5 코드 향상 Chapter 20 소프트웨어의 품질에 대한 조망 20.1 소프트웨어 품질의 특성 20.2 소프트웨어의 품질을 향상시키기 위한 기법들 개발 프로세스 목표의 설정 20.3 품질 향상 기법의 상대적 효율성 발견된 결함의 비율 결함 발견 비용 결함 수정 비용 20.4 품질 보증 활동 시기 20.5 소프트웨어 품질의 일반적인 원칙 참고 자료 요점 정리 Chapter 21 협력적인 구현 21.1 협력적인 개발 방법의 개요 다른 품질 보증 기법을 보완하는 협력적인 구현 협력적인 구현은 협동 문화와 프로그래밍 경험을 제공한다 공동 소유권을 협력적인 구현의 모든 형태에 적용한다 협력을 구현 전 만큼이나 구현 후에도 적용한다 21.2 짝 프로그래밍(Pair Programming) 짝 프로그래밍의 성공 요건 짝 프로그래밍의 혜택 21.3 형식적인 정밀 검사 정밀 검사로부터 어떤 결과를 기대할 수 있는가? 정밀 검사에서의 역할 정밀 검사의 일반적인 절차 정밀 검사에서의 자존심 정밀 검사와 Code Complete 정밀 검사 요약 21.4 다른 종류의 협력적인 개발 방법 워크-쓰루(work-throughs) 코드 읽기 프리젠테이션(Dog-and-Pony Shows) 협력적인 구현 기법의 비교 참고 자료 요점 정리 Chapter 22 개발자 테스트 22.1 소프트웨어 품질에서 개발자 테스트의 역할 구현 과정중의 테스트 22.2 개발자 테스트에 대한 바람직한 접근 방법 테스트를 먼저 할 것인가? 나중에 할 것인가? 개발자 테스트의 한계 22.3 여러 가지 테스트 트릭 불완전한 테스트 구조적인 기초 테스트 데이터 흐름 테스트 등가 분할 오류 추측 경계 분석 나쁜 데이터 좋은 데이터 수동으로 점검하기에 편리한 테스트 케이스를 사용하라 22.4 전형적인 오류 어떤 클래스가 가장 많은 오류를 포함하고 있는가? 오류의 분류 결점이 있는 구현으로부터 발생하는 오류의 비율 얼마나 많은 오류를 발견할 것으로 예상해야 할까? 테스트 자체의 오류 22.5 테스트 지원 도구 개별적인 클래스들을 테스트하기 위한 비계 작성 비교 도구 테스트 데이터 생성기 커버리지 모니터 데이터 레코더/로깅 심볼릭 디버거(Symbolic Debugger) 시스템 교란기 오류 데이터베이스 22.6 테스트를 향상시키는 방법 테스트 계획 세우기 다시 테스트하기(회귀 테스트) 자동화된 테스트 22.7 테스트 기록을 보존하는 방법 개인 테스트 기록 참고 자료 요점 정리 Chapter 23 디버깅 23.1 디버깅 문제의 개요 소프트웨어 품질에서 디버깅의 역할 디버깅 성과의 차이 기회로서의 결함 비효율적인 접근 방법 23.2 결함의 발견 과학적인 디버깅 방법 결함을 찾는 데 도움이 되는 팁 구문 오류 23.3 결함의 수정 23.4 디버깅에서 심리학적으로 고려해야 할 사항들 '심리적인 자세'가 디버깅 실명(보지 못함)에 영향을 주는 방법 '심리적인 거리'가 어떻게 도움을 줄 수 있는가? 23.5 디버깅 도구 - 분명하고 그렇게 분명하지 않은 도구 소스 코드 비교 도구 컴파일러 경고 메시지 확장된 문법과 논리 검사 실행 프로파일러 테스트 프레임워크/비계(scaffolding) 디버거 참고 자료 요점 정리 Chapter 24 리팩토링 24.1 소프트웨어 진화의 종류 소프트웨어 진화에 대한 철학 24.2 리팩토링에 대한 소개 리팩토링을 하는 이유 리팩토링을 하면 안 되는 이유 24.3 구체적인 리팩토링 데이터 수준 리팩토링 명령문 수준 리팩토링 루틴 수준 리팩토링 클래스 구현 리팩토링 클래스 인터페이스 리팩토링 시스템 수준 리팩토링 24.4 안전한 리팩토링 리팩토링에 좋지 않은 시기 24.5 리팩토링 전략 참고 자료 요점 정리 Chapter 25 코드 최적화 전략 25.1 성능의 개요 품질의 특성과 성능 성능과 코드 최적화 25.2 코드 최적화에 대한 소개 파레토 법칙 노부인들의 이야기 최적화의 시기 컴파일러 최적화 25.3 느리고 비대한 부분들 비효율성의 공통적인 원인 공통적인 연산의 상대적인 성능 비용 25.4 측정 측정은 정확해야 한다 25.5 반복 25.6 코드 최적화에 대한 접근 방법의 요약 참고 자료 요점 정리 Chapter 26 코드 최적화 기법 26.1 논리 구조 답을 알고 있을 때에는 테스트를 중단하라 빈도에 따른 테스트 정렬 유사한 논리 구조의 성능을 비교하라 복잡한 표현식을 테이블 참조로 대체하라 소극적 평가(lazy evaluation)를 사용하라 26.2 루프 언스위칭(Unswitching) 재밍(jamming) 언롤링(unrolling) 루프 내부 작업의 최소화 감시 값(sentinel values) 가장 빈번한 루프를 안쪽에 작성한다 강도 감소 26.3 데이터 변환 부동소수점 대신 정수를 사용하라 가능한 한 가장 적은 차수의 배열을 사용하라 배열에 대한 참조를 최소화하라 보조 인덱스를 사용하라 캐싱(caching)을 사용하라 26.4 표현식 대수 항등식을 사용하라 강도 감소를 사용하라 컴파일 시간에 초기화하라 시스템 루틴을 주의하라 상수의 정확한 형을 사용하라 결과를 사전에 계산하라 공통적인 하위 표현식을 제거하라 26.5 루틴 루틴을 인라인(inline)으로 재작성하라 26.6 저급 언어를 이용한 재구성 26.7 변경이 많을수록 상태는 그대로 참고 자료 요점 정리 Part 6 시스템 고려사항 Chapter 27 프로그램의 크기가 구현에 미치는 영향 27.1 의사 소통과 크기 27.2 프로젝트 크기의 범위 27.3 프로젝트의 크기가 오류에 미치는 영향 27.4 프로젝트의 크기가 생산성에 미치는 영향 27.5 프로젝트의 크기가 개발 활동에 미치는 영향 활동 비율과 크기 프로그램, 제품, 시스템, 시스템 제품 방법론과 크기 참고 자료 요점 정리 Chapter 28 구현 관리 28.1 좋은 코드 작성의 장려 표준 설정 시 고려할 사항들 좋은 코드 작성을 장려하기 위한 기법 이 책의 역할 28.2 형상 관리 형상 관리란 무엇인가? 요구 사항과 설계의 변경 소프트웨어 코드 변경 도구 버전 기계 구성 백업 계획 형상 관리에 대한 참고 자료 28.3 구현 일정의 예측 예측 방법 구현 양에 대한 예측 일정에 미치는 영향들 예측 對 제어 일정에 늦었을 때 해야 할 일 소프트웨어 예측에 대한 참고 자료 28.4 측정 소프트웨어 측정에 대한 참고 자료 28.5 프로그래머를 사람으로 대우하기 프로그래머들은 어떻게 시간을 보내는가? 성능과 품질의 다양성 신앙적인 문제 물리적인 환경 인간으로써의 프로그래머에 대한 참고 자료 28.6 관리자 관리 참고 자료 요점 정리 Chapter 29 통합 29.1 통합 접근 방법의 중요성 29.2 통합 횟수 - 단계별 또는 점증적? 단계별 통합 점증적 통합 점증적 통합의 이점 29.3 점증적 통합 전략 하향식 통합 상향식 통합 샌드위치 통합 위험 지향적인 통합 기능 지향적인 통합 T-자형 통합 통합 접근 방법에 대한 요약 29.4 일별 빌드와 스모크 테스트 어떤 종류의 프로젝트에 일별 빌드를 사용할 수 있는가? 지속적인 통합 참고 자료 요점 정리 Chapter 30 프로그래밍 도구들 30.1 설계 도구 30.2 소스 코드 도구 편집 코드 품질 분석 소스 코드 리팩토링 버전 관리 데이터 사전 30.3 실행 코드 도구 코드 생성 디버깅 테스트 코드 최적화 30.4 도구 지향적인 환경 30.5 자신만의 프로그래밍 도구 개발하기 프로젝트에 특화된 도구들 스크립트(Script) 30.6 프로그래밍 도구에 대한 환상 참고 자료 요점 정리 Part 7 소프트웨어 장인정신 Chapter 31 배치와 방식 31.1 배치 기초 극단적인 배치 기본적인 형식화 법칙 프로그램에 대한 사람과 컴퓨터의 해석 좋은 배치는 얼마나 가치가 있는가? 종교로서의 배치 좋은 배치의 목표 31.2 배치 기술 공백 괄호 31.3 배치 방식 순수 블록 순수 블록 흉내 내기 블록 경계를 나타내기 위해서 begin-end 쌍(중괄호) 사용 줄 끝 배치 어떤 방식이 가장 좋은가? 31.4 제어 구조의 배치 제어 구조 블록의 형식화에 대한 세세한 부분들 추가적인 고려사항들 31.5 단일 명령문의 배치 명령문 길이 명료함을 위하여 공백 사용하기 연속적인 줄 형식화하기 한 줄에 한 명령문만 작성한다 데이터 선언 배치하기 31.6 주석의 배치 31.7 루틴의 배치 31.8 클래스의 배치 클래스 인터페이스 배치하기 클래스 구현 배치하기 파일과 프로그램 배치하기 참고 자료 요점 정리 Chapter 32 스스로를 설명하는 코드 32.1 외부 문서 32.2 문서화를 위한 프로그래밍 방식 32.3 주석을 작성할 것인가? 작성하지 않을 것인가? 32.4 효율적인 주석을 위한 핵심 사항 주석의 종류 효율적으로 주석 작성하기 가장 적당한 수의 주석 32.5 주석 작성 기법 한 줄마다 주석 작성하기 코드 단락에 대한 주석 작성하기 데이터 선언에 주석 작성하기 제어 구조에 주석 작성하기 루틴에 주석 달기 클래스와 파일, 그리고 프로그램에 대한 주석 32.6 IEEE 표준 소프트웨어 개발 표준들 소프트웨어 품질 보증 표준들 관리 표준들 표준에 대한 개요 참고 자료 요점 정리 Chapter 33 개인 성격 33.1 개인 성격은 주제를 벗어난 것 아닌가? 33.2 지성과 겸손 33.3 호기심 33.4 지적인 정직함 33.5 의사 소통과 협동 33.6 창의성과 훈련 33.7 게으름 33.8 생각만큼 중요하지 않은 특성 인내력 경험 별난 프로그래밍 33.9 습관 참고 자료 요점 정리 Chapter 34 소프트웨어 장인(匠人)에 대한 주제 34.1 복잡성 정복 34.2 자신에게 맞는 프로세스 선택 34.3 컴퓨터보다 사람을 위한 프로그램을 작성하라 34.4 언어에 얽매이지 말고 언어를 활용하는 프로그램을 작성하라 34.5 규약을 이용하여 주의를 집중하라 34.6 문제 중심의 프로그램 프로그램을 추상화 수준으로 나누기 문제 도메인에서 작업하기 위한 저수준 기술들 34.7 낙석을 주의하라 34.8 반복, 반복, 또 반복 34.9 소프트웨어와 신조를 떼어 놓아라 소프트웨어 계시(Oracles) 절충주의 실험 요점 정리 Chapter 35 더 많은 정보를 얻으려면 35.1 소프트웨어 구현에 관한 정보 35.2 구현 외의 주제 개괄적인 자료들 소프트웨어 공학 관련 서적 개요 다른 추천 도서들 35.3 정기 간행물 구하기 쉬운 프로그래머 잡지 구하기 어려운 프로그래머 저널 전문적인 간행물 35.4 소프트웨어 개발자의 독서 계획 기초 수준 중급자 수준 전문가 수준 35.5 전문가 협회에 가입하기 INDEX