To Make Better Programs

1. Fully Understand Customer's Needs
• 고객, 즉 사용자가 무엇을 원하는지 파악하는 것이 중요하다. 아무리 좋은 기능이라고 해도 당신의 고객이 원하지 않는다면 가치가 없다.
  
2. Scheduling: According to The Mythical Man-Month, you may spend time for
   Design (1/3), Coding (1/6), Component testing (1/4), and System testing (1/4). That means Design (4) : Coding (2) : Component testing (3) : System testing (3)
• Brooks law에 따르면 늦어진 프로젝트에 사람을 충원하는 것은 프로젝트를 더욱 느리게 만들 뿐이다. 대게 실제 코딩을 하는 데 대부분의 시간을 쓴다고 생각하지만 실제 코딩은 1/6의 시간을 차지하는 것이 적당하다. 그리고 테스트에 전체의 1/2의 기간이 소요된다.
  
3. Communication Between Team Members
• Class들의 Cohesion(응집성)만 중요한 것이 아니다. 조직행동론에 따르면 높은 Cohesion을 보이는 팀은 높은 성과를 내거나 낮은 성과를 낸다. (반면, 응집력이 작은 팀은 약간 좋은 성과를 내거나, 약간 낮은 성과를 낸다.) 성패를 좌우하는 것은 탁 팀원들의 공통 목표를 제대로 인식하고 goal을 향해 나아가는 가이다.
  
4. Exactly Understand What Problem Is
• 해결해야 하는 문제가 무엇인지 올바로 파악해야, 문제를 풀 수 있다.
  
5. Appropriate Software Design (using Design Patterns)
• 문제에 적절한 디자인 패턴을 이용한다. 자신이 알고 있는 디자인을 Golden hammer로 모든 곳에 적용하려 해서는 안 된다. (Golden hammer와 Anti-pattern을 참고.)
  
6. Spiral Design Process: Waterfalls model은 지양해야 한다.
   Star lifecycle model, simple interaction design model, simple interaction design model, usability engineering lifecycle 등 Evaluation을 강조한 다양한 Design process가 있다.
   
   
• Spiral model (Waterfalls model을 사용하지 말라.)
• Interface Design and Usability Engineering
7. Make a couple of scenarios
• 예상되는 사용 시나리오를 몇 개 작성해 본다. 프로그램이 어떻게 사용 될지, 어떻게 사용자, H/W, 시스템이 서로 영향을 미칠지 구체적으로 기술한다.
  
8. Understand What I have to do for a project, by attending meetings.
• 특히 팀으로 진행 되는 경우, 각자의 역할이 무엇인지 명확하게 설정 되어 있어야 서로 overlap되지 않아 효율을 높일 수 있다.
  
9. Cohesion and Decoupling (especially for OOP)
• OOP의 기본 개념이다. 보다 maintainable한 프로그램을 위한 조건이다. 프로그램을 디자인할 때 염두해야 한다.
  
10. Documentation (Comments, API, Javadoc, helper methods, etc.)
• 이 역시 maintainable한 프로그램을 위한 조건이다. 덧붙여 프로젝트가 진행 됨에 따라 개발자가 교체되거나 개발팀 외부의 사람과 대화 할 때 유용하다.
  

Figure. Spiral model: www.swc.scipy.org/lec/dev01.html
Figure. Interface Design and Usability Engineering: http://grouplab.cpsc.ucalgary.ca/saul/481/