* 코드가 어떻게 동작하는가 이해해야 하지만, 꼭 그 내용에 전문가가 될 필요는 없다...
* 팀원 가운데 한 사람이 코드가 너무 어려워서 다른 사람은 이해할 수 없다고 말한다면, 누구라도(원저자를 포함해서) 유지 보수하기가 힘들것이다. 단순화하라.
* 이해하지 않은 상태에고 코드를 고쳐서 못 쓰게 만들지 말라. 땜질식 수정 증후군은 처음엔 아주 천진난만하게 시작하지만 급격히 알아볼 수 없는 쓰레기가 된다. 증상이 아니라 문제를 고쳐라.
* 대부분의 복잡한시스템은 너무나 난해해서 한 사람이 시스템 전체를 이해하기 어렵다. 작업 중인 특정 부분에 대해 더 깊이 이해하는 것 외에도, 시스템의 각 부분이 서로 어떻게 상호작용하는 지 알기 위해 시스템의 대부분에 대하여 상당한 수준으로 이해할 필요가 있다.(44-45)
매 주 팀원 중 한 명에게 토의를 이끌게 하자. 토의를 이끄는 사람은 개념을 제시하거나 툴 사용법을 보여주고, 그렇지 않더라도 팀의 관심을 끄는 것이면 무엇이든지 소개할 것이다. 여러분은 책 한 권을 골라서 그 책에서 특정 단원이나 항목, 실천방법들을 수행해 볼 수도 있다....
그 주의 회의 주관자가 15 분 정도 얘기하는 것으로 시작하자....모두가 자신의 아이디어를 제안하고 프로젝트에 그 주제가 어떻게 연관되는지 토의할 수 있다.(64)
다운로드해 얻을 수 있는 프로그램을 새로 만들지 말라. 환상적인 것을 만들고 있다면 ..., 정신 차리고 잘못하고 있음을 깨달아라. 코딩을 적게 할 수록 유지보수할 양이 적다.
..."객체 관계 매핑(Object Relational Mapping) 은 컴퓨터 과학의 베트남이다." 라고 테드 뉴워드(Ted Neward) 가 말한 것을 기억하라. 자신의 애플리케이션을 만드는 데 필요한 것만, 즉 도메인이나 애플리케이션에 국한된 프로그램을 만드는 데 더 많은 시간과 노력을 들여야 한다.(94)
프로젝트를 항상 컴파일할 수 있고, 실행할 수 있으며, 테스트하고 당장에 배치할 수 있게 하자.(99)
* 고객이 피드백들 주고 프로젝트를 조정하는데 데모의 목적이 있다. 기능이나 안정성이 부족해서 고객을 동요시키거나 화나게 해서는 안된다, 안정성이 없으면 보여주지 말라.(114)
코드를 시험하는 단위테스트를 미리 작성하기 때문에 , 코드를 수정하거나 리팩터링할 땨마다 코드를 체크인 하기 전에 테스트 케이스를 시험한다.(141)
* 코드가 무슨 일을 하는지 주석을 다는 것은 그다지 유용하지 않다. 그러나 코드가 왜 그렇게 하느지 주석을 다는 것은 유용하다.(171)
* 문제를 문서화하는 것보다 해결하는데 더 많은 시간을 보내야 한다. 문제를 문서화하는 일을 가볍고 간단하게 유지하자. 출판할 정도로 문서화 하지 않아도 된다.
* 이전 해결책을 찾는 것이 중요하다. 따라서 필요하 때 목록을 찾는데 도움이 되도록 많은 키워드를 사용하자.(201)
모든 예외를 처리하거나 전달하라.
예외를 덮어 두지 말자. 임시로라도 말이다. 코드가 실패할 수 있다고 생각하며 작성하자.(213).
* 어떤 사람도 홀로 설계하게 하지 마라. 특히 여러분 자신이 혼자서 설계해서는 안된다.(233)
코드 리뷰...아래의 최소 목록으로 시작해야 한다.
* 코드를 읽고 이해할 수 있는가?
* 명백한 에러는 없는가?
* 코드가 애플리케이션의 다른 부분에 바람직하지 않은 영향을 끼치는가?
*(코드 자체의 배부 섹션이나 시스템의 다른 부분과) 코드 중복이 있는가?
* 코드를 개선시키는 적당한 개선이나 리팩터링이 있는가?
(250)
.. 개발 기반(infrasctructure) 환경을 .. 도입해야 한다.....
* 버전관리
* 단위테스트
* 빌드 자동화
(259)
자료
여러분의 코드는 왜 형편없을가? (Why Your Code Sucks)
http://www.artima.com/weblogs/viewpost.jsp?thread=71730
이 책의 한국어 사이트
http://insightbook.springnote.com/pages/335290
영어판 참고 사이트
http://www.pragmaticprogrammer.com
