코드리뷰로 클린하고 일관적인 프로덕트 만들기

1. 클린하고 일관적인 프로덕트를 위해

클린하고 일관적인 코드만을 프로덕트에 남기는 것은 중요하다. 이를 위해서 뭘 할 수 있을까?

1. 코드 작성과정에서
   1. 유지보수하기 쉽고, 일관성있는 코드를 위해 재사용성이 뛰어난 컴포넌트 제작
   2. 중복되는 기능을 분리하여 모듈화하기
   3. 팀 단위 코드 컨벤션을 정하고, 이에 알맞게 코드를 작성
   4. Eslint와 Pritter등 Linter와 Formatter를 사용
2. 코드 병합과정에서
   
   1. 합의한 커밋, PR, Git 관리 컨벤션에 따라 작성
   2. 리뷰를 받을 때는 Pull Request(혹은 Merge Request)를 상세하고 이해하기 쉽게 작성
   3. 자신이 리뷰어라면 병합에 책임감을 가지고 의문이 생기면 적극적으로 질문

이번 글에서는 2번. 최근 진행한 프로젝트들에서 좋은 코드를 남기기 위해서 코드 병합과정을 어떻게 처리했는지 보여주고, 회고해보고자 한다.

---

2. 상세하게 커밋하기

커밋이 중요한 이유는

1. 게임으로 치면 Save Point. 혹시 잘못되었다면 되돌아 갈 부분
2. 리뷰어 입장에서 Commit이 상세하게 부분별로 잘 되어있어야 리뷰하기 쉬움

따라서 가능한 기능별로 상세하게 커밋해야한다. 그 누구도 게임 플레이 중에 죽었을 때, 3시간 전으로 되돌아가서 다시 하고 싶지는 않을테니까,,, 또한 리뷰가 완료된 후에는 develop 브랜치에 병합할 때에는 rebase와 squash를 이용해서 커밋 내역을 깔끔하게 정리해주는것이 좋다.

 

내용을 어떻게 작성할지는 팀에서 합의한 컨벤션에 따르면 될 것이다. 이제 예시를 보자.

위의 커밋은 가장 최근 진행한 프로젝트, "관리하당"에서 내가 남긴 커밋이다.(관리하당 커밋 컨벤션)

내가 남겼지만 Best Practice라고 생각한다. 하나의 기능이 변경된 것만을 커밋에 담고 있으며, Header는 간결하게 어떤 부분을 수정했는지 적었고, body에서는 단순히 "수정했다"가 아니라 어떤 문제가 있었고 어떻게 해결했는지를 정확히 적고 있다.

---

3. 친절하게 PR(MR) 작성하기

이제 커밋을 남겼으면 Pull Request(Gitlab을 사용한다면 Merge Request)를 작성할 차례다.

 

좋은 PR은 리뷰어가 이해하기 쉬운 PR이고, 리뷰어의 이해를 위해서는 아래와 같이 작성해야 할 것이다.

1. 하나의 주제로
   • 여러 주제를 합쳐서 PR을 날린다면 당연히 리뷰어 입장에서는 헷갈릴 수 밖에 없다. 헷갈린다는 것은 즉 다시 질문을 하건 이해를 위해서 시간을 더 들이건 리소스가 더 투입된다는 뜻이다.
2. 가능한 작게
   • 라인 기술 블로그의 글에 따르면, 400줄이 넘어가면 리뷰어의 문제 발견 비율은 급격히 떨어진다고 한다. 리뷰어 입장에서는 코드가 많으면 많을수록 집중력이 떨어질 수 밖에 없다. (그렇다고 커밋 한 번하고 PR 한 번 날리라는 것은 아니다)
     

     

     Defect density(결함 밀집도) vs inspection rate(결함이 발견되는 비율)

     

     뱅크샐러드의 작은 PR 규칙 후기

   • 작업을 하다보면 커밋이 쌓여버리는 경우가 많은데, 나는 이런 경우를 막고자 가능하면 하루, 정말 어쩔 수 없다면 이틀에 한 번 정도는 반드시 PR을 날리도록 했다.
3. PR 내용은 최대한 자세하고 이해하기 쉽게
   • 이를 위해서는 Template을 사용하면 좋다. 아래는 내가 사용 Template이다.
     ### Part

     - [ ] FE

     - [ ] BE

     - [ ] etc.

     ### Changes

         - Feat:

         - Fix:

         - 논의사항:

     ### Test Checklist ☑️

     - [ ] Checklist

     ### Screenshot(option)​​
   • 이를 통해서 아래와 같이 MR(SSAFY에서는 Gitlab을 쓴다)을 보냈다.

     

     핀테크 서비스 "모익"에서의 Merge Request 내용이다.

 

 

---

4. 적극적으로 리뷰하기

자신이 리뷰어가 되었을 때, 대충 훑어보고 LGTM 날리는 것이 아니라. 코드를 리뷰하는 것 역시도 중요하다. 코드가 프로젝트에 병합되면 그 코드는 팀 모두의 것이 되는 것이고, 즉 모두의 공헌이자 모두의 책임이 되는 것이다.

 

따라서 책임감을 가지고 코드 리뷰에 임해야하며, 혹시라도 의문이 생기거나 수정해야 하는 부분, 혹은 떠오르는 의견이 있다면 적극적으로 제시하는 자세가 필요하다.

---

5. 참고한 글

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기 : NHN Cloud Meetup

형상관리 모범사례\:\ Git 형상관리 이렇게 하세요!

git: 프로답게 commit하는 법

효과적인 코드 리뷰를 위해서

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드