"전문 프로그래머로 성장하기 위한 실용지침서"

앤드류 헌트, 데이비드 토머스 공저 / 김창준,정지호 공역 | 인사이트(insight)


1. 책이 내게로 왔다.(감상)

통찰력(Insight)있는 출판사에서 보내준 책이어서 꼭 읽어야 한다는 일종의 압박감이 있었으나 막상 책을 읽고 나니 이렇게 좋은 책을 왜 이제서야 읽게 되었는지 만시지탄이 들었다. 『실용주의 프로그래머』라는 책 제목이 암시하듯이 이 책은 기술적인 프로그래밍만을 제시하지 않는다. 좋은 프로그램은 유용한 철학과 접근법에 의해 만들어 질 수 있으며 그것은 바로 실용주의라고 저자는 주장한다. 존 듀이가 주창한 실용주의는 현실에서 유용한 것이 진리라고 보는 입장으로 진리의 절대성을 부정한다. 이 철학을 시스템에 적용해보면 다음과 같다. ‘오직 특정한 환경에 적합한 시스템이 존재하기 때문에 그 상황에 적절한 지식과 기술을 지속적으로 연마해야 한다.’ 어제의 지식과 기술이 오늘 쓸모 없어지는 스피드의 시대에서 실용주의 원칙은 큰 힘을 발휘한다. 실제 IT 현장에서는 자신의 과거 경험만을 제일로 여기는 국수주의 입장에서 프로젝트를 진행하는 사례를 많이 목도하게 된다. 이런 프로젝트의 대부분은 매너리즘이 지배하고 활력이 떨어지며 몸으로 떼우는 방식으로 진행된다.

실용주의 프로그래머는 이 같은 폐쇄적인 입장을 거부하고 ‘돌멩이 스프’를 끓일 수 있을 정도로 고객과의 커뮤니케이션이 원활하고 지속적인 지식 자산을 습득하여 주어진 일을 잘 완수한다. 공동 저자 앤드류 헌트와 데이비드 토머스는 실용주의 프로그래머는 다음과 같은 특징이 있다고 한다. 먼저 새로운 것을 시도해보고 빨리 적응하는 얼리 어답터 성향을 갖고 있으며, 묻기를 좋아하고 비판적인 사고의 소유자이다. 과거의 노예가 되는 것을 단호하게 거부한다. 그리고 모든 문제의 근본적인 성격을 이해하려고 하며 다방면의 기술에 익숙하다. 무엇보다 중요한 특징은 자신의 기술에 관심과 애정을 갖고 있으며 자신이 하고 있는 일에 대해 생각하면서 일한다.

소프트웨어 개발의 모든 부문에 적용가능한 프로세스, 기법, 팁 등 실용주의 접근법에 대한 소개는 퍽 신선하다. 특히 엔퍼프라이즈 자바빈즈(EJB)의 예를 들며 직교성을 향상시키라고 충고하는 구절과 포스트잇을 통해 프로토타이핑의 학습경험을 강조한 대목은 유용한 원리다.
특히 쾌속 프로토타이핑이 혁신적인 조직이 추구해야 할 가장 중요한 능력이다는 슈레이즈의 말을 인용한 부분은 신선한 충격이었다.

더불어 이 책 곳곳에는 개발 과정에 매우 실제적인 도움을 줄 수 있는 방법론이 재미있는 비유를 통해 소개되고 있다. 결합도 줄이기와 디미터 법칙에서는 스파이 조직의 ‘세포’의 비유를 통해 독립적으로 모듈을 구성할 것을 주장하며, 리랙토링(Repactoring)이 필요한 코드를 ‘종양’에 비유하여 지금 바로 수술해서 아직 종양이 작을 때 제거하라고 한다. 무엇보다 본인의 마음을 잡아 끈 내용은 ‘의도적으로 프로그래밍’하기였다. 자기 코드에 대해 적극적으로 생각하지 않고 ‘보이지 않는 손’에 의해 알아서 잘 돌아갈 것이라는 우연에 맡기는 프로그래밍이 아니라, 언제나 자신이 지금 무엇을 하고 있는지를 인식하고, 계획을 세우고 목적의식적으로 프로그래밍하라는 것이다.

