2019-11-08 금요일

알고리즘

종만북

• 9.19 - 블록 게임
  - 월요일에 다시 도전

책

UML 실전에서는 이것만 쓴다

회사에 책이 있어서 한 번 읽어 봤다. 앞부분에 실무 개념이 나와서 정리해본다.

• UML 설계의 비용은 아직 잘 알려진 바가 없다. 모델을 만드는 것은 비용을 줄이기 위함인데, 건축/설계 영역과는 달리 소프트웨어의 경우 코드를 작성하는데 큰 비용이 들어가는 것이 아니기 때문이다.
• 의사소통, 로드맵을 그릴 때 유용하다.
• 설계에 대한 문서화 작업은 프로젝트 막바지에 하는 것이 맞다. 초기에 해봐야 다 변경될 것이기 때문이다.
• UML은 자주 그리고 자주 버려야 한다.
• 모든 것을 그리려고 하지 마라. 시간 낭비고, 어차피 아무도 보지 않는다.
• 아래의 경우 그려라.
  1. 이해가 필요할 때
  2. 설계를 시도할 때
  3. 구조를 설명할 때
  4. 문서화를 요구할 때
• 아래의 경우 그리지 마라.
  1. 설계단계의 포괄적 문서를 만드려고 할 때
  2. 코딩을 시키려고 할 때. 진정한 아키텍트는 직접 프로젝트에 참여하고 구현한다.
• 문서화는 현명하게 하라. 많이 만들고 복잡하게 만들면 아무도 보지 않을 뿐더러, 오히려 방해가 된다.

Clean Code

• 8. 경계
     - 외부 모듈과의 경계를 형성하라(완충지대).
• 9. 단위 테스트
     - 코드 품질에 신경써라. 망가지는 순간 더 이상 테스트 코드를 작성하지 않게 될 것이다.
  • 실행되기에 충분히 빨라야 하지만, 프로덕션 코드에서 고려해야 할 성능은 고려 대상이 아니다.
    • 예를 들어 굳이 SringBuffer를 이용하여 문자열을 결합할 필요가 없다.
  • 학습 테스트를 작성하라.
  • DSL

GoF의 디자인 패턴

• Adapter
• Bridge