실용주의 프로그래머

프로그래머 블로그나 사이트에서 글을 보다보면 꼭 추천하는 책들이 있는데 이 책도 그 것들 중 하나다. 프로그래머를 위한 자기개발서 같은 느낌이다. 코딩 내적으로의 가르침뿐만아니라 외적으로 추구하거나 진행해야 하는 바에 대해서도 얘기해주 고 있다.

책을 읽을 때는 '아~ 이런부분은 나도 고려를 해야겠어' 하고 생각하지만, 읽고 얼마 시간이 지나면 까먹어 버릴 것이란걸 안다. 생각날때마다, 또는 주기적으로 읽어줘야 하겠다.

 

기억하고 싶은 내용

모든 개발 과정에서, 매일, 여러분이 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다. 절대 기계적으로 일하지 말라. 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라.

매일같이 지금 있는 기술들을 다듬고, 여러분 기술 목록에 새로운 도구들을 추가하라.

당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다. 업무 환경이 엉망인가? 하는 일이 지루한가? 문제를 고치기 위해 노력하라.

안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.

당장 풀고 있는 문제에만 정신을 쏟지 말고, 주변에서 무슨일이 벌어지는지 살펴 보라.

놀랍게도 많은 사용자가 멋지고 휘황찬란한 버전을 위해 일 년을 기다리느니 차라리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어 한다. 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달 할 수 있을 것이다.

ETC는 규칙이 아니라 가치다. 어떻게 가치를 내면화 할 수 있을까? 우리의 경험에 따르면 초기에는 어느 정도 의식적으로 노력해야 한다. 일주일 정도는 걸릴 수 있다. 스스로 자꾸 물어보라. '내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까?, 어렵게 만들었을까?' 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라.


