[모델링]코드리뷰짝 매칭결과 알림

들어가기

팀원 6명에 대해 코드리뷰 짝을 지어주면 재밌을 것 같아 작년말에 Node.js를 이용해서

간단하게 프로그램을 만들었다.프로그램에 대한 자세한 소개는 여기를 참고하면 된다.

이번에 얘기할 주제는 프로그램 구현완료 후에 모델링을 다시 해본 내용이다. =============================================================================

1. 최초버전

나름, 알림을 보내는 부분과 결과를 파싱하는 부분이 변화되는 부분이라 생각되어

AlarmSender와 Parser인터페이스를 정의했다.

알림내용에 대한 부분도 공통적인 부분은 Alarm(SmsAlarm도 생각해서)으로 정의하고

그것을 상속받아 EmailAlarm을 만들어 모델링했다.

하지만, 모델링과정에서 “역할“에 대한 정의가 잘못되어 Main 클래스에 해당하는

CodeReviewMathcingPairResultBatch클래스에서 알림내용을 만들고 있고,

통지내용을 모델링하기 위해 Alarm클래스를 만들었지만, 알람은 그냥 알람일 뿐인데

코드리뷰매칭결과“를 Alarm이란 이름으로 정의한 것도 결국 “역할“에 대한 잘못된

정의에서 나온 결과물이다.

class_diagram_mod   2. 중간버전

기존의 Alarm이 담고 있던 “코드리뷰매칭결과“를 CodeReviewPairResult클래스로

모델링했지만, 클래스다이어그램만 봤을때는 이것이 무엇을 담고 있는지 명확하지

않은 문제가 있다.

그리고 “코드리뷰매칭결과“를 가져오기 위한 부분도 저수준모듈인 HtmlParser클래스에

의존하고 있다. 저렇게 되면 “코드리뷰매칭결과“를 웹페이지가 아닌 DB 혹은 파일에서

가져왔을 때 CodeReviewService클래스를 수정해야된다.

결국, 수정에는 열려있고 확장에 닫혀있는 구조가 된 것이다.

그래도, 통지기(Notifier)인터페이스의 notify메소드 파라미터를 “코드리뷰매칭결과”와

“팀원”으로 나누어 정의한 것은 통지기의 “역할“에 대한 고민의 흔적이다 class_diagram_v5_mod 3. 최종버전

총 8번에 걸쳐 최범균님과 모델링결과물에 대해 논의하고 리팩토링한 결과 아래와 같은

클래스다이어그램이 나오게 되었다.

제일 큰 변화는 “코드리뷰매칭결과“를 가져오는 부분이다.

이전에는 Parser로 추상화해서 정의했다면, 최종버전을 만들면서 가장 고민했던 부분이

 “코드리뷰매칭결과를 가져오다“라는 부분에 집중했다는 것이다.

이 말은 즉, Parser로 추상화해서 정의한 것이 웹페이지에서 결과를 가져오는

구체적인 “구현“에 의존했다면,  MatchingResultSource인터페이스를 정의함으로서,

 “코드리뷰매칭결과를 가져오다“라는 부분을 올바르게 “추상화“할 수 있었다.

MatchingResultSource인터페이스를 정의함에 따라,  “코드리뷰매칭결과” 모델링도 각각

MatchingResult와 Group으로 정의했다.

CodeReviewPairResult클래스에 제목과 내용만 있던 전과 비교해 “코드리뷰매칭결과“에

어떤 내용이 담겨있는지가 보다 더 명확해졌다.

그리고, 전체적으로 인터페이스와 클래스, 메서드의 “이름“에 신경썼는데

결국, 겉으로 드러나는 “이름“을 통해 말하고자 하는 의도가 더욱 분명히 드러나기 때문에

더욱 고민을 많이 했던 부분이다.

class_diagram_v8_mod=============================================================================

마치며..

이번 모델링과 리팩토링을 통해  “코드리뷰짝 매칭결과를 가져와 팀원에게 알려준다

라는 고수준 로직을 적절하게 “추상화“하고 그에 따른 “다형성” 구현을 통해 각각의

역할“과 “책임“을 정의함으로서, 향후 유지보수에 유연한 구조를 만들 수 있게 되었다.

이것이 가능한 이유는 객체지향 설계 중, 추상화/다형성을 통한 “의존역전원칙(DIP)“과

리스코프치환원칙(LSP)“을 지킴으로서, 결국엔 수정에는 닫혀있고 확장에는 열려있는

개방폐쇄원칙(OCP)“을 준수했기 때문이다.

그리고, 추가적으로 OCP를 준수함으로써 CodeReviewService의 고수준모듈 로직,

코드리뷰짝 매칭결과를 가져와 팀원에게 알려준다“를 재사용할 수 있게 되었다.

8번에 걸친 수정을 하면서 익숙하지 않은 “모델링“에 대한 “역할“과 “책임“정의가

쉽지 않았다.

책으로만 봤던, 수정이 용이한 유연한 설계에 대한 이론에 고개를 끄덕이면서 머리로만

이해하려고 했던 내용을 실전에서 부딪치니 생각처럼 “모델“이란 녀석이 쉽게 도출되는

게 아니구나라는 걸 깨닫게 되었다.

적절하게 “모델”을 추출하기 위해서는 많은 지식과 경험이 필요하고, 또한 깊이있는

고민과 사색이 수반되어야 함을 느꼈다.

마지막으로 그간의 과정이 결코 쉽지 않았지만, 힘들었던 것 만큼 재미있는 시간이었다

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

w

%s에 연결하는 중