[맨먼스 미신]

# 2. 맨먼스 미신

• 내 나름의 법칙은 전체 일정의 1/3을 설계에, 1/6을 코딩에, 1/4를 구성 요소 테스트에, 1/4를 시스템 테스트에 배정하는 것이다.

 #10. 기록물 가설. 

• 오로지 글로 적을 때에만 빠진 곳이 나타나고 모순들이 드러난다.

• 관리자는 모든 사람이 같은 방향으로 계속 가게 하는 것이며, 문서들은 의사 소통에 따르는 부담을 줄여준다.

#11. 버리기 위한 계획

• 아무리 훌륭한 계획이라도 한 번 만에 제대로 된 시스템을 만들 정도로 전지적일 수는 없다. 따라서 파일럿 시스템을 만든 다음에 '버릴 것이냐 말 것이냐' 가 아니라 버릴 시스템을 만들기 위해 미리 계획을 세울 것인가, 아니면 그것을 고객에게 납품하겠다고 약속할 것인가이다.

• 모듈 총 개수는 버전에 따라 선형적으로 증가하지만, 출시로 영향을 받는 모듈 수는 기하급수적으로 늘어난다. 모든 수정 행위는 시스템 구조를 훼손하고 엔트로피와 무질서를 증가시키는 경향을 보였다. 

#12. 예리한 도구 (34분)

• 숙련공들은 저마다 기량을 보여줄 수 있는 도구, 수단을 가지고 있듯 프로그래머도 편집기, 정렬 기법, 이진 덤프, 디스크 공간 관련 유틸리티 등을 자기 파일 속 어딘가에 숨겨둔다. 하지만 개별 도구들은 의사소통을 돕기보다 방해한다는 근본적인 문제가 있고, 장비나 언어가 바뀌면 기술도 바뀌므로 도구의 수명은 그다지 길지 않다. 

#13. 전체 그리고 부분들

• 버그 중에서 가장 치명적이고 찾기 힘든 부류는, 다양한 구성 요소의 개발자들이 나름대로 세운 가정이 서로 어긋날 때 생기는 시스템 버그들이다. ( 개념적 일관성이 있어야 한다. )

• 시스템을 구축을 설계, 구현, 제품화의 각 과정은 하향식으로 이루어질 때 가장 좋은 결과를 가져온다.( 결과를 달성하기 위한 큰 밑그림을 그리고, 구현하기 위한 단계들을 더 작은 단계로 나누어 간다. 작업 정의를 세분화함에 따라 해법을 담은 알고리즘도 점차 세분화되며, 그 과정에서 데이터 표현법 또한 세분화될 수 있다. )

#14. 재앙의 알을 품다

• 매일매일 조금씩 일어나는 지연은 더 알아차리기 어렵고, 예방하기도 어려우며, 만회하기도 더 힘들다.

• 불분명한 마일스톤은 일을 진행할 때 더 힘겨운 짐이 된다. 그것은 잃어버린 시간을 더 어떻게 할 수 없는 지경이 될 때까지 사람을 속이므로, 사실상 의욕을 갈아 으깨는 맷돌과도 같다. 

#15. 또 다른 면

• 프로그램 설명에 들어가야 할 내용.

- 목적 : 주된 기능, 왜 이 프로그램을 쓰는가?

- 환경 : 프로그램이 수행될 장비, 하드웨어 설정, 운영체제

- 정의역과 치역 : 유효 입력값의 정의와 범위, 유효출력값의 정의와 범위

- 기능과 알고리즘. 그것들이 하는 일에 대한 설명

- 입출력 데이터 형식

- 작동 지침 : 정상, 비정상 종료시 보여지는 동작.

- 옵션 : 각 기능에 대해 사용가 선택할 수 있는 범위.

- 실행 시간 : 특정 작업을 하는데 걸리는 시간

- 정밀도와 검증 : 정밀도의 예측, 검증할 방법.

• 모든 프로그램 사본에는 소규모의 테스트 케이스가 포함되어서, 해당 사본이 신뢰할 수 있고 정확히 동작함을 사용자에게 확인시켜야 한다.

#16. 은 탄환은 없다.

• 소프트웨어 제품은 응용 분야, 사용자, 법 조항, 주변 장비들이 만들어내는 문화적인 모체 안에 파묻혀 있다. 이 모든 것은 지속적으로 변화하고, 그 변화는 소프트웨어 제품의 변경을 가차없이 강제한다.

• 소프트웨어는 많은 경우 가장 최근에 나왔다는 이유로 호환성을 갖추어야 한다. 어떤 경우에라도 다른 인터페이스에 맞추는 것 자체가 많은 복잡성을 초래하고, 이런 복잡성은 해당 소프트웨어만을 어떻게 재설계하든지 간에 단순화 될 수 없다.

• 고객들도 자기가 무엇을 원하는지 알지 못한다. 고객들은 반드시 해야 할 질문이 무엇인지도 모르고, 명세가 필요한 세부 수준까지 문제를 고민해 본 적도 없다. 그러므로 소프트웨어 개발에 따른 어떤 활동을 계획하더라도, 시스템 정의의 한 부분으로써 고객과 설계자가 폭넓고 반복적으로 소통할 필요가 있다.