'UML 실전에서는 이것만 쓴다' 책 리뷰

이전 회사에서의 실패 경험을 뒤로하고 이번에 들어간 회사에서는 같은 실수를 반복하지 않기 위해 여러 IT 관련 책들을 보면서 지식을 쌓기 위해서 노력하고 있습니다. 설계 관련 책을 구매 시 관련 서적 추천을 받아 읽게 된 'UML 실전에서는 이것만 쓴다'의 책 내용과 감상평을 간단히 소개하도록 하겠습니다.

실전에서는 이것만 쓴다 책 표지

목차

 

'UML 실전에서는 이것만 쓴다' 내용 요약

저자는 다이어그램 법률가가 되지 않아야 된다고 책에서 강조하면서 말합니다. 그러니 모든 다이어그램의 세세한 룰을 몰라도 관계없다고 이야기하며 아래의 다이어그램만 정확히 알아도 실무에서 적용하는데 문제가 없다고 이야기합니다.

이진트리 알고리즘
클래스 다이어그램
객체 다이어그램
시퀀스 다이어그램
협력 다이어그램

그리고 uml은 대규모 소프트웨어 구조의 로드맵을 만들 때 유용하며, 정말 필요한 다이어그램만 보관하고 나머지는 설명할 때만 사용하고 바로 파기 파기하는 것이 중요하다고 이야기합니다. 저자가 주장하는 다이어그램의 사용법은 아래와 같습니다.

 

1. 먼저 간단한 동적 다이어그램을 그린다(5분 이내)

2. 정적인 구조 다듬기(5분 이상)

3. 다이어그램은 칠판에 적으면서 구조를 생각하는데 쓸 것

4. 형식을 아주 잘 지키려고 노력하지 않을 것

5. 목적은 오직 하나 모든 사람이 지금 논의하는 내용을 다 이해하는 것

그러면서 모든 것을 다이어그램으로 그리는 것은 악영향이라고 이야기하는데요. 저자가 말하는 다이어 그램을 그려야 하는 경우는 아래와 같습니다. 
-여러 사람이 동시에 작업할 때, 모두가 설계에서 특정한 부분의 이해를 해야 할 때
-2명 이상의 의견이 달라, 팀 의견을 모을 필요가 있을 때
-설계 아이디어 시험 시(생각을 코드로 옮겨 적을 수 있게 되었을 때 멈추고 다이어그램 파기)
-코드 일부분의 구조를 설명할 때
-마지막 문서 작업 때

그리고 다이어그램 그리지 말아야 할 경우를 아래와 같이 이야기합니다.
-공정에 있기 때문에(형식적으로)
-훌륭한 설계자 흉내
-코드 지시를 위해(코딩에 직접 참여해라)

또한 다이어그램을 그리는 비싼 case도구는 거의 필요 없다고 이야기합니다. 도구를 활용하는 것보다 수첩, 노트, 칠판을 사용하는 것을 강조합니다. 그리고 다이어그램에 모든 메서드를 다 적을 필요는 없다고 합니다.(저자는 이에 대해서 '모든 메서드를 다이어그램에 다 적으면 그저 어지러울 뿐이다. 구현해야 하는 메서드에 대한 힌트로 충분하다')

또한 UML의 모든 문법을 다 쓸 필요는 전혀 없다고 하는데요.(아무도 이해하지 못하게 된다) 저자가 다이어그램에 대해서 주장하는 주옥같은 내용들을 모으면 아래와 같습니다.

시퀀스 다이어그램은 객체 사이의 연결을 드러내기 위해 사용하는것이지 알고리즘의 세부사항을 위해 사용하면 안됨
코드만으로 이해할 수 있으면, 다이어그램은 시간과 자원의 낭비
꼭 필요할 때 그린 시퀸스 다이어그램은 매우 가치가 있다.

다이어그램 천 개가 가득 그려진 문서는 쓰레기다.
모든 메서드의 시퀸스 다이어그램을 그리는 그런 짓거리는 하면 안 된다.
유스 케이스는 그때그때 '작성하는 요구사항'이라고 생각하라

유스케이스는 시스템의 동작 하나를 기술한 것(사용자의 눈에 보이는 이벤트들).

자주 변경되는 컨 크리트 클래스에 의존하지 말 것(단 string, vector는 예외-자주 변하지 않으니까)

함수, 상속의 기반 클래스, 참조 등은 전부 추상 클래스로 만들어라(그럼 변화가 작아진다)

다이어그램 사용 실천방법
1. 고객과 일의 우선순위 이등에 대한 상담

2. 시스템 동작방법, 필요한 것들을 상담하며 유스 케이스들을 찾아낼 것, 찾아낸 유스 케이 스는 메모장 한 장에 하나씩 적어놓음(완벽하게 말고 간략히)

3. 기능의 추정치 잡기(실제로 만드는 데 걸리는 시간)

4. 각 기능의 추정치를 현재 가용한 인원으로 계산

5. 릴리스 계획
  -릴리스는  보통 반복 주기 6개, 즉 세 달 정도임
 6. 반복 주기 계획

  -고객이 요구하는 스토리(요구사항)를 각각의 태스크로 잘게 쪼개기

  -잘게 쪼갠 여러 개의 테스트를 개발자들이 스스로 선택하게 만들기
 7. 중간점검

  -작업 시작 1주일 후 실제로 작업 속도와, 견적 점수 및 일자들을 계산해보기
  -견적 점수 및 일자들에 미치지 못했다면, 고객에게 납기를 늘려달라고 이야기할 것
  -다음 주에는 현재의 작업 속도를 기준으로 고객에게 견적 재 조정

 