DRY - don`t repeat yourself
ETC - easy to change
유사해 보이는 함수는 <GOF의 디자인 패턴> 에서 소개하는 전략 패턴(strategy pattern)을 사용하는 것으 추천
리팩터링 - 기회가 있을 때마다 코드의 구조와 직교성(결합도)을 개선하기 위해 노력하라
바꾸기 쉽게 만드는 것 - 외부의 API 를 여러분이 만든 추상화 계층 뒤로 숨겨라. 여러분의 코드를 여러 컴포넌트로 쪼개라.

시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.

프로토타이핑의 대상 - 증명되지 않았거나, 실험적이거나, 의심이 가는것, 마음이 편하지 않은 것 모두가 대상이 될 수 있다. 예를 들어, 어키텍처, 기존의 시스템에 추가할 새로운 기능, 외부 데이터의 구조 혹은 내용, 외부에서 가져온 도구나 컴포넌트, 성능문제, 사용자 인터페이스 설계 같은.

'프로젝트를 끝내는데 얼마나 걸릴까?' 같은 일정을 추정하기 위해서는

1. 무엇을 묻고 있는지 이해하라. 상대방이 무엇을 묻고 있는지 이해해야 한다. 요구하는 정확도 뿐만 아니라 도메인에 존재하는 조건에 대해서도 감을 잡을 필요가 있다.
2. 시스템의 모델을 만들어라. 의뢰인의 요청을 이해한 수에 간단하게 기본적인 것만 갖춘 대략적인 모델을 만들어 보라. 어느 수준까지 모델을 정교하게 만들어야 할지는 여러분의 경험이 이야기 해 줄것이다.
3. 모델을 컴포넌트로 나눠라. 다 만든 모델은 컴포넌트로 분해할 수 있다. 이제 이러한 컴포넌트들이 어떻게 상호 작용하는지를 수식으로 기술해야 한다. 대부분의 컴포넌트에는 각 컴포넌트가 어떻게 전체 모델에 기여하는지를 나태내는 매개변수가 있다. 이 단계에서는 일단 매개 변수를 찾기만 하면된다.
4. 각 매개 변수에 값을 할당하라. 결과에 가장 큰 영향을 미치는 매개변수를 찾아서 이 매개변수의 값을 최대한 정확하게 산출해 내는 것이 중요하다. 단순히 더해지는 값보다는 곱하거나 나누는 값이 결과에 큰 영향을 미친다. 주요 매개 변수를 계산할 때는 나름의 근거가 있어야 한다. 실제 시간당 요청수를 측정해 보거나, 측정할 수 있는 비슷한 시스템을 찾아보아야 할 것이다. 실제로 추정을 하다보면 다른 하위 추정치를 계산하는 경우가 있는데, 이때 큰 오차가 슬그머니 기어들어 올 확률이 높다.
5. 답을 계산하라. 주요 매개변수들의 값을 변경시켜 가면서 여러번 계산해보고, 이 가운데 어떤 것이 모델에 잘 들어맞는지 찾아내라.
6. 여러분의 추정 실력을 기록하라. 추정치가 나중에 실제 결과에 얼마나 가까웠는지를 평가해 보면 좋다. 그리고 왜 틀렸는지를 찾아라. 원인이 무엇이든 시간을 들여 이를 규명하라. 다음 추정치는 훨씬 나아질 것이다.

어느 정도 에디터를 써야 유창하다고 볼 수 있을까? 아래의 과제들을 마우스나 트랙패드 없이 모두 수행할 수 있는가?

• 텍스트를 편집할 때 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용을 선택하라.
• 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서를 이동하라.
• 변경한 코드의 들여쓰기를 자동으로 맞춰라.
• 여러줄의 코드를 명령 하나로 주석 처리 했다가 다시 주석 해제하라
• 실행 취소를 여러번 했다가 취소한 명령을 재실행 기능으로 다시 수행하라
• 에디터 창을 여러 구역으로 쪼개라. 그리고 각 구역 사이를 이동하라.
• 특정 줄 번호로 이동하라
• 여러줄을 선택한 후 가나다 순으로 정렬하라.
• 문자열로, 또 정규 표현식으로 검색하라.
• 선택 영역에서 패턴 검색을 이용하여 일시적으로 여러 개의 커서를 만든다음, 동시에 여러 곳을 텍스트를 편집하라.
• 현재 프로젝트의 컴파일 오류를 표시하라
• 현재 프로젝트의 테스트를 실행하라

버그를 고치는 첫걸음으로 가장 좋은 것은 그 버그를 재현할 수 있게 만드는 것이다.

'있을 수 없는 일'이 발생했을 때 우리는 그 사실을 알아야 한다. 이것이 모든 케이스/스위치 문에 디폴트 구문을 달아야 하는 이유다.

 

상속의 대안

• 인터페이스와 프로토콜
• 위임
• 믹스인과 트레이트

가끔은 코드가 여러분의 뇌에서 에디터로 거침없이 술술 옮겨지고, 생각을 비트로 바꾸는 일이 전혀 힘들지 않은 날이 있다. 반면에 코딩이 진창에서 오르막길을 걷는 것처럼 느껴지는 날도 있다. 일단, 하고 있는 일을 멈춰라. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보하라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 산책을 하고 점심을 먹고 다른 사람과 수다를 떨어라. 아예 하룻밤 자면서 생각을 해봐도 된다. 언젠가는 다시 생각이 의식의 영역으로 올라와서 '아하!'하는 순간이 찾아올 것이다. 여러분 뇌의 다른 부위에 문제를 노출하라. 그리고 여러분이 어려움을 겪는 부분을 더 잘 처리할 수 있는 부위가 있는 지 보라. 

 

의도적으로 프로그래밍을 해야 한다. 

자신도 잘 모르는 코드를 만들지 말라.

계획을 세우고 그것을 바탕으로 진행하라. 

신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라.

가정을 기록으로 남겨라. 

여러분이 세운 가정도 테스트해 보아야 한다.

노력을 기울일 대상의 우선순위를 정하라. 중요한 것을 먼저 시간을 투자하라.
기존의 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라. 

코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해 보라. 결과를 그래프로 그려보자. 금방 그래프 선이 어떤 모양인지 감을 잡을 수 있을 것이다. 

 

리팩터링은 언제 하는가? 

중복 코드를 발견했을 때.

직교적이지 않은 설계를 확인했을 때

사물의 변화, 요구사항의 변경, 여러분의 지식의 증가로 인해 더 이상 유효하지 않은 지식이 생겼을때

사용 사례를 통해 중요한 기능과 필요 없는 기능을 알게되었을 때

성능의 개선이 필요할 때

테스트 통과 후

 

소프트웨어에 회로판이나 칩처럼 '테스트용 핀'은 없지만, 어떤 모듈의 내부 상태를 디버거 없이 다양한 형태로 볼수 있는 방법을 제공할 수 있다. 로그 파일에 쌓이는 추적(trace) 메시지가 이런 메커니즘 가운데 하나다. '단축키'조합이나 숨겨진 URL 방식도 있다. 보통 최종 사용자에게는 이런 것이 있다는 사실을 알리지 않겠지만, 고객 지원실에 있는 사람들에게는 매우 유용한 도구가 될 수 있다. 

 

프로그래밍에서는 이름이 "모든 것!"이다. 우리는 이름을 붙인다. 애플리케이션, 서브시스템, 모듈, 함수, 변수 등 새로운 것을 끊임없이 만들고 그것에 이름을 부여한다. 그리고 이름은 아주 아주 중요하다. 이름은 여러분의 의도와 믿음을 잔뜩 드러내기 때문이다. 우리는 코드에서 하는 역할에 따라 이름을 지어야 한다고 믿는다. 즉, '내가 이것을 왜 만드는 거지?' 하고 생각해야 한다는 뜻이다. 

 

우리의 경험상 최초의 요청 사항은 궁극적인 요구 사항이 아니다. 의뢰인의 요청 사항은 사실 함께 탐허을 떠나자는 초대장이다. 의뢰인이 미처 고려해 보지 않은 문제도 있을 것이다. 좋은 개발자라면 협상 능력을 키울 수 있는 상황이기도 하다. 의뢰인의 머릿속 깊숙이 들어갈 수 있는 단순한 기법이 있다. 의뢰인이 되어 보는 것이다. 수작업 재고 관리 시스템을 자동화 하고 있는가? 창고에서 일주일만 일해보라. 

 

의뢰인이 프로그래머를 고용하는 이유는 의뢰인은 고차원적이고 모호한 측면이 있느 문제를 풀고 싶어 하는 반면, 프로그래머는 세부 사항과 미묘한 차이 하나하나에 관심을 두기 때문이다. 요구사항 문서는 개발자를 위해서 쓰는 것이다. 

 

훌륭한 프로젝트팀은 뚜렷한 특성이 있다. 사람들은 이 팀과의 회의를 기대한다. 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문이다. 이들이 생산해 내는 문서는 깔끔하고 정확하며 일관적이다. 

 

자동화는 모든 프로젝트 팀에서 필수 불가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 뱁포를 자동화하는 도구르 만들고 적용하라. 

 

버전관리, 회귀 테스트, 전체 자동화, 이 셋은 모든 프로젝트를 지탱하는 기둥이다. 

 

여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정하 ㄴ여러분의 직함은 "문제 해결사"다. 이것이 우리가 하고 있는 일이고, 실용주의 프로그래머의 본질이다. 우리는 문제를 해결한다. 

 

 

수록 팁

1. 자신의 기예(craft)에 관심을 가져라
- 소프트웨어 개발을 잘하고 싶지 않다면 왜 여기에 인생을 바치고 있는가?

2. 자기 일에 대해 생각하라
- 자동 조종 장치를 끄고 직접 조종하라. 자신의 작업을 끊임없이 비판적으로 살펴보라

3. 당신에게는 에이전시가 있다
- 당신의 인생이다. 꽉 움켜쥐고, 원하는 바를 이루어라

4. 어설픈 변명 말고 대안을 제시하라
- 변명하는 대신 대안을 제시하라. 그 일을 할 수 없다고 말하지 말고, 무엇을 할 수 있는지 설명하라

5. 깨진 창문을 내버려 두지 말라
- 눈에 뛰일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라

6. 변화의 촉매가 되라
- 사람들에게 변화를 강요할 수는 없다. 대신 미래가 어떤 모습일지 보여주고, 미래를 만드는 일에 그들이 참여하도록 하라

7. 큰 그림을 기억하라
- 주변에 무슨 일이 일어나는지 점검하는 걸 잊을 정도로 세부 사항에 빠지지 마라

8. 품질을 요구 사항으로 만들어라
- 프로젝트의 진짜 품질 요구 사항을 결정하는 자리에 사용자를 참여시켜라

9. 지식 포트폴리오에 주기적으로 투자하라
- 학습을 습관으로 만들어라

10. 읽고 듣는 것을 비판적으로 분석하라
- 벤더, 매체들의 야단법석, 도그마에 흔들리지 말라. 여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.

11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다
- 한국어든 영어든 하나의 프로그래밍 언어인 것처럼 다뤄라. 문서 작성도 코드를 작성하듯이 하라. DRY 원칙, ETC, 자동화 등을 지켜라.

12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다
- 효과적으로 전달하지 못하면 좋은 생각이 있어봐야 소용 없다

13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
- 코드와 별개로 만든 문서가 정확하거나 최신정보를 잘 반영하기는 힘들다.

14. 좋은 설계는 나쁜 설계보다 바뀌기 쉽다
- 어떤 게 잘 설계되었다는 건 그 물건이 사용하는 사람에게 적응하여 맞춰진다는 것이다. 이 말을 코드에 적용해 보면, 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다.

15. DRY: 반복하지 말라 Don`t Repeat Yourself
- 모든 지식은 시스템 내에서 단 한번만, 애매하지 않고, 권위 있게 표현되어야 한다

