디자인 패턴 공부, Member 변경사항 Main 반영, Order 도메인 개발

오늘은 오랜만에 다시 디자인 패턴을 공부하고, Member 브랜치에 반영된 이슈들을 Main 브랜치에 반영했다. 그리고 Order 도메인 계층을 개발했는데 벌써 시간이 지금이 되버렸다.. 뭐 한것도 없는데.. 아 ! 오늘은 내가 이슈로 등록했던 내용(ControllerAdvice)에 대한 포스팅도 했다! 이 포스팅을 하는데 생각보다 많은 시간이 소요되서인지 하루가 무진장 짧게 느껴지는 것 같다.

 

---

디자인 패턴 공부

과거 내가 디자인 패턴을 공부하면서 기록한 내용의 일부분

 

오랜만에 다시 디자인 패턴을 공부 및 복습하기 시작했다. 회사를다니면서 가장 먼저 공부한 것이 디자인 패턴이었는데, 시간이 지나서인지 많이 까먹은 것 같아 다시 공부해야겠다 생각이 들었다. 과거 디자인 패턴을 공부하게 된 계기는 주된 업무였던 프로젝트 분석을 하면서, 소스코드 내에 반복되는 패턴이 보였고, 소스코드를 더 효율적으로 분석하기 위해 디자인 패턴을 공부하게 되었다.

 

과거에는 출퇴근길에 책(쉽게 배워 바로 써먹는 디자인 패턴)과 유튜브를 보면서 디자인 패턴을 공부했었다. 그리고 과거 공부를 하면서, 개인 공부 저장소에 기록도 남겨두었었는데, 지금 다시보니 많이 부족한듯하다.. 다시 복습하고 공부하면서, 블로그 포스팅과 개인 저장소 내용을 업데이트 해야겠다

 

디자인 패턴을 공부하면서 기록을 남긴 저장소: https://github.com/KEEMSY/STUDY/tree/main/Architecture/GoF

 

디자인 패턴에 대해 이야기를 조금 해본다면, 디자인 패턴에 대해 주변사람들과 이야기를 나누면 패턴쟁이, 디자인 패턴을 공부하면 좋은데~..(귀찮음), 패턴을 뭐하러 공부해, 우리가 지금 개발하는 코드들이 반복되면 그게 패턴이야. 등등.. 부정적인(?) 이야기를 많이 들었었다. 그럼에도 불구하고 당시 내가 디자인 패턴을 공부한 이유는 디자인 패턴을 보다보니, 디자인 패턴을 이야기하는 사람들은 이것이 정답이 아니라, 하나의 사례로서 알아두면 좋다. 라는 의도를 갖고 있다는 것을 깨닫게되었고, 나 또한 이 내용들이 친한 선배들이 아끼는 동생들에게 시간 낭비하지 말라며 조언해주는 꿀팁 같았기 때문이다.

 

그리고 디자인 패턴을 공부하면서, 실제 레거시 코드 및 다른 시스템을 분석하는데 큰 도움이 되었고, 유지보수 및 신규기능개발에도 긍정적인 영향을 받았다.

 

하지만 공부한 패턴을 실제 개발에 적용하는 일은 쉽지 않았다. 더 정확히는 해당 패턴을 정확하게 이해하는 것이 어려웠던 것 같다. 사내 스터디(공부하는 내용을 공유)에서 매일 공부하는 디자인 패턴을 공유하고 이야기도 했었지만, 당시 다른 신입개발자분들도 역시 나와 비슷한 상황이었다. 더 많은 분들과 이야기를 나눠봤다면 좋았을텐데.. 아쉽다.

 

시간이 흘러 지금의 나는 과거보다 성장했다고 생각한다. 비록 패턴들에 대해서 뚜렷하게 기억이 나는 것은 아니지만, 다시 공부하면 과거보다 더 깊게 이해하고 응용할 수 있을 것이라고 기대한다.

 

 

---

Member 변경사항 Main 반영

 

오늘 작성한 PR, Member 브랜치를 Main에 병합하였다.

 

오늘은 이전 Member 이슈를 반영한 Member 브랜치를 Main 에 병합하였다. 각 도메인 브랜치를 정기 배포처럼하면 어떨까? 하는 생각에 Member 이슈를 해결하고 바로 Main에 반영하지 않고 해당 도메인의 브랜치에 병합했다. 실무에서는 해보지 못했던 것들을 이렇게라도 해보니 사소한 일이지만 너무 즐거운 것 같다.(혼자서 바보처럼 아빠미소 하고있다.. 정말 행복하다.. 이것이 소확행인가..)

 

이번에 기존 작성하던 PR과는 다른 종류(?)의 PR 과, Issue 를 작성하면서 좀더 체계적인 템플릿과 규칙의 필요성을 깨닫게 되었다. Issue 템플릿을 만든것 처럼 PR 템플릿을 만들어야 겠다.

 

---

Order 도메인 개발

 

개발중인 Order 도메인

 

원래 오늘 목표는 Order 도메인 계층을 개발 완료하는 것이었는데.. 그렇지 못했다. Order 엔터티를 개발 간 테스트를 먼저 작성하면서, 시나리오를 계획하고있다. 그리고 이 과정 간, 이게 필요하겠다 ~! 하고서 하다보면 저게필요하겠다~!,  이것도 필요하지 않을까?하며 점점 도메인 로직이 추가가 되고, 필요한 엔터티가 추가되면서 살짝(?) 정리가 조금 안되는듯하다. 그래도 이것을 몇 시간동안 하다보니 이제는 어느정도 안정(?)권에 들어온듯하다. 내일은 기필코 Domain 계층을 마무리하고서, Application 계층을 개발해야겠다.

 

그런데 개발을하면서 조금 고민(궁금한) 부분이 있다. 실제 실무에서 DDD 및 클린 아키텍처를준수하는 프로젝트에서, 특정 도메인이 새롭게 개발이 된다고 할때, 도메인 계층이 개발완료되고 애플리케이션 계층의 Ports(인터페이스)까지 정해지고나서 각 계층들의 개발이 이뤄지는걸까?? 궁금하다.

 

이에대한 내 생각은 동일한데(인터페이스가 정해지고 나서 다른 계층이 개발이 이뤄진다.) 이렇게 되면, 다른 계층을 개발하는 담당자들은 어떤 일을 주로하려나..? 각 계층에 대한 전문성을 더 깊이있게 준비하나..? 아니면 다른 업무를 좀 더 진행하려나?? 이것도 아니라면 어떻게 협업이 이뤄지는걸까???

---

 

이렇게 궁금한 것을 글로 정리하다보니, 나는 실제 다른 여렇 개발자들과의 협업을 궁금해하는 것같다. 다른사람들과 어서 빨리 함께 프로젝트를 진행해보고싶다. 더 나은 코드를 위해 진행하는 코드리뷰, 기술공유 등등.. 함께 더 많은 문제를 해결하고, 더 많은 경험을 해보고 싶다!!! (생각만으로도 설레...)