brunch

You can make anything
by writing

C.S.Lewis

헤어샵 백엔드 개발자 코드 리뷰 - 단일책임원칙 편

지극히 주관적인 저스틴 코드 리뷰 방법 - 1

안녕하세요 카카오헤어샵 서비스 개발팀의 저스틴이라고 합니다 :)

저는 코드 리뷰가 두 가지 타입으로 나뉘는데요
첫 번째, 회사적 코드 리뷰
두 번째, 교육적 코드 리뷰

코드리뷰라는 것이 사실 보는 관점마다 다를 수가 있습니다

그렇지만?! 개발자들은 무엇인가 배우고 반론하는 것을 좋아한다라는 것을 가정하고 두 번째인
교육적 코드 리뷰를 진행한다면 어떻게 진행할 것인가에 대해서 글을 적으려고 합니다

교육적 코드 리뷰라고 하니 뭔가 되게 배울게 많고 그런 것 같지만 우리가 배웠던 것 내에서
특정한 규칙, 틀 내에서 리뷰를 진행하는 것
입니다.
스타일 가이드, 클린 코드, 객체지향 등이 있겠지만 그중 객체지향에 대해서 간략하게 이야기를 나누려고 합니다

갑자기 객체지향적으로 코드 리뷰하면 뭐지?라고 생각할 수 있지만
제가 생각하는 가장 큰 방향은 객체의 책임과 역할이 잘 분리되어 있냐!입니다.
여기서 이를 지키기 위해 흔히 우리가 알고 있는 단일책임원칙이 가장 먼저 이야기될 수 있습니다.


(실제 코드 아닙니다..)  
극단적으로 위와 같은 예시가 있을 때, 어떤 생각이 드시나요?
위의 코드들이 Service Layer와 같이 사용되고 있다면 어떠한 일들이 일어날지 상상이 가시나요?
이를 개선하고 싶어 근질근질하시는 분들은 저와 개발 스타일이 비슷한 분들인 것 같습니다!! 같이 언젠간 일하면 좋을 것 같네요 :)

무튼 이를 조금 더 개선해 본다면!!



우선 각 책임에 맞게 역할을 나누어 볼 수 있을 것 같네요!
역할과 책임에 맞게 나누었을 때 가장 중요한 이해하기 쉬운 코드, 가독성이 높은 코드, 유지보수가 용이한 코드를 만들 수 있는 한 걸음 내딛는 결과를 볼 수 있을 것 같아요!

물론 여기서 Product 에 아직 있는 updateShopAddress, changeReview 도 바꾸면 좋은데 말이죠
이를 다른 곳에서 사용할 수도 있기 때문에 사이드 이펙트를 검증하고 변경하면 좋겠죠?


책임과 역할 분리에 대해서 간략한 예시를 통해 살펴보았는데요

앞으로 코드리뷰를 할 때 저스틴의 주관적인 시점에 대해서 궁금하신 분들은 지속적으로 찾아주시면 좋을 것 같네요!! 그럼 Bye~


궁금한 점, 이해한되는 점은 언제든 댓글로 달아주시면 친절히 답변드립니다 :)




매거진의 이전글 언제까지 자동으로 잡아 주길 원해.
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari