소프트웨어 개발
을 잘 해보려는 생각이 없다면 왜 인생
을 그 일을 하면서 보내는가?
자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라.
변명하는 대신 대안을 제시
하라. 그 일을 할 수 없다고 말하지 말고, 무었을 할 수 있는지에 대해 설명하라.
눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.
깨진 유리창 이론(영어: Broken Windows Theory, BWT)은 미국의 범죄학자인 제임스 윌슨과 조지 켈링이 1982년 3월에 공동 발표한 깨진 유리창(영어: Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities)이라는 글에 처음으로 소개된 사회 무질서에 관한 이론이다. 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다.
사람들에게 변화
를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라
.
주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.
프로젝트의 진짜 품질 요구사항을 결정하는 자리에 사용자를 참여
시켜라.
학습을 습관으로
만들어라.
벤더, 매체들의 야단법석, 도그마에 흔들리지 말라. 여러분과 여러분 프로젝트의 관점에서 정보를 분석
하라.
효과적으로 전달
하지 못한다면 좋은 생각이 있어봐야 소용없다.
어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 하나뿐인 표현
을 가져야 한다. DRY
재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라. REUSE
컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의도니 목적만 갖도록 설계하라. 직교성
돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비
하라.
예광탄
은 이것저것을 시도
해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다.
프로토타이핑
은 배움의 경험
이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교훈에 있다.
사용자의 언어
를 사용해서 설계와 코딩을 하라.
Code Generation in Action
(Jack Herrington, Manning, 2003) 이라는 책을 참고FIT for Developing Software
(Prantice-Hall, 2005)를 참고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)를 추천초일류 기업의 성공 비밀, 시리어스 플레이
(세종서적, 2001)에서 프로토타이핑 속도가 혁신에 뛰어난 조직과 그렇지 못한 조직을 결정짓는 주된 요소라 말한다.생각하는 프로그래밍
(인사이트, 2003, 원제는 Programming Pearls)을 쓴 존 벤틀리(Jon Bentley)는 그 책의 후속작 More Programming Pearls
(Addison Wesley, 1988)에서 작은 언어(Little Language)에 대해 하나의 칼럼을 할애, 탁월한 설명을 한다. (이 칼럼은 CACM 아카이브에서 볼 수 있다.)소프트웨어 프로젝트에서의 리스크 관리
(인사이트, 2004, 원제는 Waltzing with Bears)를 참고실용주의 프로그래머를 위한 프로젝트 자동화
(마이크 클라크, 인사이트, 2005)에 잘 정리되어 있다.실용주의 프로그래머를 위한 버전 관리 using CVS
를 참고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)은 문제가 뭔지 생각하는 데에 도움을 주는 책이다.자신감
그들은 직면한 문제 너머를 생각하며, 문제를 항상 더 큰 맥락
에 놓으려 노력하고, 항상 더 큰 그림
을 보려 한다.
의미없는 이름보다 더 고약한 것은 오해를 불러일으키는 이름이다.
개발자간에 황금률(남들이 자신에게 해주기 바라는 대로 남에게 행하라
)과 상호존중이라는 기반을 지킨다.
시작하기 전에 추정
부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다.
구현하면서 얻는 경험을 이용해서 프로젝트의 시간
척도를 세밀히 조정
하라.
일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다. 일반 텍스트 형식
은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는데 도움이 된다.
그래픽 사용자 인터페이스로는 할 수 없는 일에 셀을 이용하라. command shell
에디터를 마치 손의 연장으로 자유자재로 다루어야 한다. 여러분이 사용하는 에디터
는 설정을 바꿀 수 있고, 확장가능
하고, 프로그램 가능
해야 한다.
소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다. GIT
, SVN
버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여저히 고쳐야 할 필요가 있다.
숨을 깊게 들이 쉬고, 무엇이 버그를 일으키는지 생각하라!
OS 나 컴파일러의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장 크다.
진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명
하라.
여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터가 그 일의 일부를 하게끔 만들지 않는가? perl
, python
, ruby
코드 생성기
는 생산성을 증가시키며 중복을 막는 일에도 도움이 된다.
소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라.
코드가 실제로 하기로 한 것을 문서화
하고 검증하기 위해 계약
을 사용하라.
보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.
단정은 여러분이 세운 가정을 검증해준다. 확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라.
예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.
가능하다면, 리소스를 할당한 루틴이나 객체가 해제도 책임져야 한다.
디미터 법칙
을 적용하고 '부끄럼 타는 shy' 코드를 작성해서 결합이 생기는 일을 피하라.
디미터 법칙은 객체의 모든 메소드는 다음에 해당하는 메소드만을 호출해야 한다고 말한다. 1. 객체 자신의 메소드 2. 메소드의 매개변수로 넘어온 인자의 메소드 3. 메소드 내부에서 생성 된 객체의 메소드 4. 메소드가 포함하고 있는 객체의 메소드
애플리케이션에서 기술 선택을 설정 옵션으로 구현
하고, 통합하거나 만들어 넣지 말라.
프로그램은 최대한 일반화
해서 만들고, 세부사항들은 가능하면 컴파일된 코드 기반 바깥으로 빼라.
사용자의 작업흐름이 허용하는 동시성을 최대한 활용하라.
서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.
동시성
이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.
애플리케이션을 모델과 뷰의 관점으로 설계해서 적은 비용만 들이고도 유연함을 얻어내라.
참여하는 요소들의 독립성(independence)과 고립성(isolation)을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.
정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든 계획과 착각하지 말라.
코드를 작성하기 전에, 실행 시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.
알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다. 실제 대상 환경에서 코드의 수행 시간을 측정해보라.
정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.
코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.
가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.
마법사
는 엄청난 양의 코드를 만들 수 있다. 그것들은 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해
하는지 확실 해놓도록 하라.
요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 싶이 묻혀 있다.
시스템이 정말로 어떻게 사용될지 통찰력을 얻을 수 있는 가장 좋은 방법이다.
구현 말고 추상에 투자
하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을 수 있다.
프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.
해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라. 스스로에게 이렇게 물어보라. '정말로 반드시 이런 방식으로 해야 하는 일인가? 꼭 해야만 하는 일이긴 한 건가?'
여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.
명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.
여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.
벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라. 도구 자체의 장점만 갖고 판단하라.
설계자와 코더를, 테스트 담당자와 데이터 모델 담당자를 분리시키지 말라. 코드를 만드는 방식에 맞춰 팀을 만들어라.
쉘 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행해준다.
매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.
뭐 더 할 말 있나?
코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.
중요한 프로그램 상태들을 파악해서 테스트 하라. 단지 많은 코드 줄 수를 테스트 범위안에 넣는 것만으로는 충분하지 않다.
인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만든다.
코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고, 메타데이터를 사용하고, MVC 모델을 쓰고, 자동 생성을 이용하고 등등.
코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.
사용자들은 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.
옛날 장인들은 자신의 작업 결과물에 서명 하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.