16. 재사용하기 쉽게 만들어라
- 재사용하기 쉽다면 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들어라.

17. 관련 없는 것들 간에 서로 영향이 없도록 하라
- 컴포넌트를 자족적이고, 독립적이며 단 하나의 잘 정의된 목적만 갖도록 설계하라

18. 최종 결정이란 없다
- 돌에 새겨진 것처럼 바뀌지 않는 결정은 없다. 모든 결정이 바닷가의 모래 위에 쓰인 글씨라 생각하고 변화에 대비하라.

19. 유행을 쫓지 말라
- 닐 포드가 말했다. "어제의 모범 사례는 내일의 나쁜 사례가 된다." 유행이 아니라 본질을 보고 아키텍처를 선택하라.

20. 목표물을 찾기 위해 예광탄을 써라
- 예광탄은 일들을 시도해 보고 그것들이 목표와 얼마나 가까운 곳에 떨어지는지 봄으로써 목표를 정확히 맞히게 해준다.

21. 프로토타이핑으로 학습하라
- 프로토타이핑은 학습 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다.

22. 문제 도메인에 가깝게 프로그래밍하라
- 사용자의 언어를 사용해서 설계하고 코딩하라

23. 추정으로 놀람을 피하라
- 시작하기 전에 추정부터 하라. 잠재적인 문제점을 미리 발견할 수 있을 것이다.

