PR 리뷰-피드백, 알고리즘 문제풀이

오늘의 하루는 PR 리뷰에 대한 생각의 정리와 답변, 그리고 문제풀이로 하루가 다 지나갔다. 책도 못봤다.. 오늘 하루 공부 작성을 마치면, 30분정도 읽고 자야겠다.

 

PR을 올리고, 리뷰를 부탁하고나면 메일을 정말 자주 확인하게 된다. 리뷰가 달렸을까? 어떤 리뷰가 달렸을까? 내 고민과 생각을 어떻게 생각하고, 다른 사람의 생각은 어떨까? 하는 생각에 자꾸만 보게 되는 것 같다.(다른사람이 나쁘게보면 어떡하지? 이런건 절대아니다! 오히려 다른사람의 생각이 너무 궁금하다.)

 

Feature/product adapter: DataAccess by KEEMSY · Pull Request #3 · KEEMSY/shoes-ordering-system

---

PR 리뷰 피드백

벌써, 3번째 PR을 마쳤다.

이번 PR은 지난 PR 리뷰 간 피드백 사항을 반영하여 작성하고 또 작업했다.

 

• 첫 PR 보다 단위가 줄어들었지만, 여전히 크다.
• 예외처리에 명확성이 떨어진다.

 

---

지난 피드백: 첫 PR 보다 단위가 줄어들었지만, 여전히 크다.

 

이번 PR의 단위는 더 작은 작업단위로 줄여, 최종 diff 가 456 밖에 안된다! 그리고 이번 PR 에서는 PR 단위가 너무 크다는 피드백을 듣지 않았다. 다행이다.

최종적으로 diff 는 456이 되었다.

그런데 작업량은 적은데(?) 너무 오래걸린것이 아닌가 싶어, 내 자신에 대해 반성하게 되는 것 같다... 개발 전 고민은 불가피하지만, 너무 고민이 많고 실행이 적었던 것은 아닐까? 다음 개발에서는 고민을 조금만 줄여볼 수 있도록 노력해야겠다.

 

 

---

지난 피드백: 예외처리에 명확성이 떨어진다.

 

이 피드백은 과거 특정 메서드에서 예외를 다루는 과정에서 명확성이 떨어지는 것이 아니냐? 하는 피드백을 받은 부분이었다.

지난 리뷰의 일부분

이 부분은 이번 프로젝트에서 어떻게 개선했다. 피드백을 반영한 것은 아니지만, 관련된 공부를 할 수 있었다.

좋은코드, 나쁜코드 프로그래머의 코드 품질 개선법 책의 일부분

 

이 부분은 과거 독서 했던 부분이지만, 잊고 있다가 다시 복습하고 에러(오류)처리에 대한 방법을 고민해볼수 있었다. 내가 주로 하는 오류 처리 방법은 무엇이고, 이 방법과 다른 방법의 차이는 무엇인지 배울 수 있었다.그런데 지금 보니, 또 조금(?) 까먹은 것같다. 이 내용을 STUDY Repo에 정리하고, 블로그 글로도 정리해 놓아야겠다.

 

 

 

이번 PR의 주된 리뷰는 코드에 대한 부분보다는 설계에 대한 리뷰를 받았다. 왜 이렇게 했는지, 차이점은 무엇인지에 대한 설명이 대부분이었던 것 같다. 나는 내가 공부하고 수도 없이 고민하고서 만들었었는데, 막상 이를 쉽게 설명하고자하니, 어떻게 해야 쉽게 설명이 될까? 하는 고민을 하게 되어서 오늘 하루 대부분을 소비한 것 같다.

 

 

---

고민

 

 

그런데 리뷰 중, 정말 큰 고민을 하게 된 것이 있다.

정말 많은 고민을 하게 된 리뷰다..

 

나는 명지님의 이번 리뷰를 통해 정말 많은 생각을 하게 되었다. 왜냐하면, 명지님이 말씀하신, 많은 설명이 필요하지 않은 구조를 보고 한번에 이해할 수 있는 프로젝트 가 이번 프로젝트의 목표이며, 이를 위해 패키지 구조를 일반적으로 작성하는 기술 계층이 아닌 지금의 패키지 구조(도메인형) 을 선택했다. 도메인형을 선택하게 된 추가적인 이유로는 DDD를 적용한 모델링을 적용할 계획이였기에, 더욱더 도메인형 패키지 구조를 통해 프로젝트의 설계 및 구조를 명확하게 파악 할 수 있을 것 이라고 생각했다. 그런데 이런 피드백을 받으니, 약간은 심란하다..

 

