open:실용주의-프로그래머 [EL]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# 실용주의 프로그래머

{{tag>실용주의 프로그래머 책}}

# 실용주의 프로그래머 TIPS 1/4


# 1. 자신의 기술(craft)에 관심과 애정을 가져라.

소프트웨어 `개발`을 잘 해보려는 생각이 없다면 왜 `인생`을 그 일을 하면서 보내는가?

# 2. 자신의 일에 대해 생각하면서 일하라!

자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라. 

# 3. 어설픈 변명을 만들지 말고 대안을 제시하라.

변명하는 대신 `대안을 제시`하라. 그 일을 할 수 없다고 말하지 말고, 무었을 할 수 있는지에 대해 설명하라.

# 4. 깨진 창문을 내버려두지 말라.

눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라. 

  깨진 유리창 이론(영어: Broken Windows Theory, BWT)은 미국의 범죄학자인 제임스 윌슨과 조지 켈링이 1982년 3월에 공동 발표한 깨진 유리창(영어: Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities)이라는 글에 처음으로 소개된 사회 무질서에 관한 이론이다. 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다.

# 5. 변화의 촉매가 되라.

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

# 6. 큰 그림을 기억하라.

주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.

# 7. 품질을 요구사항으로 만들어라.

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

# 8. 지식 포트폴리오에 주기적으로 투자하라.

`학습을 습관으로` 만들어라.

# 9. 읽고 듣는 것을 비판적으로 분석하라. 

벤더, 매체들의 야단법석, 도그마에 흔들리지 말라. 여러분과 여러분 프로젝트의 관점에서 `정보를 분석`하라.

# 10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.

`효과적으로 전달`하지 못한다면 좋은 생각이 있어봐야 소용없다. 

# 11. DRY - 반복하지 마라 (Don't Repeat Yourself)

어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 `하나뿐인 표현`을 가져야 한다. `DRY`

# 12. 재사용하기 쉽게 만들라.

재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라. `REUSE`

# 13. 관련 없는 것들 간에 서로 영향이 없도록 하라. 

컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의도니 목적만 갖도록 설계하라. `직교성`

# 14. 최종 결정이란 없다. 

돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 `변화에 대비`하라.

# 15. 목표물을 찾기 위해 예광탄을 써라. 

`예광탄`은 `이것저것을 시도`해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다. 

# 16. 프로토타입을 통해 학습하라. 

`프로토타이핑`은 `배움의 경험`이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교훈에 있다. 

# 17. 문제 도메인에 가깝게 프로그래밍하라. 

`사용자의 언어`를 사용해서 설계와 코딩을 하라.

{{tag>실용주의 프로그래머 책}}

## 참고

