2. • 커밋하고 도망가는 것은 범죄다
o Niclas Nilsson (p30)
• 일정을 지켜라
o Norman Carnovale (p42)
• 개발자에게 자율성을 부여하라
o Philip Nelson (p64)
• 간단한 것은 간단하게 하라
o Chad LaVigne (p124)
• 보이는 것처럼 그렇게 되지 않는다
o Peter Gillard-Moss (p166)
3. 커밋하고 도망가는 것은 범죄다
Niclas Nilsson (p30)
• 누군가가 커밋하고 도망가면 남은 사람들이 해결해야하며 리
듬은 깨지고 흐름은 멈춘다.
• 사람들은 자신의 시간을 줄이려고 문제가 될 수 있는 것을 커
밋한다.
• 자동화된 테스팅을 위한 건실한 아키텍처를 보장할 필요가
있다.
• 테스트가 빠르게 실행되고 더 자주 할 수 있도록 하자.
• 빠른 테스트로 커밋&도망을 생각 못하게하자.
4. 일정을 지켜라
Norman Carnovale (p42)
• 일반적인 프로젝트 실패 원인은 진행중 계획없이 일정을 변
경하는 것.
• 일정에 다음과 같은 것을 따질 때 문제가 시작된다.
o 동일한 일정 동안 얼마나 많은 것을 했는지
o 작업량을 안줄이면서 일정을 단축시켰는지를 따질 때
• 무분별한 일정 변경은 문제를 발생시킨다.
o 저렴한 설계, 나쁜 문서, 나쁜 품질
o 버그 증가, 문제수정 비용증가
• 비용을 축소하면 실패가 증가한다.
• 일정 단축이 필요하다면 기능을 다음 릴리즈로 넘겨라.
• 협상 능력을 갈고 닦아라.
5. 개발자에게 자율성을 부여하라
Philip Nelson (p64)
• 개발자가 설계를 따르도록 통제하는 것은 나쁘다.
o 자유를 주어 창조성과 능력을 행사하도록 하는 것도 중요
하다.
• 전체시스템이 잘 맞춰지는지 바라보고 지속적으로 확인해라.
• 작업의 어려움, 설계된 API 사용 실수, 이해 부족 등 개발자가
문제를 겪고 있을 때 조언하고 설계를 명확히해라.
• 고군분투하는 것을 볼 때 조언하고, 찾아와 조언을 요청할 수
있는 환경을 만들어라.
6. 간단한 것은 간단하게 하라
Chad LaVigne (p124)
• '간단한 문제-복잡한 해결책'이라는 함정에 쉽게 빠질 수 있다
.
• 오버 엔지니어링은 기회비용이 많이 발생할 수 있다.
• 당장 필요한 기능만 구현하라.
o 잠재적인 요구사항은 배제
• 필요할 때 복잡하게 하라.
o 잠재적인 요구사항이 실제 상황이 되었을 때
7. 보이는 것처럼 그렇게 되지 않는다
Peter Gillard-Moss (p166)
• 설계한 대로 될거라고 생각한다.
• 그러나 그렇게 되지 않는다.
o 잘못된 정보, 제약사항, 내 잘못, 남의 잘못
• 사소한 설계 변경은 누적되며 처음부터 다시 시작해야 하는
상황에 이르게 된다.
• 다시 철저히 설계하려 하지만 그렇게 되지 않는다.
• 설계는 항상 진행 중이라는 것을 받아들여라.