이 피드백에 대한 나의 생각

 

하지만 한편으로는 이것이 너무나도 당연한 과정이라고 생각이 들기도 한다. 익숙한 계층형 아키텍처과 계층형 패키지 구조가 아닌 도메인형, 클린 아키텍처(Ports and Adapters) 를 본 사람들이라면, 머릿속 물음표가 드는게 당연하다는 생각이 들었다.

 

이에 대해 관심을 갖고 공부하고 개발하는 내 자신도 계속해서 되새기고, 떠올리는데 처음보는 사람들이라면 더 그러지 않을까?

 

하지만, 이런 의견은 한사람만의 생각은 아니기에 깊은 고민에 빠지게 만드는 것 같다.

 

또 다른 같은 피드백, 사실상 리뷰를 해주는 3명에게 나는 한번씩 공식적으로 설명을 진행했다.

승원이의 피드백또한 너무나도 맞는 이야기이다. 지금의 프로젝트는 너무나도 간단하지만, 아키텍처가 거창하다. 고작 두세개의 유스케이스를 구현하는데, 클린아키텍처를 적용한 프로젝트를 구현하기위해 Adapter, Application, Domain 계층이 나눠지고, Out, In 어댑터와 포트가 또다시 나눠진다. 충분히 이렇게 이야기가 나올만하다.

 

하지만, 이번 프로젝트의 목적을 생각해본다면 나는 지금이 바른 길이라고 생각한다.

프로젝트 시작 전, 작성한 현 프로젝트(신발 주문 시스템)을 계획하게 된 배경

 

나는 이번 프로젝트를 통해 도메인과 아키텍처를 고민하고자 했다. 빠른 제품의 출시가 목표가 아니다. 스프링과 자바, 코틀린 프로젝트를 만들어보는 것이 목표가 아니다.

 

내가 생각한 이에 대한 답변

나는 이번 프로젝트에서 선택을 해야했다.

일반적인 개발 초기단계에서의 프로젝트의 목표(=빠른 제품의 출시) 를 선택할 것인가, 유지보수와 확장성이 좋은 아키텍처를 고민할 것인가? 나는 후자를 선택했다.

 

지난 Member 도메인을 개발하면서 유스케이스가 너무나 한정적이라서 고민이었던 적이 있다. 그리고 Product 에서 같은 고민을 하고있다. 그리고 이것은 앞으로 다른 도메인을 개발하면서도 동일할 것이다.

 

하지만 괜찮다. 겁나지 않는다. 비록 시작은 미약하였지만, 끝은 창대할 것이다! 기능(유스케이스) 추가가 두렵지 않다. 기능 추가를 하는데 있어서 어느 곳에 작업을 해야하고, 변경해야하는지 명확하다. 적어도 지난 레거시프로젝트에서 겪은 문제점은 극복할 수 있는 아키텍처를 가졌기 때문이다.

 

---

알고리즘 문제풀이

 

매일매일 꾸준하게 코틀린으로 알고리즘 문제풀이를 하며, 기초 지식을 쌓아가고있다. 이를 정리하는 포스팅을 작성해야하는데, 자꾸만 내 아이패드에만 정리하고 넘어간다.. 내일은 풀이했던 문제를 모두 정리해야겠다.

 

---

내일은 이제 다시 개발의 시작이다. 내일부턴 Messaging 을 개발할 예정이다. 원래는 오늘부터 진행됬어야하지만.. PR 리뷰 피드백에 너무 많은 시간을 쏟게되면서.. 그렇게되버렸다.. 하하..... 어서 빨리 Messaging, Web Adapter 를 개발하고, 대망의 주문 도메인으로 넘어가보자 !!

 

요즘의 개발적인 고민을 다른 개발자들과 함께 해보고싶다. 그래서 이력서를 빨리 넣어보고싶다. 서류가 붙는다는 보장도 없는데, 그냥 해피패스로 서류 붙고 면접에서 프로젝트관련된 이야기를 나눠보고싶다. 혼자 고민하는 것도 재밌지만, 다른 사람들의 의견을 듣는 것도 너무 재밌고 무엇보다 결과물을 만들어보고싶다. 이를위해 내일은 더 열심히 해야겠지!! 더 열심히!! 부지런히 !!!

 

이력서! 코테 ! 프로젝트 ! 아좌좌 !! 가쥬아 ~~~!