24. 코드와 함께 일정도 반복하며 조정하라.
- 구현하면서 얻는 경험을 바탕으로 프로젝트의 소요 시간을 재조정하라.

25. 지식을 일반 텍스트로 저장하라.
- 일반 텍스트 형식은 시간이 지나도 못 쓰게 되는 일이 없다. 일반 텍스트 형식은 기존 도구를 사용할 수 있고 디버깅과 테스트를 쉽게 만든다.

26. 명령어 셀의 힘을 사용하라.
-그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.

27. 에디터를 유창하게 쓸 수 있게 하라.
- 에디터는 가장 중요한 도구다. 필요한 일을 빠르고 정확하게 하는 방법을 익혀라.

28. 언제나 버전 관리 시스템을 사용하라.
- 버전 관리 시스템은 여러분의 직업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.

29. 비난 대신 문제를 해결하라.
- 버그가 여러분의 잘못인지 다른 사람의 잘못인지는 중요하지 않다. 어쨌거나 그 버그는 여러분의 문제고, 고쳐야 한다.

30. 당황하지 말라.
- 숨을 깊게 들이쉬고 무엇이 버그의 원인인지 생각하라.

31. 코드를 고치기 전 실패하는 테스트부터.
- 코드를 고치기 전에 버그 재현에 초점을 둔 테스트부터 만들어라.

32. 그놈의 오류 메세지 좀 읽어라.
- 대부분의 예외는 무엇이 어디서 실패했는지 알려준다. 운이 좋으면 어떤 매개 변수가 쓰였는지도 알 수 있다.

33. "select" 는 망가지지 않았다.
- OS나 컴파일러의 버그를 만나는 일을 정말 드물다. 심지어 외부 제품이나 라이브러리일지라도 드문 일이다. 버그는 여러분의 애플리케이션에 있을 가능성이 가장 크다.