- 코드 생성에 대해서는 `Code Generation in Action`(Jack Herrington, Manning, 2003) 이라는 책을 참고
- MS Word 등으로 문서를 만들고 그 안에 포함된 테스트를 자동으로 실행할 수 있다. http://fit.c2.com 와 `FIT for Developing Software`(Prantice-Hall, 2005)를 참고
- 싱글톤의 적절한 사용법에 대해서는 레인스버거(J.B.Rainsberger)의 `Use Your Singletons Wisely`(http://www-128.ibm.com/developerworks/webservbices/library/cosingle.html)을 참고
- `Art of UNIX Programming`(에릭 S. 레이몬드, 정보문화사, 2004)
- 포스트잇과 같은 로우테크 툴을 이용한 프로토타이핑에 대해 탁월한 서적이 있다. `Paper Prototyping`(Corolyn Snyder, Morgan Kaufman, 2003)을 참고
- 포스트잇의 활용법에 대해서는 `포스트잇 100% 활용법`(데이빗 스트레이커, 윈윈북스, 2004)를 추천
- 슈레이즈(Michael Schrage)는 `초일류 기업의 성공 비밀, 시리어스 플레이`(세종서적, 2001)에서 프로토타이핑 속도가 혁신에 뛰어난 조직과 그렇지 못한 조직을 결정짓는 주된 요소라 말한다.
- `생각하는 프로그래밍`(인사이트, 2003, 원제는 Programming Pearls)을 쓴 존 벤틀리(Jon Bentley)는 그 책의 후속작 `More Programming Pearls`(Addison Wesley, 1988)에서 작은 언어(Little Language)에 대해 하나의 칼럼을 할애, 탁월한 설명을 한다. (이 칼럼은 CACM 아카이브에서 볼 수 있다.)
- '밑에서부터 프로그래밍 하기' (http://www.paulgraham.com/progbot.html)
- 추정과 리스크 관리에 대해 더 알고 싶다면 톰 디마르코와 티모시 리스터의 `소프트웨어 프로젝트에서의 리스크 관리`(인사이트, 2004, 원제는 Waltzing with Bears)를 참고
- 빌드 자동화에 대한 자세한 내용은 `실용주의 프로그래머를 위한 프로젝트 자동화`(마이크 클라크, 인사이트, 2005)에 잘 정리되어 있다.
- 가장 널리 쓰이는 SCCS 가운데 하나인 CVS 에 대해서는 `실용주의 프로그래머를 위한 버전 관리 using CVS`를 참고
- 로버트 C. 마틴이 쓴 `Agile Software Development`(Prentice Hall, 2002, 번역서는 '소프트웨어 개발의 지혜')
- 리팩터링에 대해서는 마틴 파울러의 `Refactoring`(대청, 2002) 외에 `Refactoring Workbook`(William C. Wake, Addision Wesley, 2004), `Refactoring to Pattern`(Joshua Kerievsky, Addison Wesley, 2005), `테스트 주도 개발`(켄트 백, 인사이트, 2005) 등의 책을 참고
- 유스 케이스는 `Writing Effective UseCases`(Addison-Wesley Professional, 2000)을 참고
- 제랄드 와인버그의 `Are Your Lights On?`(Dorset House, 1990)은 문제가 뭔지 생각하는 데에 도움을 주는 책이다.




# 공부해 볼 언어

- Haskell
- Lisp
- Smalltalk
- Rubu/Python
- Erlang
- Prolog
- Self


# 전문가 단체

- Association for Computing Machinery (ACM)
- IEEE 컴퓨터 협회 (IEEE Computer Society)

# 정기 간행물

- IEEE Computer
- IEEE Software
- Communications of the ACM (CACM)
- SIGPLAN
- Dr. Dobbs Journal
- The Perl Journal
- Software Development Magazine

# 책

## 분석과 설계

- Object-Oriented Software Construction, 2nd Edition
- Design Patterns
- Analysis Patterns

## 팀과 프로젝트

- The Mythical man Month
- Dynamics of Software Development
- Surviving Object-Oriented Projects: A Manager's Guide

## 특정한 환경

### Unix

- Advanced Programming in the Unix Environment
- Unix Network Programming

### Windows

- Win32 System Services
- Programming Windows

### C++

- Effective C++
- More Effective C++
- Large-Scale C++ Software Design
- Advanced C++ Programming Styles and Idioms

# 웹

- Slashdot (www.slashdot.org)
- Cetus Links (www.cetus-links.org)
- WikiWikiWeb (www.c2.com)

# 편집기

- Emacs (www.gnu.org)
- XEmacs (www.xemacs.org)
- vi (www.vim.org)
- elvis 편집기
- Emacs Viper 모드

# 컴파일러, 프로그래밍 언어, 개발 도구

- GNU C/C++ 컴파일러 (www.gnu.org/software/gcc/gcc.html)
- Java (java.sun.com)
- Perl (www.perl.com)
- Python (www.python.org)
- SmallEiffel (smalleifeel.loria.fr)
- ISE Eiffel (www.eiffel.com)
- Sather (www.icsi.berkeley.edu/~sather)
- VisualWorks (www.cincom.com)
- Squeak (www.squeak.org)
- TOM 프로그래밍 언어 (www.gerbil.org/tom)
- Beowulf 프로젝트 (www.beowulf.org)
- iContract - Java 언어용 계약에 의한 설계 (www.reliable-systems.com)
- Nana - C 와 C++를 위한 로깅과 단정(assertion) 기능을 제공하는 라이브러리 (www.gnu.org/software/nana)
- DDD - Data Display Debugger (www.gnu.org/software/ddd)
- John Brant 의 리팩터링 브라우저 (st-www.cs.uiuc.edu/users/brant/Refactory)
- DOC++ 문서 생성기 (www.docpp.sourceforge.net)
- xUnit - 단위 테스트 프레임워크 (www.XProgramming.com)
- Tcl 언어 (www.scriptics.com)
- Expect - 대화형 프로그램 자동화 프로그램 (expect.nist.gov)
- T Spaces (www.almaden.ibm.com/cs/TSpaces)
- javaCC - 자바 컴파일러 (https://javacc.dev.java.net)
- bison 파서 생성기 (www.gnu.org/software/bison/bison.html)
- SWIG - Simplified Wrapper and Interface Generator
- The Object Management Group, Inc. (www.omg.org)
- UWIN 개발 도구들 (www.research.att.com/sw/tools/uwin)
- Cygnus 사의 Cygwin 도구들 (www.cygwin.com)
- Perl Power Tools (sourceforge.net/projects/ppt)

## 소스코드 관리 도구

- RCS - Revision Control System (www.gnu.org/software/rcs/rcs.html)
- CVS - Concurrent Version System (www.cvshome.org)
- Aegis 트랜잭션 기반 형상 관리 (aegis.sourceforge.net)
- ClearCase (www.rational.com)
- MKS Source Integrity (www.mks.com)
- PVCS 형상 관리 (www.merant.com)
- Visual Sourcesafe (www.microsoft.com)
- Perfoce (www.perfoce.com)

## 기타 도구

- WinZip - 윈도우용 압축 유틸리티 (www.winzip.com)
- Z 셸 (www.zsh.org)
- Unix 시스템용 공개 SMB 클라이언트 (www.samba.org)

# 논문과 출판된 글

- [The comp.object FAQ](http://www.cyberdyne-object-sys.com/oofaq)
- [eXtreme Programming](http://www.XProgramming.com)
- [엘리스테어 코번(Alistair Cockburn)의 홈페이지](http://www.alistair.cockburn.us)
- [마틴 파울러(Martin Fowler)의 홈페이지](http://www.martinfowler.com)
- [로버트 마틴(Robert Martin)의 홈페이지](http://objectmentor.com)
- [Aspect-Oriented Development](http://aosd.net)
- JavaSpaces 명세 (java.sun.com/developer/products/jini/index.jsp)
- Netscape 소스코드 (www.mozilla.org)
- Jargon File (www.jargon.org)
- 에릭 레이몬드(Eric S. Raymond)의 글 (http://catb.org/~esr)
  - 성당과 시장(The Catherdral and the Bazzar)
  - 사고공간을 개척하기(Homesteading the Noosphere)
- K 데스크톱 환경 (www.kde.org)
- GNU Image Manipulation Program (GUN 이미지 조작 프로그램) (www.gimp.org)
- 디미터(Demeter) 프로젝트 (www.ccs.neu.edu/research/demeter)

## 기타

- GNU 프로젝트 (www.gnu.org)
- 웹 서버 정보 (www.netcraft.com/survey/server.html)


## 참고

- [개발자들이 알아두면 좋은 사이트](http://egloos.zum.com/hyun924/v/5104585)
- [Korea Tcl/Tk Community](http://tcltk.co.kr/node/311)
- [[001] 형상 관리 도구? 버전 관리 도구?](http://www.whatwant.com/290)


{{tag>실용주의 프로그래머 책}}

# 실용주의 프로그래머들의 특징

- 얼리어덥터 성향 / 새로운 것에 빨리 적응하는 성향. `자신감`
- 캐묻기 좋아한다.
- 비판적인 사고의 소유자
- 현실적이다
- 다방면의 기술에 익숙하다.

그들은 직면한 문제 너머를 생각하며, 문제를 항상 더 `큰 맥락`에 놓으려 노력하고, 항상 더 `큰 그림`을 보려 한다.

# 목표

- 매년 새로운 언어를 최소 하나는 배워라
- 기술 서적을 분기마다 한 권씩 읽어라.
- 비 기술 서적도 읽어라
- 수업을 들어라
- 지역 사용자 모임에 참여하라.
- 다른 환경에서 실험해보라
- 요즘 흐름을 놓치지 마라
- 인터넷을 이용하라.

# 아키텍처 프로토타입에서 규명할 사항

- 주요 컴포넌트의 책임이 잘 정의되었고 적절한가?
- 주요 컴포넌트 간의 협력관계가 잘 정의되었는가?
- 결합도는 최소화 되었는가?
- 잠재적 중복을 찾아낼 수 있는가?
- 인터페이스 정의와 제약 사항은 수용할 만 한가?
- 각 모듈이 실행 중에 필요로 하는 데이터에 접근할 수 있는 경로를 갖고 있는가?

# 스트룹 효과(Stroop Effect)

의미없는 이름보다 더 고약한 것은 오해를 불러일으키는 이름이다. 

# 다른 사람들의 코드를 존중해야 한다.

개발자간에 황금률(`남들이 자신에게 해주기 바라는 대로 남에게 행하라`)과 상호존중이라는 기반을 지킨다.




# 출처

- 책:실용주의 프로그래머


{{tag>실용주의 프로그래머 책}}

## 18. 추정을 통해 놀람을 피하라. 

시작하기 전에 `추정`부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다. 

## 19. 코드와 함께 일정도 반복하면 조정하라. 

구현하면서 얻는 경험을 이용해서 프로젝트의 `시간` 척도를 세밀히 `조정`하라.

## 20. 지식을 일반 텍스트로 저장하라.

일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다. `일반 텍스트 형식`은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는데 도움이 된다. 

## 21. 명령어 셀의 힘을 사용하라. 

그래픽 사용자 인터페이스로는 할 수 없는 일에 셀을 이용하라. `command shell`

## 22. 하나의 에디터를 잘 사요하라.

에디터를 마치 손의 연장으로 자유자재로 다루어야 한다. 여러분이 사용하는 `에디터`는 설정을 바꿀 수 있고, `확장가능`하고, `프로그램 가능`해야 한다. 

## 23. 언제나 소스코드 관리 시스템을 사용하라. 

소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다. `GIT`, `SVN`

## 24. 비난 대신 문제를 해결하라.

버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여저히 고쳐야 할 필요가 있다. 

## 25. 디버깅을 할 때 당황하지 마라.

숨을 깊게 들이 쉬고, 무엇이 버그를 일으키는지 `생각하라!`

## 26. 'select' 는 망가지지 않았다. 

OS 나 컴파일러의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장 크다. 

## 27. 가정하지 마라. 증명하라.

진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 `증명`하라.

## 28. 텍스트 처리 언어를 하나 익혀라. 

여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터가 그 일의 일부를 하게끔 만들지 않는가? `perl`, `python`, `ruby`

## 29. 코드를 작성하는 코드를 작성하라. 

`코드 생성기`는 생산성을 증가시키며 중복을 막는 일에도 도움이 된다. 

## 30. 완벽한 소프트웨어는 만들 수 없다. 

소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라. 

## 31. 계약에 따른 설계를 하라. 

코드가 실제로 하기로 한 것을 `문서화`하고 검증하기 위해 `계약`을 사용하라.

## 32. 일찍 작동을 멈추게 하라. 

보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.

## 33. 단정문을 사용해서 불가능한 상황을 예방하라.

단정은 여러분이 세운 가정을 검증해준다. 확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라. 

## 34. 예외는 예외적인 문제에 사용하라. 

예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라. 

## 35. 시작한 것은 끝내라. 

가능하다면, 리소스를 할당한 루틴이나 객체가 해제도 책임져야 한다. 

## 36. 모듈간의 결합도를 최소화하라.

`디미터 법칙`을 적용하고 '부끄럼 타는 shy' 코드를 작성해서 결합이 생기는 일을 피하라. 

```
디미터 법칙은 객체의 모든 메소드는 다음에 해당하는 메소드만을 호출해야 한다고 말한다.

1. 객체 자신의 메소드
2. 메소드의 매개변수로 넘어온 인자의 메소드
3. 메소드 내부에서 생성 된 객체의 메소드
4. 메소드가 포함하고 있는 객체의 메소드
```

## 37. 통합하지 말고 설정하라. 

애플리케이션에서 기술 선택을 `설정 옵션으로 구현`하고, 통합하거나 만들어 넣지 말라. 

## 38. 코드에는 추상화를, 메타데이터에는 세부 내용을

프로그램은 `최대한 일반화`해서 만들고, 세부사항들은 가능하면 컴파일된 코드 기반 바깥으로 빼라.

## 39. 작업흐름 분석을 통해 동시성을 개선하라. 

사용자의 작업흐름이 허용하는 동시성을 최대한 활용하라.

## 40. 서비스를 사용해서 설계하라.

서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.

## 41. 언제나 동시성을 고려해 설계하라.

`동시성`이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.

## 42. 모델에서 뷰를 분리하라. 

애플리케이션을 모델과 뷰의 관점으로 설계해서 적은 비용만 들이고도 유연함을 얻어내라. 

## 43. 칠판을 사용해 작업흐름을 조율하라. 

참여하는 요소들의 독립성(independence)과 고립성(isolation)을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.

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

정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든 계획과 착각하지 말라. 

## 45. 여러분의 알고리즘의 차수를 추정하라. 

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

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

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

## 47. 일찍 리팩터링하고, 자주 리팩터링하라.

정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라. 

## 48. 테스트를 염두에 두고 설계하라. 

코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다. 

## 49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다. 

가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라. 

## 50. 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.

`마법사`는 엄청난 양의 코드를 만들 수 있다. 그것들은 프로젝트에 통합해 넣기 전에 그 코드 내용을 `전부 이해`하는지 확실 해놓도록 하라.

## 51. 요구사항을 수집하지 말고 채굴하라.

요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 싶이 묻혀 있다.

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

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

## 53. 구체적인 것보다 추상적인 것이 더 오래간다.

구현 말고 `추상에 투자`하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을 수 있다. 

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

프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.

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

해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라. 스스로에게 이렇게 물어보라. '정말로 반드시 이런 방식으로 해야 하는 일인가? 꼭 해야만 하는 일이긴 한 건가?'

## 56. 준비가 되었을 때 시작하라.

여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.

## 57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.

명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.

## 58. 형식적 방법의 노예가 되지 마랄. 

여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.

## 59. 비싼 도구가 더 좋은 설계를 낳지는 않는다. 

벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라. 도구 자체의 장점만 갖고 판단하라.

## 60. 팀을 기능 중심으로 조직하라.

설계자와 코더를, 테스트 담당자와 데이터 모델 담당자를 분리시키지 말라. 코드를 만드는 방식에 맞춰 팀을 만들어라.

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

쉘 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행해준다.

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

매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다. 

## 63. 모든 테스트가 통과하기 전에 코딩이 다 된게 아니다. 

뭐 더 할 말 있나?

## 64. 파괴자를 써서 테스트를 테스트하라. 

코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라. 

## 65. 코드 커버리지보다 상태 커버리지를 테스트하라.

중요한 프로그램 상태들을 파악해서 테스트 하라. 단지 많은 코드 줄 수를 테스트 범위안에 넣는 것만으로는 충분하지 않다.

## 66. 버그는 한 번만 잡아라.

인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만든다.

## 67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.

코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고, 메타데이터를 사용하고, MVC 모델을 쓰고, 자동 생성을 이용하고 등등.

## 68. 문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라.

코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.

## 69. 사용자의 기대를 부드럽게 넘어서라.

사용자들은 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.

## 70. 자신의 작품에 서명하라.

옛날 장인들은 자신의 작업 결과물에 서명 하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.