테스트의 중요성을 설득력 있게 언급한 점도 마음에 든다. 개발자 대부분은 테스트를 싫어한다. 한다 하더라도 버그를 피해 살살 테스트하려 한다. 그러나 실용주의 프로그래머는 자존심이 강해서 나중에 다른 사람이 자신의 버그를 발견하는 것을 수치심으로 여긴다. 따라서 가차없이 테스트를 한다. 개발자가 작성한 코드는 언젠가는 테스트되며 따라서 개발자가 테스트를 하지 않으면 결국은 사용자가 테스트하게 된다. 사전에 철저하게 테스트 계획을 세우고 진행하지 않으면 수모는 물론이고 고객 검수에 지장을 초래하게 될 것이다. 여기에 덧붙여 한가지 지적하고 싶은 점은 대부분의 소프트웨어 개발에서 개발을 코딩의 완성으로 간주하고 있다는 것이다. 따라서 품질은 전혀 고려되지 못하고 실제 진척이 왜곡되게 마련이다. 주지할 점은 개발은 리팩토링, 동료검토, 테스트가 포함되는 것이며 모든 테스트가 통과되기 전엔 코딩이 다 된 게 아니다.

개발자가 싫어하는 또 하나는 바로 문서화이다. 다큐먼트는 마지 못해 해야 하는 작업이며 기껏해야 필요악이다. 그러나 코드와 문서는 서로 다른 뷰(View)일 뿐이다. 문서는 커뮤니케이션을 위한 중요한 매개체이다. 기록은 기억보다 오래가는 법이다.

이 책 곳곳에는 지혜와 잠언이 가득 차있다. 이 책은 개발자면 누구나 꼭 한번은 봐야 할 필독서이다. 책의 구성도 치밀하고 항목 구성이 잘 되어 있다. 역자의 친절한 주해도 돋보인다. 내용적인 측면에서도 철학적 원칙과 원리를 바탕으로 프로그래밍에 대항 유용한 지식과 팁을 친절이 소개하고 있는 점이 강점이다. 전체적으로 XP(eXtreme Programming) 방법론을 밑바탕에 두고 있다는 느낌이 든다. 테스트를 염두에 두고 설계하라는 팁은 XP의 테스트 주도형 개발(TDD)과 비슷하며 리팩토링, 지속적인 통합의 내용도 마찬가지다.

소프트웨어 개발은 분명 창의적인 일임에도 불구하고 언제부터인가 단순 노가다성으로 치부되었다. 주위의 환경 탓도 크지만 IT업에 종사하는 개발자들의 책임도 적지 않다. 소프트웨어 개발은 기예(craft)이며 프로그래머는 매일매일 작은 기적을 만드는 사람이라고 저자는 말한다. 개발에 대한 나름대로의 확고한 철학이 바탕이 되어야 한다. 또한 자신의 일에 대해 꼭 생각해 보아야 한다. 그것이 바로 실용주의다. 실용주의는 현실에 영합하는 것이 아니라 기본원칙이 반드시 존재한다. 이런 원칙이 견지될 때 실용주의는 그 위력을 발휘할 수 있으며 정약용 선생의 가르침인 실사구시와 맞닿아 있을 수 있다.

실용주의 프로그래머는 지속적인 변화를 통해 전문가를 추구한다. 또한 습득한 지식을 현장에 적용해봄으로써 이론과 실천의 조화를 꾀한다. 이 책이 소프트웨어 개발업계에 널리 확산되어 실력 있는 마이스터(Meister)가 많이 양성되었으면 하는 바람을 가져본다. 그러나 솔직히 첫 번째 바램은 ‘월화수목금금금’의 척박한 환경에서도 묵묵히 맡은 바 일을 감내하는 개발자들이 자신의 일에 대해 한없는 애정을 품는 기회가 되는 것이다.


2. 역지사지(易之思之)-내가 저자라면

* 저자 : 데이비드 토머스(David Thomas), 앤드류 헌트(Andrew Hunt)
데이비드 토머스(David Thomas)와 앤드류 헌트(Andrew Hunt)는 현재 Pragmatic Programmer LLC를 운영하며 개발자와 관리자를 대상으로 한 실용적인 자원들을 제공한다.
저서로 실용주의 프로그래머를 위한 시작도구 시리즈 『Pragmatic Starter Kit 시리즈』가 있고, 최근 Pragmatic Bookshelf 출판사를 만들어 효과적이고 유쾌한 실용주의 프로그래머의 프로그래밍 방식을 설파하고 있다.
저자들에 대한 정보는 http://pragmaticprogrammer.com에서 더 찾아볼 수 있다.

