Application 계층 완료, Adapter 개발시작, 디자인패턴공부

오늘은 Application 계층 개발을 완료하고, PR 및 Merge 했다.테스트와 관련된 부분에서 이슈가 된 부분들이 많았는데, 나름의 생각정리하다보니, 지금 코드로 해당 계층의 1차 개발을 마칠 수 있었다. 오전에 PR을 작성하고, 오늘 독서로는 디자인 패턴을 독서했다. 템플릿 메서드를 응용한 팩토리패턴, 싱글턴 패턴을 복습했다. 둘다 사용해본 패턴이라 그런지 코드를 분석하는것이 어렵지 않았다. 패턴을 보면 항상 느끼는 것이 프로그래밍은 철처한 역활극 놀이인 것같다. 정신나간 놈 같지만, 상상을 좋아하는 나로써는 정말 재밌는 것 같다.

 

---

Application 계층 완료, Adapter 개발시작

 

Order 도메인의 유스케이스는 2개뿐인데 이렇게 많은 것을 고민하고 배울 수 있을 것 이라는 생각은 못했던 것 같다. 이전에 Member, Product 를 개발 간 작성한 테스트 코드로, Order 에서는 좀 더 빠른 개발을 할 수 있을 것이라고 생각했는데, 오히려 반대였다.

 

테스트 코드를 작성할 수록, 이전에 작성했던 테스트 코드의 개선점들이 점점 보이기 시작했다. 나는 테스트 코드를 하나의 문서처럼 사용하고 싶었는데, 가만보니 테스트 코드가 작성자 기준으로 되어 있어 깔끔하게 읽히지 않는 것 같았다.

 

Command 를 사용하는 CommandService의 테스트의 일부분

나는 createOrder() 메서드를 검증하기 위해, 필요한 요소를 모두 Given 영역에서 만들었다. 그런데 필요한 요소들은 사진과는 다르게 헬퍼 메서드를 사용하지 않았다.

 

createOrderItem 헬퍼 메서드의 내부 모습

헬퍼 메서드를 사용하기 전에는, 테스트가 가독성이 많이 떨어졌던 것 같다. createOrderItem 메서드의 내용은 OrderItem 을 만든다는 것을 이해하는 것은 어렵지 않다. 그렇다고 해당 메서드를 사용하지 않는 것이 좋다는 생각은 들지 않았다. 코드 줄수가 늘어남으로써, 해당 검증의 흐름을 한눈에 파악하기 어려웠기 때문이다.

 

그래서 나는 Order 애플리케이션 테스트를 작성하면서, 헬퍼메서드를 적극 사용했다.

 

 

Adapter 개발: Messaging

나는 애플리케이션 계층을 마무리하고 Adapter 계층을 개발하기 시작했다. 가장 먼저 내가 시작한 것은 Adapter의 out에 해당하는 Messaging 을 개발하는 것이었다. 매도 빨리 맞는게 낫다고, 가장 자신없는 부분을 빨리 끝내고자 하였다.

 

이제 Avro 모델을 만들기 위한 avsc 파일작성은 어렵지 않았다. 그러나 이전의 문제였던 정상적으로 카프카 클러스터와 상호작용하며, 이벤트가 발행됬음을 검증하는 것이 내 발목을 잡았다.

 

그렇게 고민을 했는데, 어떻게 테스트를 진행해야할지 모르겠다..  단순하게 publisher 와 consumer 만 있으면 테스트를 할 수 있을 것이라고 생각했는데, 이를 위해서는 카프카 클러스터가 테스트 환경에서 필요했다.(로컬의 카프카클러스터 없이)

 

로컬의 카프카클러스터 없이 테스트 하기 위한 방법을 찾아보다, spring-kafka-test 와 EmbeddedKafka 설정을 알게되었다. 나는 이것을 통해 로컬 카프카 클러스터 없이 카프카 메시징 테스트를 진행할 수 있을 것이라 생각했는데 생각보다 이게 쉽지 않은 것 같다.

 

