[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
* XP의 한계
저자가 이야기한 바와 같이 XP는 대규모 Project (여기서 말하는 대규모란, project를 하기 위해 필요한 사람 숫자가 많은 Project를 의미하는 것처럼 보인다 - 사람 숫자가 많다 = 필요한 Communication 양이 많다.)에는 적합하지 않은 것 같다. 이 점을 명확히 하고 XP를 적용하자.
* Test Oriented Development의 장점.
일단 Test Oriented로 하게 되면, Test를 위한 Interface를 가장 먼저 생각하게 된다. 즉 자연스럽게 "Interface Oriented Development"를 하게 된다. 또한 개발된 Program을 검증하기 용이할 확률이 높다. 중요한 것은 Auto Test란 것 자체가 논리적인 오류를 잡아낼 수는 있어도, User experience쪽에 부적합한 내용같은 부분은 잡아내는 것이 사실상 불가능 하다는 점이다. 또한 논리적인 오류 역시, 어느 정도 큰 Module을 대상으로 Auto Test를 돌리게 되면, 모든 경우를 Test하는 것이 상당히 어렵게 된다. 따라서 Auto Test는 작은 Unit Test에 적합한 것으로 보인다. (이렇게 하면, Test종류는 늘어나겠지만... )
* 고객의 역할.
고객은 business의 가치를 높이는 것이 무엇인지 파악하고, 무엇을 먼저 하고 무엇을 나중에 할 것인지를 결정하고, 시스템이 제대로 작동하는지 확인할 수 있는 test를 정의한다.
* 관리자의 역할.
관리자는 고객과 개발자를 한데 모으고 서로 융화시켜, 팀이 순조롭게 운영되도록 도와준다. 관리자는 process를 수행하는 것이 아니라, 단지 process가 원활하게 진행되도록 하는 것이다.
-> 훌륭한 관리자의 일은 처음부터 끝까지, 작업을 하고 있는 사람들 앞에 놓인 장애물을 치우는 일이다.
* XP 프로그램 작성.
- 코드의 공동 소유 : 누구든 현재 Project의 코드를 원하는 대로 수정할 수 있다.
- 단순한 설계 : 모든 test를 실행하고, 모든 idea를 표현하며, 최소한의 Class와 Method를 가지지만, 중복된 code를 포함하지 않는다.
- 지속적인 Refactoring: 기존 코드를 바꾸지 않는 이유는 잘못되는 것을 두려워해서이다. 따라서, 거의 100%가동되는 모든 단위 Test를 가지고 있다면 Refactoring은 두려워할 만한 일이 아니다.
- 지속적인 통합 : 지속적인 통합은 항상 releasable한 상태로 유지하고, 통합시에 나타날 수 있는 문제를 최대한 빨리 찾아낼 수 있다는 측면에서 중요하다. 통합이 늦어지면, debugging시 드는 비용은 늦어진 시간만큼 증가한다. 기하급수적으로...
- 코드작성표준
- 주당40시간 : 한 주 이상의 과도한 시간외 근무는, 코드의 질을 떨어뜨리며, bug를 양산하는 주범이다.
* 짝 Programming.
두 사람이 하나의 컴퓨터 앞에서 같이 Programming을 한다. "역동적인 2인조는 개별 Play를 하는 3명보다 낫다"
(=> 일단 XP에서는 이렇게 이야기하고 있는데... 난 여기에는 아직까진 동의할 수 없다. 이건 분명히 case by case..이다.!)
코드 공동 소유 vs. 코드의 건전성 유지.