08장_도약

• 가장 어려운일은 도메인 전문가의 관심사를 포착하고 효과적인 설계를 이끌어줄 명확한 모델을 발견하는 것 
  (이 모델이 무엇인가? 책과 같은 Class Diagram? ES? 요구사항? 기능분해? 업무흐름도?)
  도메인에 대한 심층적인 이해를 반영하는 모델 > 도메인 전문가의 사고방식과 융합되고 사용자의 요구에 기민하게 대응할수 있는 SW개발 가능 - p198
• Refactoring : SW의 기능을 수정하지 않고 설계를 다시 하는 것 - p198
  항상 모든것이 정상적으로 동작하는 상태를 유지하면서 작언 단계를 밟아가며 코드를 개선해야 - p211
  사전에 모든 결정을 내리기보다는 기존의 기능은 유지한 채 끊임없이 코드를 변경하면서
  설계를 좀 더 유연하게 개선하거나 이해하기 쉽게 만들다
  자동화된 테스트가 준비되어 있다면 비교적 안전하게 Refactoring을 할 수 있음
  (코딩하고 Refactoring 재 설계 후 다시 구현하는 재작업은 현실에서 어려우므로
  , 재작업을 최대한 줄이기 위해 상세설계 개발을 반복해서 수행, 그때 그때 Feedback 필요)
• 전통적인 방식으로 객체 분석하면 요구사항 문서에 서술된 명사와 동사를 식별하고, 식별된 명사는 초기 객체의 이름으로, 식별된 동사는 Method로 사용 - p199
• 도메인 전문가가 사용하는 특수한 용어가 어휘집(용어사전)에 편입되어 UL의 일부가 된다
  (그러면 UL의 전체는 무엇인가? UL은 개념적으로 업무전문가와 개발자가 공유하라는 의미이고 그 방법은 모델등 프로젝트 상황에 따라 다를것이라 생각) - p205
• (UML 등의) 다이어그램이 '너무 기술적'이라고 지적하곤 했던 업무 전문가들은 ... (시간이 지나서) 새로운 모델 다이어그램을 완벽하게 이해할 수 있었다 - p211
• 프로젝트 관리자는 (Refactoring 관련 3주등의 시간, Risk 등의 회의 후) 그렇게 해도 좋다고 했고 프로젝트 진행에 따른 비난이나 공격을 자신이 처리할 것이라고 말해줬다. 나는 그러한 결정을 내린 그의 '용기'와 '신뢰'에 항상 헤아릴수 없는 존경을 표한다
  우리는 목표를 달성하고자 몸이 부서질 정도로 노력했고 결국 3주 안에 작업을 마칠 수 있었다 - p212