27장: 프로그램의 크기가 구현에 미치는 영향
27.1 의사소통과 크기
- 협업하는 사람이 많을수록 의사소통에서 문제가 발생할 확률이 높다. 이 때 전형적 접근 방법은 의사소통을 문서화하는 것이다.
- 거의 모든 방법론의 핷미은 의사소통 문제를 감소시키는 것이다.
27.2 프로젝트 크기의 범위
- N/A
27.3 프로젝트의 크기가 오류에 미치는 영향
- 프로젝트의 크기가 커질수록 구현 오류보다는 설계/요구사항에서의 오류가 증가한다.
- 라인 수와 오류 수는 정비례하지 않는다. 라인수가 많아질 때, 1000줄당 오류의 빈도가 많아진다. 거의 exponential 하게 증가한다.
27.4 프로젝트의 크기가 생산성에 미치는 영향
- 프로젝트가 작을수록 생산성이 높다. 작게는 2~3배, 많게는 5~10배.
27.5 프로젝트의 크기가 개발 활동에 미치는 영향
- 프로젝트가 작으면 구현이 대부분. 프로젝트가 커질수록 다른 활동이 더 빠른 속도로 늘어난다 - 계획, 아키텍쳐, 통합, 테스트, …
28장: 구현 관리
28.1 훌륭한 코딩 장려
- 페어 프로그래밍, 세 명 이상의 사람이 모든 코드를 리뷰하기
- “나는 이 프로젝트에서 작성되는 모든 코드를 읽고 이해할 수 있어야만 한다”고 말하는 것.
28.2 형상 관리
- N/A
28.3 구현 일정 예측
- 초기 예측은 어차피 부정확하다. 프로젝트가 진행됨에 따라 주기적으로 재예측하고 반영한다.
- 보통 계획된 일정을 무조건 넘기게 된다. 시간의 양을 늘리는 것이 반드시 필요하다. 만약 그렇게 안된다면 - 일정에 맞출 수 있다는 희망을 갖는다 / 프로젝트 범위를 축소한다(속도 면에서 느리더라도 기능을 완성한다).
28.4 측정
- 작업일수, 총 비용, 작성된 줄 수, 클래스나 함수의 수, 버그 수, 컴파일러 오류 수, , …
- 측정을 안 하는 것보다는 하는 것이 무조건 좋다. 그러나 데이터를 수집하는 이유가 있음을 분명히 할것. 목표를 정하고 물어야 할 질문을 정한 뒤 측정한다.
28.5 개발자를 사람으로 대우하기
- 코딩 컨벤션이 격렬한 논쟁을 할정도로 중요한가 ? 사기를 떨어뜨리는 것이 더 큰 손해다.
- 작업 환경을 개선할 것. 몰두할 수 있는 공간, 조용한 작업 공간, 전화를 다른 곳으로 돌릴 수 있는 능력 등이 매우 중요한 환경적 요인이었다.
- 개발자는 사람으로 대우를 받을 때 수행 능력이 가장 좋아진다.
28.6 관리자 관리
- 최고의 장기적 해결책은 관리자를 교육하는 것이다.
29장: 통합
- 개별 컴포넌트를 합치는 것. 컴포넌트 작성 순서가 통합의 순서에 영향을 미친다.
29.1 통합 접근 방법의 중요성
- 잘못된 방법으로 구현하고 통합하면 코드를 작성하는 것, 테스트하는 것, 디버깅하는 것 모두 다 어려워진다. 또한 구현 중간에 더 이상 진행되지 못할 수 있다.
- 신중한 통합으로 얻을 수 있는 장점은 테스트의 장점과 거의 유사하지만, 그것 때문에 통합의 중요성이 간과되고 있다. 통합은 중요하다.
29.2 통합 빈도-단계별 또는 점증적 접근 방법
- 단계별 통합 - 컴포넌트 테스트까지 완성하고 한번에 합쳐보는 것. ‘빅뱅 통합’. 통합 시점에 난리가 난다. 온갖 오류 발생.
- 점증적 통합 - 작은 단위로 프로그램을 작성하고 테스트한 다음 한 번에 하나씩 결합한다. 오류를 찾기가 쉽고 프로젝트 초기부터 성공한다. 약간 애자일 한 느낌.
29.3 점증적 통합 전략
- 어떤 컴포넌트부터 만들어야 점증적으로 통합할 수 있는지 신중하게 확인하고 계획해야 한다.
- 하향식 통합 : main() 부터 짜는 것. 인터페이스 계획을 잘 해야 된다. 프로젝트 초기부터 동작하는 프로그램을 확인할 수 있음. 문제는 stub 코드가 엄청나게 많이 필요해짐.
- 상향식 통합 : 잠재적으로 까다로운 시스템 인터페이스들을 초기에 구현. 그래서 오류를 찾기가 쉽다. 문제는 마지막에 가서야 인터페이스를 통합할 수 있다는 것. 따라서 통합 전에 설계가 끝나야 된다.
- 순수한 하향식/상향식은 없다. 순서를 어떻게 하느냐에 따라 샌드위치, 위험 지향, 기능 지향, T자, .. 뭐 많기도 하다. 만드는 제품에 따라 취사선택 해야 한다.
29.4 일일 빌드와 스모크 테스트
- 매일 문제가 없는지를 확인하는 건 사기 진작에도 도움이 된다.
- 스모크 테스트는 시스템과 같이 발전해야 된다. 언제까지 헬로 월드만 찍을 건가 ? 이건 프로그램에 대한 잘못된 자신감을 심어준다.
30장: 프로그래밍 도구
- N/A
30.1 설계 도구
30.2 소스코드 도구
30.3 실행 코드 도구
30.4 도구 지향적인 환경
30.5 자신만의 프로그래밍 도구 개발
30.6 프로그래밍 도구에 대한 환상
