한국의 마틴 파울러가 되기
<짝 프로그래밍처럼 함께 설계하기>를 이어가는 글입니다. 앞서 제가 열거한 순서에 따르면 3번에 해당하는 절차를 다룹니다.
경계를 지어 준 후에 가장 먼저 해야 할 일은 경계를 넘나드는 상호작용을 담을 그릇을 준비하는 일입니다. 명절에 잡채를 많이 요리했다고 가정합시다. 접시에 푸짐하게 잡채를 담고 나서 남은 것도 어딘가에 보관을 해야 하죠. 잡채로 비유한 소프트웨어로 처리할 역할과 기능을 적절히 담는 그릇으로 보통 '객체'라는 개념을 사용합니다. 즉, 어떤 객체를 후보로 지정하여 역할과기능을 담아 보는 식입니다.
동료가 포착한 그림에서 바운더리로 표시한 부분은 무엇이며 나머지와는 어떤 관계를 갖는지 드러내는 그림을 제가 다시 추가했습니다. 지난 글에서도 설명했듯이 경계를 짓는 일은 경험이 필요한 일이라 협업 과정이라면 시니어가 가늠한 후에 함께 답을 찾아갈 것을 권합니다.
위 그림에서 매칭이라고 쓴 것이 객체의 이름(후보)입니다. 매칭을 제외한 다른 부분의 작명이나 상세 내용은 지금은 중요하지 않습니다. 이미 포착한 내용을 놓치지 않는 것이 지금의 초점이죠. 그래서, 요리한 잡채를 담을 그릇이라고 비유한 것입니다. 이런 흐름은 맥락을 놓치지 않고 객체를 점차 구체화하는 효과를 노리는 방법입니다.
즉흥적으로 그린 그림이라 나에게 치우친 단어와 개념이 등장합니다. 동료를 이해시키기 위해 질문을 하고 뒤따르는 답변 과정은 굉장히 유용합니다. 그러는 가운데 용어가 두 사람 수준에서나마 객관화됩니다. 답변 과정에서 현장에서 자주 쓰는 말 즉, 도메인 언어를 택하기도 쉽죠. 두 사람 사이에서 감정 흐름만 잘 조절할 수 있다면 업무 개념 중심의 원활한 소통을 촉진할 수 있습니다.
자연스럽게 도메인 지식이 도출되고, 규명되고, 서로 관계를 지어 가는데 이를 정제(refinement)된다고도 표현합니다.
동료가 처음 그린 상태도는 주요한 도메인 용어를 모두 담으려는 의도로 인해 바운더리가 불투명하다는 인상을 받았습니다. 객체를 정의하려면 함께 담을 수 있는 요소들이 포착되어야 합니다.
업무 분석을 하는 모델러는 흔히 낯선 업무를 다루기 쉬운데, 이번 경우는 객체의 바운더리마저 제가 정한 것이라 낯선 것들이 맞추느라 동료가 편안하게 생각을 표현하지 못한 탓이라고 짐작을 했습니다. 이를 회복할 수 있도록 구두 미팅에서 몇 가지 질문과 조언을 했는데 나중에 동료가 메모한 것을 보니 7가지 항목 정도였습니다. 그중에서 보편적으로 쓸모 있어 보이는 코멘트는 다음 두 가지였습니다.
당연한 것(뻔한 것)부터 해결하자
완결형이 되어야 상태도로 의미 있다
그 결과를 담아 즉석에서 그려 낸 다시 말해, 짝 모델링 결과로 그린 상태도 초안은 다음과 같습니다.
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기
13. 설계는 변화에 대한 준비인가?