UML 다이어그램 표기법을 사용해서 이루려는 정말 중요한 것에 대해 배워보자. 무엇을 발견하기 위해 UML을 그리는 것일까? 좋은 다이어그램인지 아닌지 평가하는 기준은 무엇일까?

코드 또는 다이어그램을 작성할 때 어떤 설계 원칙을 적용해야 할까?

설계의 품질

잘 설계되었다는 의미는 무엇인가?

• 잘 설계한 시스템은 이해하기 쉽고, 바꾸기도 쉽고, 재사용하기도 쉽다.
• 개발하는데 특별히 어렵지도 않고, 단순하고 간결하며 경제적이다
• 잘 설계한 시스템을 개발하는 일은 즐겁다.

반면, 잘못된 설계에서는 마치 섞는 고기처럼 역한 냄새가 난다.

나쁜 설계의 냄새

코드를 보는 프로그래머에게서 12일 정도 묵은 음식물 쓰레기 봉지를 방금 연 표정이 떠오른다면, 그 사람은 나쁜 설계를 바탕으로 작업을 하고 있는 것이다.

나쁜 설계의 냄새에는 여러가지 요소가 섞여있다.

1. 경직성: 무엇이든 하나를 바꿀 때마다 반드시 다른 것도 바꿔야하며, 그리고나면 또 다른 것을 바꿔야하는 변경의 사슬이 끊이질 않기 때문에 시스템 변경이 힘들다.
2. 부서지기 쉬움: 시스템의 한 부분을 변경하면 그것과 전혀 상관없는 다른 부분이 작동을 멈춘다.
3. 부동성: 시스템을 여러 컴포넌트로 분해해서 다른 시스템에 재사용하기 힘들다.
4. 끈끈함: 개발 환경이 배관용 테이프나 풀로 붙인 것처럼 꽉 달라붙은 상태다. '편집 → 컴파일 → 테스트'의 시간이 오래 걸리게 된다
5. 쓸데없이 복잡함: 괜히 머리를 굴려서 짠 코드 구조가 굉장히 많다. 이것들은 대개 지금 당장 하나도 필요 없지만 언젠가는 굉장히 유용할지도 모른다고 기대하며 만든 것이다.
6. 필요없는 반복: 코드를 작성한 프로그래머 이름이 마치 '복사'와 '붙여넣기' 같다.
7. 불투명함: 코드를 만든 의도에 대한 설명을 볼 때 그 설명에 '표현이 꼬인다'라는 말이 잘 어울린다.

코드에서 이런 냄새를 없애는 것이 좋은 설계의 방향이다. 다이어그램에서 의존 관계를 조사하면 더 많은 냄새를 발견할 수 있기 때문에, UML 다이어그램을 통해 냄새를 없애는데 도움이 되는 경우가 많다.

의존 관계 관리하기