이 책은 적어도 형식적인 측면은 완벽할 정도로 치밀하게 구성되어 있다. 각 장마다 제목에 맞추어 명언, 내용 설명, Tip, 관련항목, 도전해 볼 것, 연습문제 등의 단락으로 이루어져 있는데(한마디로 모듈화가 잘 되어 있어서) 각 장이 완결적인 구조를 갖고 있어서(결합도가 낮다) 특정 장(Chapter)만 봐도 이해가 될 수 있다. 앞으로 책을 쓸 때 꼭 참고할 만한 구성이다. 각 장의 관련항목이 해당 장의 앞, 뒤에 있는 내용이 나와 있는 걸 보면 독립적으로 각 장을 작성한 후 연결한 듯한 느낌이 든다.

독자를 배려한 책의 구성이 돋보이는 점이 이 책의 큰 장점이다. 책 뒷부분에 있는 유용한 팁과 정보는 책을 산 보람을 느끼게 한다. 무엇보다 이 책을 구매했을 때의 가장 큰 혜택은 바로 책 부록에 있는 70개의 팁에서 얻을 수 있다. 사실 이 내용만 숙지해도 이 책에 대한 본전은 충분히 뽑고도 남음이 있다. 출판사는 독자가 편리하게 사용할 수 있도록 별도의 용지를 사용하여 친절하게 뒷부분에 껴주었다. 세심한 배려가 느껴진다. 프로그래머는 책상 머리에 붙여두고 화두처럼 되새기면 좋을 듯하다. 실용주의 프로그래머 체크리스트 팁과 참조항목도 매우 유용한 정보이다.

내가 만난 번역서는, 특히 IT 관련 책자는 번역이 매끄럽지 못한 경우가 많았다. 아무리 유명한 책으로 소문났다 하더라도 용어상의 애매모호함, 내용의 오류, 전체적인 일관성의 부재 등의 요인이 나의 인내심을 시험했다. 그러나 이 책은 번역이 깔끔하고, 특히 역자 주해가 돋보인다. 에드워드 드보노, 켄트 백 등의 필요한 저자의 책 소개를 통해 해당 부분에 대한 독자의 풍부한 이해를 돕는다.

전체적으로 책의 내용이 저자의 위트가 가미되어 재미있고 일관성 있게 전개되고 있으나, 4장(실용주의 편집증)과 5장(구부러지거나 부러지거나)의 내용은 장황한 설명이 반복되어 다소 지겨운 면이 없지 않다. 대부분의 번역서를 읽고 나면 느끼는 바이지만 한국적 현실과의 괴리가 가장 아쉬운 대목이다. 특히 프로그램 명세화에 대한 부분은 인식의 차가 크게 존재한다. 국내 현실은 명세화를 누락하거나 간과하는 경향이 심해서 프로그래밍과의 간극이 발생하고 이로 인해 재작업이 자주 발생하는 문제점을 안고 있다. 그러나 이 책에서는 ‘명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다’며 오히려 이를 부추기는 듯한 기술을 하고 있다. 또한 국내 현실은 소프트웨어 개발 분야가 세분화되지 못하여 개발자가 프로그래밍에만 전적으로 매달릴 수 없다. 우리 현실은 개발자의 연수가 올라가면 분석, 설계에 대한 이해가 필수적이다. 따라서 데이터베이스, 프로세스 모델링에 대한 접근이 없는 점이 아쉬움으로 남는다.

이 책은 디테일한 기술 서적이 아니다. 언뜻 보기에 개발자에게 직접적인 도움을 주는 책이 아닐 수도 있다. 그러나 앞으로 이 책은 스테디셀러가 될 가능성이 높다. 왜냐하면 개발자가 소프트웨어 개발 분야에 종사하는 한 견지해야 할 철학과 방향을 제시해주고 있기 때문이다. 하루가 빛의 속도로 빠르게 변하는 세상이지만 무릇 철학의 수명은 길다. 성경이 아직까지 전 세계 베스트셀러를 유지하고 있는 것은 바로 세계관, 가치관, 구원의 문제를 다루고 있기 때문이다. 이 책이 개발자를 구원해줄 책 중의 하나임은 분명하다.


3. 책에서 끌어다 쓰기(인용)

[서문]