34. 가정하지 말라. 증명하라.
- 진짜 데이터와 경계 조건을 사용하여 실제 환경에서 여러분의 가정을 증명하라.

35. 텍스트 처리 언어를 익혀라.
- 여러분은 매일 많은 시간을 텍스트와 씨름하며 보낸다. 왜 그중 일부를 컴퓨터에게 맡기지 않는가?

36. 여러분은 완벽한 소프트웨어를 만들 수 없다.
- 소프트웨어는 완벽할 수 없다. 불가피한 오류로부터 여러분의 코드와 사용자를 보호하라.

37. 계약으로 설계하라.
- 코드는 많지도 적지도 않게 자신의 일이라고 주장하는 만큼의 일만 해야 한다. 이를 계약으로 문서화하고 검증하라.

38. 일찍 작동을 멈춰라.
- 일반적으로 죽은 프로그램은 이상한 상태의 프로그램보다 훨씬 피해를 적게 끼친다.

39. 단정문으로 불가능한 상황을 예방하라.
- 일어날 수 없는 일이라면 단정(assertion)으로 일어나지 않는 것을 확인하라. 단정은 여러분의 가정을 검증한다. 불확실한 세상에서 단정으로 여러분의 코드를 보호하라.

40. 자신이 시작한 것은 자신이 끝내라.
리소스를 할당한 함수나 객체가 가급적 리소스를 해제하는 책임도 져야 한다.

41. 지역적으로 행동하라
- 변경 가능한 변수나 리소스의 유효 범위를 짧고 눈에 잘 들어오게 만들어라.

42. 작은 단계들을 밟아라. 언제나.
- 언제나 작은 단계를 밟고, 더 진행하기 전에 피드백을 확인하고 조정하라.

43. 예언하지 말라.
- 여러분이 볼 수 있는 만큼만 내다보라.

44. 결합도가 낮은 코드가 바꾸기 쉽다.
- 여러가지를 묶어서 결합도가 높아지면 딱 하나만 바꾸기가 어려워진다.

45. 묻지 말고 말하라
- 객체에게 값을 얻은 다음, 변환한 후 결과를 다시 객체에 붙이지 말라. 객체가 직접 처리하도록 하라.

46. 메서드 호출을 엮지 말라.
- 무언가에 접근할 때 마침표를 딱 하나만 쓰려고 노력하라.

47. 전역 데이터를 피하라.
- 전역 데이터는 모든 메서드에 매개 변수를 추가하는 것과 마찬가지다.

48. 전역적이어야 할 만큼 중요하다면 API로 감싸라.
- 하지만 정말 정말 전역적이어야 할 때만 써야 한다.

49. 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.
- 모든 프로그램은 데이터를 변환한다. 받은 입력을 출력으로 바꾼다. 변환을 사용하여 설계하라.

50. 상태를 쌓아 놓지 말고 전달하라.
- 함수나 모듈 안에서 데이터를 계속 보관하지 말라. 꺼내어 전달하라.

 

51. 상속세를 내지 말라. 

- 상황에 맞게 인터페이스, 위임, 믹스인 같은 대안을 사용하라. 

 

52. 다형성은 인터페이스로 표현하는 것이 좋다. 

- 인터페이스는 상속으로 인한 결합 없이도 명시적인 다형성을 만들어 준다. 

 

53. 서비스에 위임하라. Has-A 가 Is-A 보다 낫다. 

- 서비스를 상속하지 말고 객체 안에 소유하라. 

 

54. 믹스인으로 기능을 공유하라. 

- 믹스인으로 상속세 없이 여러 클래서에 기능을 추가할 수 있다. 인터페이스와 함께 사용하여 고통 없는 다형성을 구현하라. 

 

55. 외부 설정으로 애플리케이션을 조정할 수 있게 하라. 

- 애플리케이션이 출시된 이후 바뀔 수도 있는 값에 코드가 의존하고 있다면, 그 값을 애플리케이션 외부에서 관리하라. 

 

56. 작업 흐름 분석으로 동시성을 개선할. 

- 사용자의 작업 흐름 속에 있는 동시성을 최대한 활용하라. 

 

57. 공유 상태는 틀린 상태다. 

- 공유 상태는 버그로 가득 찬 상자를 열어젖힌다. 재부팅 말고는 방법이 없는 경우가 많다. 

 