반복 주기 개발 관리

 -프로그래머 2명이 짝을 이루어 개발을 한다. 컴퓨터 한 대 앞에 두 사람이 함께 앉아 작업을 진행한다.(생산성에 악영향을 끼치지 않으면서도 품질은 상승한다.)

-하루에 한 번씩 짝을 바꾼다.
 

인수 테스트
 -한 주에 절반이 지나기 전에 프로그래머에게 인수 테스트가 전달되고, 그때서야 개발자들은 본인이 개발하고 있는 것들이 무엇을 진정으로 이루어야 하는지 알게 된다

단위 테스트
 -코드보다 단위 테스트를 먼저 작성한다.

 -처음에 통과하지 못하는 게 당연하다.

 -하지만 단위 테스트를 통과한 코드는 '몇 분 전에 모든 테스트를 완벽하게 통과한 코드'다

 -수 없이 쌓인 테스트 케이스가 많이 있기 때문에 리팩터링을 주저할 이유가 없다. 리팩터링을 할 때에 테스트를 돌려보고 실패 여부를 살펴보면 된다.

UML패키지

재사용 그룹의 클래스들을 한 패키지에 사용해야 한다. 그리고 이 패키지는 계속 유지/보수되어야 한다.

1. 공통 폐쇄 원칙
 -변경 가능성이 비슷한 클래스들을 하나로 묶는다
2. 공통 재사용 법칙

 -클래스의 클라이언트마다 따로따로 인터페이스를 만드는 것이 좋다. 패키지도 마찬가지로 클라이언트마다 따로따로 패키지로 만들어 관리하는 것이 좋다.
3. 의존 관계 비순환 원칙
-의존 관계 그래프에서 순환을 제거하라
4. 안정된 의존 관계 원칙
 - 모든 패키지 의존 관계 화살표는 언제나 화살표가 출발하는 패키지(의존하는 패키지) 보다 변경하기 어려운 패키지를 가리켜야 한다.
5. 안정된 추상화 원친
 -안정된 패키지는 추상적이어야 한다.

객체 다이어그램
 -사용할 일은 거의 없다 하지만 한 번씩(1년에 한 번 정도) 써야 할 때는 꼭 쓰는 게 좋다.
 -스레드의 사령부 역할을 하는 활동적인 객체들은 경계선을 굵게 해서 그린다.
 -객체 다이어그램은 특정 순간의 시스템 상태를 찍은 스냅숏이다. 동적인 경우 특히 유용하지만, 자주 쓰지 않도록 조심해야 한다(대부분의 객체 다이어그램은 대부분 대응되는 클래스 다이어그램에서 바로 유추가 가능하기 때문, 유추하기 힘든 경우에만 사용해야 한다.)

상태 다이어그램
 -유한 상태 기계는 소프트웨어를 구조화할 때 쓸 수 있는 강력한 개념이다. UML은 FSM을 시각적으로 표현하는 매우 강력한 표기법이지만, 다이어그램보다 텍스트 기반의 언어를 사용하는 것이 더 쉬운 경우가 많다.

 

'UML 실전에서는 이것만 쓴다' 완독 후기 및 감상평

고백하자면 저는 사실 uml에 대한 대략적인 개념만 알고 있었는데요. 실제 회사에서 써본 적이 단연코 한 번도 없었습니다. 설계 업무에 전혀 참가해본 적도 없고 할 일도 없다고 생각했기 때문인데요. 코드를 이해할 수 있는 회사원이라는 포지션이었다고 제 스스로 많이 느꼈던 부분이 일조했는지도 모르겠습니다. 

 

그래서인지 이 책을 일으면서 예전에 공부했었던 모르는 부분들을 조금씩 알게 되는 효과도 있었으며, 저자가 주장하는 데로 uml의 모든 법칙을 다 외울 필요는 없다는 것에 많은 위안과 깨달음을 얻었습니다. 저자는 소위 말하는 'UML 법률가'가 되어봤자 실제 업무에 하등 아무런 도움이 되지 않으며, 서류화에 목숨을 걸어 uml을 멋지게 그리는데 목숨을 거는 짓은 미친 짓이라고 책에서 못 박고 있습니다. 오직 실제로 코드가 작동하는 부분을 설명하거나 개념을 그리는 부분에 있어서 uml을 이용할 뿐이지 그 이상 그 이하도 아니라고 이야기합니다.

 

위에서 이야기한 것처럼 모르는 부분이 많았으나, 설계에 있어서 uml이 어떻게 쓰이는지 대략적으로 감을 잡게 된 것이 가장 큰 수확이었습니다. 개별로 실제 예 제을 위해 과도하게 많은 uml 기호들을 사용하여 실제 코드들을 uml로 그리면 어떻게 보이는지 설명하는 장들이 있습니다. 이 부분들은 '이런 식의 기호 표현 방법도 있구나'정도로 참고하시면 되겠습니다. 설계에 관심이 조금이라도 있으시거나, IT 개발의 전체 부분을 각 단계별로 알아보고 싶으신 분, uml을 어떻게 하면 좀 더 실용적으로 활용하면 좋을지에 대해 고민하고 있으신 분이라면 추천드립니다.