프로그래밍은 기예(craft)이다. 가장 간단하게 생각해보면 프로그래밍이란 컴퓨터에게 여러분이 시키고 싶은 일을 하게끔 만드는(또는 여러분의 고객인 사용자가 시키고 싶은 일을 하게 만드는) 것이다. 프로그래머는 어떤 면으로는 들어주는 사람이고, 어떤 면으로는 조언하는 사람이며, 어떤 면으로는 통역하는 사람이기도 하고, 어떤 면으로는 명령을 내리는 사람이기도 하다. 프로그래머는 애매모호한 요구사항을 포착해서 단순한 기계까지도 그것을 잘 수행할 수 있도록 요구사항을 표현하는 방법을 찾으려 노력한다. 프로그래머는 다른 사람도 이해할 수 있도록 자신의 작업을 문서로 만들려고 노력하고, 다른 사람들이 자신이 한 것을 바탕으로 또 다른 것을 만들 수 있도록 자신의 작업을 설계하려고 노력한다. 이뿐이 아니라, 프로그래머는 쉬지 않고 똑딱대는 프로젝트 일정 시계의 초침에 굴하지 않고도 이 모든 일들을 해내기 위해 노력한다. 프로그래머는 매일 작은 기적을 만드는 것이다. (P17~18)

오직 특정한 환경 조건의 집합마다 각 집합에 가장 적절한 시스템들만이 있을 뿐이다. 바로 이것이 실용주의가 뜻하는 바다. 어떤 특정 기술에 매이면 안 되며, 개별 상황마다 그 상황에서 좋은 해결방안을 고를 수 있도록 충분한 배경지식과 경험을 가져야 한다. 배경지식은 컴퓨터 과학의 기본 원리들을 이해하는 것에서 나오고, 경험은 다양한 범위의 실제 프로젝트들을 수행해보는 것에서 나온다. 이론과 실천의 결합이 여러분을 강하게 만든다. (P18)

* 실용주의 프로그래머의 특징
1. 얼리어덥터 성향/새로운 것에 빨리 적응하는 성향
2. 캐묻기 좋아한다.
3. 비판적인 사고의 소유자
4. 현실적이다.
5. 다방면의 기술에 익숙하다.

우리가 단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다. -채석장 일꾼의 신조 (P22)


[1장 실용주의 철학]

<3. 돌멩이 수프와 삶은 개구리>
“허락을 얻는 것보다 용서를 구하는 것이 더 쉽다” (P39)

<4. 적당히 괜찮은 소프트웨어>

<5. 지식 포트폴리오>
지식에 대한 투자가 언제나 최고의 이윤을 낸다. –벤자민 프랭클린 (P46)

* 지식 자산을 얻는 최선의 길
1. 매년 새로운 언어를 최소 하나는 배워라.
2. 기술 서적을 분기마다 한 권씩 읽어라.
3. 비 기술 서적도 읽어라.
4. 수업을 들어라.
5. 지역 사용자 모임에 참여하라.
6. 다른 환경에서 실험해보라.
7. 요즘 흐름을 놓치지 마라.
8. 인터넷을 이용하라. (P49-50)

<6. 소통하라!>
나는 무시당하느니 차라리 샅샅이 훑어보는 시선이 낫다고 봐요. –메이 웨스트 (P54)

* WISDOM - 청중 이해하기
1. 무엇(What)을 배우기 원하는가?
2. 말하려는 것에서 그들이 관심(interest)있어 하는 건 무엇인가?
3. 얼마나 소양(sophisticated)이 있는가?
4. 어느 정도의 구체적인(detail) 내용을 원하는가?
5. 누가 정보를 소유(owe)하길 원하는가?
6. 그들이 경청하도록 동기(motive)를 주려면 어떻게 해야 할까? (P56)


[2장 실용주의 접근법]

<7. 중복의 해악>
소프트웨어를 신뢰성 높게 개발하고, 개발을 이해하고 유지보수하기 쉽게 만드는 유일한 길은 우리가 DRY 원칙이라고 부르는 것을 따르는 것뿐이라 생각한다. DRY 원칙이란 이것이다. 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다. (P66)

나쁜 코드야말로 많은 주석을 필요로 한다. (P68)

<8. 직교성>
‘직교성’이란 기하학에서 빌려온 용어다. 그래프의 축과 같이 두 직선이 직각으로 만나는 직교한다고 말한다. 벡터의 입장에서 보면, 두 개의 선은 ‘독립적’이다. 두 선 가운데 하나의 방향으로 움직여도 나머지 선 위로 투영된 여러분의 위치는 변하지 않는다. 컴퓨팅에서 이 용어는 일종의 독립성이나, 결합도 줄이기를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. (P76)