58. 불규칙한 실패는 동시성 문제인 경우가 많다. 

-  타이밍과 전후 상황의 변화가 동시성 버그를 드러낼 수 있다. 하지만 비일관적이고 재현이 힘들 것이다. 

 

59. 공유 상태 없는 동시성을 위하여 액터를 사용하라. 

- 액터를 사용하여 외부 동기화 없이 동시에 상태를 관리하라. 

 

60. 칠판으로 작업 흐름을 조율하라. 

- 칠판을 사용하여 참여자들의 독립성과 고립성을 유지시키면서도 개별적인 사실과 에이전트들을 조율하라. 

 

61. 여러분 내면의 파충류에게 귀 기울여라. 

- 코드가 반발하는 것처럼 느껴진다면, 사실은 여러분의 무의식이 무엇인가 잘못되었다고 말하려는 것이다. 

 

62. 우연에 맡기는 프로그래밍을 하지말라. 

- 믿을 만한 것만 믿어야 한다. 우발적인 복잡성에 주의하고, 우연한 행운을 목적을 가지고 세운 계획으로 착각하지 말라. 

 

63. 사용하는 알고리즘의 차수를 추정하라. 

- 코드를 작성하기 전에 실행 시간이 얼마나 걸릴지 대략이라도 감을 잡아라. 

 

64. 여러분의 추정을 테스트하라. 

- 알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다. 실제 환경에서 코드의 수행 시간을 측정해 보라. 

 

65. 일찍 리팩터링하고 자주 리팩터링하라. 

- 전원의 잡초를 뽑고 식물 배치를 바꾸는 것과 같이 코드도 필요할 때마다 다시 작성하고, 다시 작업하고, 아키텍처를 다시 만들라. 근본적인 문제를 해결하라. 

 

66. 테스트는 버그를 찾기 위한 것이 아니다. 

- 테스트는 여러분의 코드를 보는 한 관점이다. 코드의 설계, API, 결합에 대한 피드백을 준다. 

 

67. 테스트가 코드의 첫 번째 사용자다. 

- 테스트가 주는 피드백으로 코드의 방향을 잡아라. 

 

68. 상향식이나 하향식이 아니라 끝에서 끝까지(end to end) 만들어라. 

- 끝에서 끝을 잇는 조그만 기능 조각들을 만들고, 그 과정에서 문제에 대하여 배워라. 

 

69. 테스트할 수 있도록 설계하라. 

- 코드를 쓰기 전 테스트에 대해 먼저 생각하라. 

 

70. 여러분의 소프트웨어르 테스트하라. 그러지 않으면 사용자가 테스트하게 된다. 

- 가차 없이 테스트하라. 사용자가 여러분 대신 버그를 찾도록 하지 말라. 

 

71. 속성기반 테스트로 가정을 검증하라. 

- 속성기반 테스트는 여러분이 절대 시도해 보지 않을 만한 것들을  시도하고, 여러분이 의도하지 않은 방식으로 여러분의 코드를 사용할 것이다. 

 

72. 단숨함을 유지하고 공격 표면을 최소화 하라. 

- 복잡한 코드는 버그의 온상이고, 공격자가 뚫고 들어올 여지도 높인다. 

 

73. 보안 패치르 신속히 적용하라. 

- 공격자들은 최대한 빨르게 취약점을 공격한다. 여러분은 더 빨라야 한다. 

 

74. 이름을 잘 지어라. 필요하면 이름을 바꿔라. 

- 읽는 사람에게 의도를 표현할 수 있는 이름을 붙이고, 의도가 변하자마자 이름을 바꿔라. 

 

75. 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다. 

- 어쩌면 전반적인 방향은 알 수 있지만, 다양한 경우를 속속들이 알지는 못한다. 

 

76. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. 

- 소프트웨어 개발은 사용자와 프로그래머의 공동 창작 작업이다. 

 

77. 요구 사항은 피드백을 반복하며 알게 된다. 

- 요구 사항을 이해하려면 탐험과 피드백을 거쳐야 한다. 결정한 요구 사항의 여파를 바탕으로 처음의 발상을 다듬는다. 

 

78. 사용자처럼 생각하기 위해 사용자와 함께 일하라. 

