1

새로운 프로젝트 시작을 위해서 가볍게 읽기 시작했다. 아주 당연한 이야기도 있고, 다시금 생각하게 만든 이야기도 있다. 책은 여전히 그대로인데, 고민은 달라졌다.

1. OOA&D는 위대한 소프트웨어를 작성하는 방법에 관한 것이지, 방대한 문서 작업을 하기 위한 것이 아닙니다.

2. 요구사항이라는 것이 정확히 무엇입니까? ‘시스템이 올바르게 동작하기 위해서 수행하는 특정한 하나의 일’

3. […] 어떻게 사용될지를 이해해야 합니다.

4. 유스케이스, 세 가지 부분 ‘명확한 가치, 시작과 종료, 외부 기동자’

5. 고객은 항상 옳습니다.

6. […] 시나리오들은 항상 같은 사용자 목표를 공유합니다.

7. 유스케이스에서 명사(와 동사)를 분석하는 것을 본문 분석이라고 합니다.

8. […] 추상 클래스는 기능(behavior)을 정의하고 […]

9. 구현보다는 인터페이스에 의존하도록 코딩하는 것이 소프트웨어를 확장이 용이하게 합니다.

10. 모든 클래스는 이것에 대해 오직 하나의 이유만 갖도록 해야 합니다.

11. 변하는 것을 캡슐화하여, 프로그램을 더 유연하고 변경하기 쉽게 만든다.

12. 항상 세부 내용은 늦출 수 있을 때까지 최대한 늦추세요.

13. […] 디자인 패턴은 특정 형태의 문제를 위한 해결 방안을 디자인하는 방법

14. 아키텍처는 디자인의 구조이고, 프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여줍니다.

15. 시스템의 본질은 가장 기본적인 수준이 완성되었을 때의 시스템 모습입니다.

16. 테스트 주도 개발은 클래스의 기능을 올바르게 만드는 데 집중합니다.