엔터프라이즈 자바빈즈 시스템은 직교성에 대한 흥미로운 예제다. 대부분의 트랜잭션 지향 시스템에서는 애플리케이션 코드가 각 트랜잭션의 시작과 끝을 서술해야 한다. 하지만 EJB에서는 이러한 정보가 메타데이터를 이용해 표현되기 때문에 코드 밖에 존재한다. 그러므로 같은 애플리케이션 코드가 서로 다른 EJB 트랜잭션 환경에서도 변경 없이 실행될 수 있다. 이는 미래에 많은 환경들이 지향할 모델이 될 것이다. (P83)

자신이 작성하는 코드를 항상 비판적으로 검토해 보는 습관을 기르기 바란다. 기회가 있을 때마다 코드의 구조와 직교성을 향상시키지 위해 노력하라. 이러한 프로세스를 리팩토링(refactoring)이라 부른다. (P85)

<9. 가역성>
당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. –에밀 사르티에 (P90)

우리가 소프트웨어를 개발하는 속도는 요구사항, 사용자 하드웨어의 변화를 앞지를 수 없다. (P92)

누구도 미래에 대해서는 알 수 없으며, 우리라고 예외는 아니다. 여러분의 코드가 로큰롤을 할 수 있게 하라. 락을 할 수도 있고 필요한 경우 롤을 할 수도 있게 하는 것이다. (P94)

<10. 예광탄>
어둠 속에서 빛을 내는 코드 : 코딩에서도 동일한 효과를 얻으려면, 우리를 요구사항으로부터 최종 시스템의 일부 측면에까지 빨리, 눈에 보이게, 반복적으로 도달하게 해줄 무언가를 찾아야 한다. (P97)

프로토타입은 나중에 버릴 수 있는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격의 일부를 이룬다. 프로토타입을 예광탄이 하나라도 발사되기 전에 먼저 일어나는 정찰과 정보 수집으로 생각하면 되겠다. (P102)

<11. 프로토타입과 포스트잇>
슈레이즈는 “초일류 기업의 성공 비밀, 시리어즈 플레이”에서 프로토타이핑 속도가 혁신에 뛰어난 조직과 그렇지 못한 조직을 결정짓는 주된 요소라 말한다. 그는 쾌속 프로토타이핑이야말고 혁신적인 조직이 추구해야 할 가장 중요한 능력”이라 강력히 주장하고 있다. (P104)

소프트웨어 프로토타입도 같은 이유에서 같은 방식으로 만든다. 즉 위험 요소를 분석하고 노출시키며 이를 매우 저렴한 비용으로 바로잡을 기회를 얻는 것이다. (P104)

포스트잇은 작업흐름과 애플리케이션 로직과 같은 동적인 것들을 프로토타이핑해 볼 수 있는 훌륭한 도구다. (P105)

프로토타이핑은 학습 경험이며, 프로토타입의 가치는 생성된 코드에 있는 것이 아니라 이를 통해 배우게 되는 교훈에 있다. 이것이 프로토타이핑의 진정한 핵심이다. (P106)

만약 적절한 정도만 기대하도록 해두지 않으면 겉으론 완벽해 보이는 프로토타입 시연을 보고 프로젝트 후원자 혹은 관리자가 프로토타입 자체 혹은 이를 보완한 결과를 배포하자고 주장하기 쉽다. 그들에게 나무와 테이프로도 멋진 자동차를 만들 수는 있지만, 나무 자동차를 타고 러시아워에 운전할 수는 없다는 사실을 환기시키기 바란다. (P108)

<12. 도메인 언어>
언어의 한계가 곧 자기 세계의 한계다. – 루트비히 비트겐슈타인 (P110)

<13. 추정>
항상 좋은 답을 알려주는 기본적인 추정 기술에 대해 이야기해주고 싶다. 이미 그 일을 해본 사람에게 물어보라는 것이다. (P122)

모델을 만들어 보는 것은 장기적으로 창의적이고도 유용한 작업이다. 흔히 모델을 만드는 과정에서 표면에 명확히 드러나지 않았던 이면의 패턴과 프로세스를 발견하게 된다. (P123)


[3장 기본적인 도구]

‘디버깅’에 고수가 되기 전에는 위대한 프로그래머가 될 수 없다. 머피씨는 사실 낙관적인 사람인 것이다. (P131)

