[TDD]숫자야구게임 연습

테스트 주도 개발(Test Driven Development)로 숫자야구게임을 구현해보았다.

1시간 30분동안 “실패-성공-리팩토링“의 과정을 거치며 최범균님이 구현한 결과와

비교해 보았다.

================================================================

1. “실패 => 성공 => 리팩토링”에서 “실패“과정을 따로 확인하지 않은 적이 많다.                   이것은 실제로 보폭을 넓게 가지고 갔다기보다 테스트코드를 만들 때 “성공“시키기           위해 구현을 먼저 시작한 경우가 많다는 뜻이다.

2. 적절한 시기에 리팩토링이 잘 되지 않았다.

3. 실제 구현에 대한 로직이 세련되지 못하다.

4. 그리고, 전에 범균님 동영상을 보지 않고 구현했으면 더 좋았을 것 같다! ㅎㅎ

5. IntelliJ는 Eclipse에 비해 리팩토링기능은 더 뛰어나고 테스트코드 실행속도는                  훨씬 느리다.

===============================================================

범균님 동영상을 이전에 보고 구현한 결과, 동영상 속의 결과물이 떠올라

제대로 내 생각을 구현에 넣지 못하는 문제가 있었다.

혹시나, TDD로 숫자야구게임을 구현해 보고 싶다면 꼭 먼저 구현해보고 범균님

동영상을 봤으면 하는 생각이다.

TDD로 개발할 때 개발속도나 설계상의 미흡한 점은 연습을 하면 할수록 보완되리라

생각된다.

그리고 이렇게 TDD로 구현을 완료하고 남은 테스트코드가 추후 유지보수시에도 훌륭한

문서가 될 것이기 때문에 꾸준한 TDD연습이 필요함을 느꼈다.

[참고 URL]

Advertisements

[독후감]나를 표현하는 글쓰기 나를 대신하는 글쓰기 -정형권 저

L

2015년 출퇴근길에 읽은 첫 책이다.

읽게 된 동기는, 올해 큰 목표 중 하나가 “책을 쓰는 것“이기 때문이다.

즉, 책을 쓰기 전 어떻게 준비하고 쓸 것인가에 대한 일종의 워밍업인 셈이다.

책을 읽으면서 인상깊었던 글귀를 옮겨보면..

=============================================================================

  • 책쓰기의 벽은 꾸준함으로 넘을 수 있다.
  • 독자를 분명하게 정하고 글을 써라
  • 자료 수집이나 개요를 구성하는 데 좀 더 많은 시간을 투자하는 편이 훨씬 낫다
  • 일단 초고 형태로 완성을 하고 본격적으로 그 초고를 고쳐 쓰는 데 많은 시간을       할애한다
  • 책을 쓰기 위해서는 평소에도 책을 많이 읽어야 하고 책을 쓰기로 결심하면             참고도서를 계속해서 읽고 생각을 정리해 나가야 한다
  • 책쓰기도 훈련하듯이 온몸이 기억하고 몸에 완전히 밸 수 있도록 매일 글쓰기를     게을리하지 말아야 한다
  • 퇴고 “부족한 부분 보완, 불필요한 부분 삭제, 글의 순서 확인 문장 구성 변경” 고려
  • 기획 => 자료수집 => 뼈대 => 서문쓰기 => 한 꼭지 써보기(마중물) => 꾸준히 쓰기

=============================================================================

키워드를 꼽아보자면 “꾸준함“이 될 것 같다.

사실 “꾸준함“은 무엇을 이루기 위해서는 어디에서나 통용되는 단어이지만,

책쓰기에서도 이 단어가 중요함을 느낄 수 있었다.

그리고 책의 마지막에는 단지 책을 쓰기 위한 마음속의 “동기”만으로는 부족하고,

그 “열망”을 뒷받침할 수 있는 “실천“이 중요하다고 끝맺음을 하고 있다.

나도 대략적인 주제는 정했고, 쓰고자 하는 마음은 어느 정도 가지고 있다라고

생각했지만, 막상 쉽게 시작하지 못하고 있는 것은 바로 그 “동기“, “열망“이

절실하지 않기 때문이지 않을까 싶다.

책을 쓰는 과정이 설사 많이 힘들고 고통스럽더라도 그것을 성취했을 때는

내 성장의 키가 한뼘 더 자라있을 것임은 분명하다.

올해의 가장 크고 새로운 도전이 될 “책쓰기“의 바다에 풍덩 빠질 시간이 되었다!

[독서]2015 올해 읽은 책

  • 기술서적

    객체지향의 사실과 오해(완독)                                                                                  – Spark로 하는 고속 빅데이터 분석과 처리                                                                 – 쉽게 배워서 빨리 써먹는 스칼라 프로그래밍                                                           – 자바 프로그래밍 면접, 이렇게 준비한다                                                                   – 엔터프라이즈 빌드자동화를 위한 Gradle                                                                  – Spring4.0 프로그래밍                                                                                                – 네이버를 만든 기술 자바편                                                                                      – 자바 ORM 표준 JPA 프로그래밍

  • 그 외 양서들(2)

    – 테크니컬 리더(2/9)                                                                                                       – 나를 표현하는 글쓰기 나를 대신하는 책쓰기(1/19)

  • 올해 처음 한 일들

    – SE-Radio듣기(6/18)                                                                                                    – – 아침출근/업무중 운동(5월중)

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

들어가기

팀원 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번에 걸친 수정을 하면서 익숙하지 않은 “모델링“에 대한 “역할“과 “책임“정의가

쉽지 않았다.

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

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

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

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

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

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