- 시스템이 정말로 어떻게 사용될지 통찰을 얻을 수 있는 가장 좋은 방법이다. 

 

79. 정책은 메타데이터다. 

- 정책을 시스템 코드 안에 고정하지 말라. 대신 시스템이 사용하는 메타 데이터로 표현하라. 

 

80. 프로젝트 용어 사전을 사용하라. 

- 프로젝트에서 쓰이는 용어와 어휘들을 모두 한곳에 모으고 관리하라. 

 

81. 생각의 틀을 벗어나지 말고, 틀을 찾아라.

- 불가능한 문제와 마주쳤다면 진짜 제약 조건을 찾아라. 스스로 물어보라. '정말로 반드시 이렇게 해야 하나? 꼭 해야하는 일이긴 한가?'

 

82. 코드에 혼자 들어가지 말라. 

- 프로그래밍은 어렵고 힘들 수 있다. 친구와 함께 가라. 

 

83. 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다. 

- 애자일은 형용사다. 즉, 무언가를 하는 방식이다. 

 

84. 작고 안정적인 팀을 유지하라. 

- 팀은 작고 안정적이어야 한다. 모두가 서로를 신뢰하고 의존해야 한다. 

 

85. 실현하려면 계획하라. 

- 계획하지 않으면 실현되지 않을 것이다. 회고, 실험, 학습, 기술, 연마를 계획하라. 

 

86. 모든 기능을 갖춘 팀을 조직하라. 

- 직무가 아니라 기능성을 중심으로 팀을 조직하라. UI/UX  디자이너와 코더를 분리하거나, 프론트엔드와 백엔드, 테스터와 데이터 모델러, 설계와 배포를 분리하지 말라. 코드를 처음부터 끝까지 점진적이고 반복적으로 만들 수 있는 팀을 조직하라.

 

87. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라. 

- 다른 회사가 쓴다는 이유만으로 개발 방법론이나 기법을 도입하지 말라. 여러분의 팀과 여러분의 환경에 잘 맞는 것을 도입하라. 

 

88. 사용자에게 필요할 때 제공하라. 

- 프로세스가 그렇다는 이유만으로 몇 주 혹은 몇 달이나 기다리게 하지 말라. 

 

89. 버전 관리 시스템으로 빌드, 테스트, 릴리스르 운용하라. 

- 커밋이나 푸시로 빌드, 테스트, 릴리스를 시작시켜라. 버전 관리 시스템의 태그로 서비스 배포 여부를 지정하라. 

 

90. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. 

- 빌드 때마다 도는 테스트는 책장에 꽂혀있는 테스트 계획보다 훨씬 효과적이다. 

 

91. 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다. 

- 당연하다. 

 

92. 버그를 심어 놓고 테스트를 테스트 하라.

- 소스 코드의 복사본에 고의로 버그를 심어놓고 테스트가 잡아내는지 검증하라. 

 

93. 코드 커버리지만 올리지 말고 상태 조합을 테스트하라. 

- 중요한 프로그램 상태들을 파악해서 테스트하라. 코드의 각 행을 테스트 했다는 것만으로는 부족하다. 

 

94. 버그는 한 번만 잡아라. 

- 한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안된다. 그 이후로는 자동화 테스트가 확인해야 한다. 

 

95. 수작업 절차를 사용하지 말라.

- 컴퓨터는 똑같은 명령을 똑같은 순서로 반복해서 실행할 것이다. 

 

96. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라. 

- 사용자의 사업 가치를 창조하는 해법을 개발하라. 그리고 매일 사용자를 기쁘게 하라. 

 

97. 자신의 작품에 서명하라. 

- 옛 장인들은 자신의 작품에 서명하는 것을 자랑스러워했다. 여러분도 그래야 한다. 

 

98. 먼저, 해를 끼치지 말라

- 실패는 피할 수 없다. 그로 인해 누구도 고통받지 않게 하라

 

99. 쓰레기 같은 인간을 돕지 말라. 

- 여러분도 똑같은 인간이 되고 말 것이다. 

 

100. 결국 당신의 삶이다. 삶을 사람들과 나누고, 삶을 축하하고, 삶을 만들어가라. 그리고 그걸 즐겨라!

- 우리에게 주어진 놀라운 삶을 즐기고, 위대한 일을 하라.