<14. 일반 텍스트의 힘>
우리는 요구사항을 지식으로 수집하고 그 지식을 설계, 구현, 테스트 그리고 문서에 표현한다. 그리고 우리는 지식을 저장하는 최고의 포맷이 일반 텍스트라고 믿는다. (P132)

일반 텍스트란 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자로 이루어진 텍스트를 말한다. (P132)

모든 소프트웨어는 작성되는 순간 레거시(legacy)가 된다. (P135)

유닉스는 작고 예리한 각각의 도구가 한 가지 일만 잘 하도록 만들자는 철학에 때라 설계된 것으로 유명하다. 이 철학은 라인 중심의 일반 텍스트 파일을 기반 포맷으로 공유하기 때문에 가능하다. 시스템 관리를 위해 사용되는 데이터베이스(사용자, 패스워드, 네트워크 설정 등등)는 모두 일반 텍스트 파일로 저장된다. (P136)

<15. 조개놀이>
GUI의 장점은 WYSIWYG(What You See Is What You Get), 즉 여러분이 보는 것이 여러분이 얻는 것이라는 것이다. 단점은 WYSIAYG(What You See Is All You Get), 즉 여러분이 보는 것이 여러분이 얻는 전부라는 것이다. (P139)

<17. 소스코드 관리>
진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다. –조지 산타야나 ‘이성의 삶’ (P152)

소스코드 관리 시스템은 일종의 거대한 UNDO 키와 같다. 코드가 실제로 컴파일되고 실행되던 지난주의 평화로운 시절로 되돌려 줄 수 있는, 프로젝트 전체를 커버하는 타임머신이다. (P152)

<18. 디버깅>
불행하게도 지금의 컴퓨터 시스템은 아직까지도 여러분이 무엇을 명령하는가에 좌우되지, 무엇을 원하는가에 좌우되지 않는다. (P157)

디버깅을 할 때 근시를 조심하라. 표면에 보이는 증상만 고치려는 욕구에 저항하라. 실제 문제는 여러분이 관찰하고 있는 것에서 몇 단계 떨어져 있고, 또 다른 여러 가지와 연관되어 있을 확률이 다분하다. 항상 문제의 근본적인 원인을 발견하려고 노력하고, 그 문제의 특정한 증상만 고치려고 하지 말라. (P159)

<21. 계약에 의한 설계>
정확한 프로그램이란 무엇인가? 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그만큼만 하는 프로그램을 말한다. 이 주장을 문서화하고 검증하는 것이 계약에 의한 설계의 핵심이다. (P185)

<23. 단정적 프로그래밍>
“하지만 물론 그건 절대 일어나지 않을 거야” 라는 생각이 든다면, 그걸 확인하는 코드를 추가하라. (P202)

<26. 결합도 줄이기와 디미터 법칙>
스파이, 반체제자, 혁명가들은 종종 세포라 불리는 작은 그룹으로 조직을 만든다. 각 세포의 구성원은 같은 세포에 속한 구성원만 알 수 있으며, 다른 세포에 누가 있는지에 대해서는 전혀 모른다. 그렇기 때문에 하나의 세포가 발각된다 하더라도, 다른 세포에 있는 사람들은 안전하다. 세포 간의 상호작용을 제거함으로써 모두를 보호하는 것이다. 우리는 이것이 코딩에도 적용될 수 있는 좋은 원리라고 믿는다. 코드를 세포(모듈)로 구성하고, 이들 간의 상호작용을 제한하라. 그러면 한 모듈이 변경되거나 교체된다 하더라도 다른 모듈들은 변경 없이 수행될 수 있을 것이다. (P227)

<27. 메타프로그래밍>
우리는 설정 메타데이터를 일반 텍스트로 표현하는 것을 권장한다. 그러면 삶이 훨씬 편해질 것이다. 그렇다면 프로그램이 언제 설정 정보를 읽어야 할까? 많은 프로그램이 시작될 때 설정 정보를 읽는데, 유감이다. 설정 정보를 변경하면 프로그램을 재시작해야 하기 때문이다. 더 유연한 접근 방식은 프로그램이 실행 중에도 설정 정보를 리로딩할 수 있도록 만드는 것이다. 물론 여기에는 대가가 있다. 구현이 좀 더 복잡하다는 것이다. (P239)

<28. 시간적 결합>
시간에는 우리에게 의미 있는 두 가지 측면이 있다. 동시성(같은 시각에 일어나는 일들)과 순서(시간 속에서 일들의 상대적인 위치)가 그것이다. (P243)