기존의 application.yml 에 내가 설정한 카프카 설정과 해당 사용을 위한 카프카 설정이 다른것인지... 내가 카프카 사용을 위해 정확하게 알고 있는 것이 아니라서 문제가 되는 듯하다..(몹시 반성하는중이다..) 카프카는 publish, consume 만 잘하면 된다 생각하며, 강의에서 사용했던 코드를 그대로 사용한 것 이 지금 많이 후회스럽다.. 당시에 좀 더 내가 찾아보고 공부했다면  지금 이러진 않았을텐데.. 아쉽기만하네..

 

하지만 지금 후회의 시간도 아깝다. 지금이라도 이 설정을 공부해서 어서 이 문제를 해결해야겠다.

 

---

디자인 패턴 공부

 

이번 패턴 공부(독서)를 하면서, 이전에는 생각해보지 못했던 패턴 이용에 대한 부분을 고민해 볼 수 있었다.

 

나는 레거시 코드를 분석하면서 코드에 특정 패턴이 반복되는 것을 보고 공부를 하면서 디자인 패턴이라는 것을 알게되었다. 그리고 디자인 패턴에 대한 내용을 보면서, 이를 공부하면 당시 주된 업무였던 코드 분석 및 개발에 큰 도움이 될 것이라 생각하여 공부를 하기 시작했다 하지만 디자인 패턴을 공부한다고 안보이던 패턴이 보이고, 복잡한 클래스간의 관계를 한순간에 이해하게 된 것은 아니었다.

 

시간이 지나 지금, 나는 사이드 프로젝트를 개발하고, 디자인 패턴을 복습하고 있다.공부를 진행하면서 자주 들었던 말에는 실제로 하는 일에 비해 복잡한 프로그래밍이 아니냐? 는 말을 정말 많이 들었었다. 이에 대하여 나는 세분화된 것이 왜 나쁜것인지 이해하지 못했고, 복잡한(?) 설계를 설명하기 바뻤다.

 

그리고 이번 책을 보면서, 내가 부족했던 부분에 대해 알수있었다. 나는 설계의 의도를 명확하게 전달하지 않았던 것이다. 왜 이런 계층이 존재하고, 각 계층의 역활과 이렇게 계층이 나눠진 이유에 대해 설명이 부족했었던 것같다.

 

일반적으로 디자인 패턴을 사용해 어떤 클래스군을 설계할 경우, 그 클래스군을 보수하는 사람에게 설계자가 의도한 디자인 패턴이 무엇인지 잘 전달할 필요가 있다.

- 책의 일부분 ... -

 

책의 해당 부분을 읽고서, 레거시코드와 내 아키텍처를 설계하던 내 모습이 떠올랐다. 레거시 코드에서 사용한 패턴에 대한 설명이 있었다면 어땠을까? 나는 설계에 대한 세부사항을 좀더 작성해두었다면 어땠을까? 하는 생각이 많이 들었다.

 

레거시 코드에서 사용된 디자인 패턴에 대한 설명이 있었더라면, 나는 디자인 패턴을 공부하면서 좀 더 깊은 패턴에 대한 이해와, 거대한 레거시 프로젝트를 이해할 수 있었을 것이다.

 

내가 설계에 대한 세부사항을 좀 더 잘 작성해두었다면, 리뷰를 해주는 고마운 사람들에게 리뷰를 하는데 있어 부담감을 줄여주고, 작성한 코드에 더 집중하여 리뷰를 진행할 수 있었을 것이다.

 

그저 짧고 간략한 문장이었지만, 많은 깨달음과 자기반성을 할 수 있었다. 이렇게 보니, 디자인 패턴을 복습하면서 디자인 패턴 그 이상을 얻어가는 것 같다. 역시 아는 것도 다시보고, 또 봐야겠다.

 

---

 

자꾸만 막히는 프로젝트에 발목을 많이 잡히는 것 같다. 원래 공부하려했던 부분을 막힌 부분을 고민한다고 못하고, 포스팅을 통해 정리할 내용도 포스팅을 못하고.. 안되는 것을 계속 잡고있는다고 해결되지 않는데, 정말 잘 안풀릴 때 다른 것을 하는 습관을 들여야겠다.(리프레시를 위해!!!)

 

일정 관리를 좀 더 잘해보자 !!!!!!! 성연아 !!!