우리는 동시성을 허용할 필요가 있고 시간이나 순서에 따른 의존성의 결합을 끊는 방법을 생각할 필요가 있다. (P244)


[6장 코딩하는 동안 해야 할 일들]

일단 코딩에 들어가면 대부분 기계적으로 따라가야 하는 일, 곧 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 남는다는 생각이 일반적이다. 코딩은 기계적인 작업이 아니다. 만약 그랬다면, 1980년대 초반에 수많은 사람들이 기대를 걸었던 CASE 도구들이 이미 오래 전에 프로그래머를 대체했을 것이다. 코딩할 때는 매분마다 결정을 내려야 하는데, 프로그램이 정확하고 생산적으로 작동하면서 천수를 누리도록 하기 위해서는 사려 깊은 생각과 판단을 통한 결정이 필요하다. 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다. (P271)

여러분이 코드를 작성할 때는 언젠가 그 코드를 테스트하게 될 것이라는 생각을 꼭 마음 한 구석에 두고 있어야 한다. 테스트하기 쉬운 코드를 만들어라. 그러면 실제로 그 코드를 여러분이 테스트하게 될 확률도 늘어난다. 우리들 대다수는 차를 운전할 때 굳이 의식적으로 생각하지 않는다. 페달을 밟거나 운전대를 돌릴 때 발이나 팔에 의식적으로 명령을 내리지 않고, 그저 ‘조금 속도를 줄이고 오른쪽으로 돌자’라고 생각한다. 하지만, 운전을 안전하게 잘하는 사람들은 언제나 자기 상황을 검토하고, 잠재적인 문제들을 점검하며, 예상하지 못한 일이 생겼을 때에도 잘 대처한다. 코딩도 똑같다. 대부분은 반복적인 일이지만, 마음을 늘 깨어있도록 유지하면 재앙을 막을 수 있다. (P272)

<31. 우연에 맡기는 프로그래밍>
* 의도적으로 프로그래밍하기
1. 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다.
2. 맹목적으로 코딩하지 말라.
3. 계획을 세우고 그것을 바탕으로 진행하라.
4. 신뢰할 수 있는 것에만 기대라.
5. 여러분의 가정을 문서로 남겨라.
6. 코드만 테스트할 것이 아니라 여러분이 세운 가정도 테스트해 보아야 한다.
7. 노력을 기울일 대상의 우선순위를 정하라.
8. 과거의 노예가 되지 말라. (P277-278)

<33. 리팩터링>
소프트웨어는 건축보다 오히려 정원일(gardening)에 더 가깝다. 딱딱하기 보다는 유기적인 존재다. (P291)

코드를 다시 작성하기, 다시 작업하기, 다시 설계하기는 총괄해서 ‘리팩토링’이라고 알려져 있다. (P292)

코드가 더 이상 잘 맞지 않아서 장애물에 부딪혔을 때, 사실은 하나로 합쳐져 있어야 할 두 개를 발견했을 때, 어떤 것이든 ‘잘못’되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안 된다. 언제나 바로 지금이 최적기다. (P292)

지금 리팩토링을 하지 않으면, 일이 더 진척되었을 때, 곧 신경 써야 할 의존성이 더 많이 생겼을 때 문제를 고치기 위해 훨씬 더 많은 시간을 투자해야 한다. 그때가 되면 일정에 더 여유가 생길까? 우리의 경험에 비추어 봤을 때 그런 일은 없다. 상사에게 이 점을 설명할 때 병을 비유로 들면 좋을 것이다. 리팩토링이 필요한 코드를 일종의 ‘종양’이라 생각하자. 종양을 제거하려면 수술이 필요하다. 지금 바로 수술해서 아직 종양이 작을 때 제거할 수도 있다. (P293)

<34. 테스트하기 쉬운 코드>
하드웨어에서 칩 차원의 테스트는 소프트웨어에서 단위 테스트와 대체로 동등한 것으로 볼 수 있다. 두 경우 모두 각 모듈의 동작을 검증하기 위해 다른 것들과 분리시켜 놓고 테스트가 이루어진다. (P301)

모듈을 설계할 때는, 심지어 루틴 하나를 설계할 때도, 그것이 지켜야 할 계약과 계약을 지키는지 테스트하는 코드도 함께 설계해야 한다. 테스트를 통과하고 계약을 지키는 코드를 설계하다 보면 자연스럽게 그렇게 설계하지 않았으면 생각나지 않았을 경계 조건이나 다른 문제들을 고려하게 된다. 애초에 에러가 나지 않게 하는 것보다 에러를 고치는데 더 좋은 방법은 없다. 사실 코드를 구현하기 전에 테스트를 먼저 만들어보면, 그 코드의 인터페이스가 고정되기 전에 미리 시험해 볼 수 있게 된다. (P304)

여러분이 작성하는 모든 소프트웨어는 언젠가는 테스트된다. 여러분이나 여러분 팀이 테스트하지 않으면, 결과적으로 사용자들이 테스트하게 된다. 따라서 소프트웨어를 철저하게 테스트할 계획을 세우는 것이 좋다. (P311)


[7장 프로젝트 전에]

<36. 요구사항의 구렁텅이>
완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 빼낼 것이 없을 때 얻게 되는 것이다. – 생텍쥐베리 ‘바람과 모래와 별들’ (P319)

요구사항은 아키텍처가 아니다. 요구사항은 설계가 아니며, 사용자 인터페이스도 아니다. 요구사항은 필요다. (P327)

프로젝트 용어사전을 만들고 유지하라. 그것은 프로젝트에서 사용되는 모든 용어와 어휘를 모아 놓은 단일한 장소여야 한다. 최종 사용자에서 보조 직원까지 프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어사전을 사용해야 한다. 이렇게 되려면 용어사전에 여러 사람이 접근하기 쉬워야 한다. 웹 기반 문서를 사용하는 것은 좋은 방법이다. (P330)

<38. 준비가 되어야만>
소프트웨어 개발은 아직 과학이 아니다. 여러분의 수행 능력에 직감이 일조하도록 놓아두라. (P339)

<39. 명세의 함정>
프로그램 명세화란 어떤 요구사항을 가져와 프로그래머가 자기 기술로 작업을 시작할 수 있는 시점까지 정리하는 과정이다. 명세화는 주요한 모호함들을 제거하는 등의 방법으로 세계를 설명하고 명확하게 만드는 의사소통의 한 행위다. (P341)


[8장 실용주의 프로젝트]

<43. 가차 없는 테스트>
개발자 대부분은 테스트를 싫어한다. 코드가 어디에서 깨지는지 무의식적으로 알고 약한 지점을 피해 다니면서, 살살 테스트하려 한다. 실용주의 프로그래머들은 다르다. 우리는 지금 당장 버그를 찾아 나서도록 내몰리지만, 그 대신 나중에 다른 사람이 자기 버그를 발견하는 되는 수치를 피할 수 있는 것이다. (P371)

일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. (P371)

* 소프트웨어 테스트 유형
1. 단위 테스트 : 모듈 테스트
2. 통합 테스트 : 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 테스트, 단위 테스트의 확장
3. 유효성 평가와 검증 : 최종 사용자 접근 방식에서 평가
4. 자원 고갈, 에러 그리고 복구 : 메모리, 디스크 공간, CPU 대역폭, 비디오 해상도 등
5. 성능 테스트 : 성능, 스트레스, 부하 테스트
6. 사용편의성 테스트 : 인간적 요소 고려 (P373)

현존하는 테스트의 그물을 빠져 나가는 버그가 있으면, 다음번에는 그걸 잡아낼 수 잇도록 새 테스트를 추가해야 한다. (P383)

<44. 결국은 모두 글쓰기>
아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다. – 중국 속담 (P385)

일반적으로, 개발자들은 문서화를 그리 대단하게 생각하지 않는다. 고작해야 그건 필요악이다. 최악의 경우 프로젝트가 끝날 무렵이면 관리자가 그것에 대해 까맣게 잊어버릴 것이라고 희망하면서 우선순위가 낮은 작업으로 취급한다. (P385)

코드와 문서를 결합시키는 아이디어는 리터릿 프로그래밍에 대한 도날드 크누쓰의 작업과 썬의 Javadoc 유틸리티에서 나타난다. (P385)

문서와 코드는 밑에 깔려 있는 동일 모델에 대한 서로 다른 뷰이지만, 다른 것이라곤 오직 뷰 뿐이다. 문서화가 프로젝트 작업흐름 주류에서 내쫓긴 2등 시민이 되게 하지 마라. 코드를 다룰 때와 똑 같은 관심을 문서화에도 주어야 한다. 그러면 사용자들(그리고 여러분 뒤의 유지보수자들)은 여러분을 기리며 노래 부를 것이다. (P393)