코드 리뷰 - 잘할 수 있을까?

코드 리뷰에 대해 고민된 부분과 이것을 잘 하는 방법은 무엇일까? 고민이 생겨서 코딩한줄 없는 내용이지만 한번 조사하고 정리해봤습니다

사실 코드 리뷰라면 본인이 한 것을 다른 사람에게 설명하고 납득시키고 설득하는 행위와 같은 부분이고 피드백을 받아 수정하고 더 좋은 품질의 코드를 만드는 과정이라고 볼 수 있을 것 같은데요

기존의 경험은 회의실에서 대면 리뷰로만 경험이 있어서인지 깃랩과 같은 플랫폼을 이용하고 비대면으로의 경험이 부족했습니다

지난 포인트 프로젝트의 경우도 구현에만 신경쓰면서 커밋 쪼개기나 작은 Pull Request 와 같은 부분을 자꾸 놓쳐서 아쉬움이 많았는데요

이 때는 상호 커뮤니테이션보다는 서비스 오픈이 중요한 부분이라 어느정도 용인이 되었던 상황입니다

하지만 역으로 제가 하는 경우에서도 제대로 하지 못했습니다. 이 때는 시간에 쫓길 일도 없었는데 전체적인 코드의 구성을 보지 못하고 결론만 보고 지나치게 되었습니다

예를 들면 "A 포인트를 적립하다" 라는 행위에 대해 개발한다면 이런 적립 API 상세 설계를 하게 되면 아래와 같은 행위에 대해 역할/책임/협력 들이 필요할 수 있습니다

누가 -> 회원 인지 / 조회  
무엇을 -> 어떤 포인트 종류들
어떻게 -> 데이터베이스 / 캐시 업데이트  
요청 / 응답 -> 데이터 모델 변환 필요

하지만 단순히 적립할 포인트 정보를 Database에 Insert 하고 끝이나는 내용으로도 볼 수 있을 것 입니다

그렇지만 이렇게 결과만 보고 아! 잘 되었구나 하고 끝나게 되면 "B 포인트를 적립하다" 이런 경우가 생기면 또 똑같은 기능을 다시한번 개발하고 아! 잘 되었구나 하고 또 끝나게 됩니다 또 "C 포인트를 적립하다" 라는 기능을 만들어야 하면 또 똑같은 기능을 만들고 아! 잘 되었구나 하는 의미없는 리뷰를 하게 됩니다

결국 포인트 적립 기능을 3개나 만들게 되었고 캐시업데이트 할 때 포인트 종류에 따라 if ~ else if ~ else if 하는 조건 처리도 늘어날 수 있습니다

각각의 기능은 의존적이지 않지만 포인트 적립이라는 공통의 목적(누가/무엇을/어떻게)은 처리해야 하니까요

비유가 이해되었을 지는 모르겠습니다만 저 스스로 의미 없는 리뷰를 하고 이게 리뷰였다니.. 하는 반성의 예시 였습니다

그렇다고 대면 리뷰를 하는 것이 더 좋을가요?

제 경험으로 얘기하자면 대면 리뷰는 회의실을 예약해야 하고 모니터로 실제 코드를 보면서 한줄 한줄 설명하듯이 진행하게 됩니다

리뷰어와 미리 예약을 하기 때문에 무엇을 할지는 알 수 있지만 그 사람이 모든걸 숙지하고 온다는 보장을 할 수 없고 저의 설명 기반으로 이끌기 때문에 말을 잘 못하면 꼬투리 잡히기 쉽고 실제로 1주일 내내 리뷰만 하다 겨우 머지한 적도 있습니다

이렇게 오래 가게 되면 멘탈도 탈탈 털리게 됩니다 그 당시 리뷰어는 구현 결과는 관심이 없어 보였네요 ㅎㅎ (제가 이름도 잘 못짓고 못한것이지만 느낌은 그냥 절 죽이려는 것 같았어요...)

아무튼 대면으로 진행하는 것도 매우 큰 리소스가 필요해 지는 경우로 보입니다

리뷰를 하는 것도 받는 것도 뭔가 표준화하거나 쉽게 접근하는 방법이 없을까? 이런 고민이 되었습니다

최근에 우아한 형제들 기술 불로그에 감명을 받아서 한번 이런 내용도 있을까 찾아보게 되었는데요 (아래 내용을 다 쓰기에는 글이 너무 길어져서 제가 생각한 중요한 포인트만 추렸습니다)

결국 중요한건 원자적인 접근(작게 쪼개고 작게 커뮤니케이션 하기)

• 공통시스템개발팀 코드 리뷰 문화 개선 이야기(우아한 형제)
• 코드 리뷰 in 뱅크샐러드 개발 문화
• 효과적인 코드 리뷰를 위해서 - 라인
• 효과적인 코드리뷰를 위한 리뷰어의 자세 - 카카오
  • 보이 스카웃 규칙 – 항상 네가 처음 만난 것보다 더 나은 상태로 코드를 만들어놓고 떠나라) 코딩을 위한 보이 스카웃 규칙,{codemotion} 발췌.
• 코드리뷰 예시 (위에글 보다는 훨씬 가볍게 읽히는 내용)
  • 코드리뷰 적응기(feat. 파일럿 프로젝트)
    • NoArgsConstructor 접근권한을 주지 않았었는데요. JPA에서는 프록시를 생성을 위해서 기본 생성자를 반드시 하나를 생성해야합니다. 이때 접근 권한을 AccessLevel.PROTECTED로 설정하여 JPA에서의 Entity 클래스 생성만 허용해줍니다.
    • deleted 라는 필드는 삭제여부를 나타내고, "Y", "N"으로 데이터를 두었었습니다. 하지만 이런 플래그를 사용할 때는 String 을 사용하지 않습니다. 다른 문자도 들어갈 수 있기때문에 boolean 타입을 사용해야 합니다
  • 코드리뷰가 쏘아올린 작은공
    • 주니어 개발자들의 (얕은) 코드리뷰 도입기
  • 코드리뷰 모음 서비스를 소개합니다

선진국이라고 생각된 회사들도 코드 리뷰 문화에 대한 고민들이 있었고 그것을 개선하려는 움직임들이 있었습니다

각각의 문제 정의에 대한 부분은 저랑도 다를 수 있어서 결국 공통적으로 무엇을 해야 하는지만 끄집어 내보겠습니다

• MR 템플릿 구성
  • MR 작성 규칙을 정하고 일관성있는 작성을 한다
  • MR 작성에 대한 고민을 줄어들게 하려는 목적

완성된 MR 템플릿
  # 해결하려는 문제가 무엇인가요?
  *
  # 어떻게 해결했나요?
  *
  ## Attachment
  * 이번 MR 의 Front 동작을 이해를 돕는 GIF 파일 첨부!
  * 리뷰어의 이해를 돕기 위한 모듈/클래스 설계에 대한 Diagram 포함!
 
  작성 예시
  # 해결하려는 문제가 무엇인가요?
  * TS2305: Module '"react-router"' has no exported member 'useHistory'. 에러를 내면서 빌드가 깨집니다.
    다른 모듈에 의해 react-router 버전이 5 -> 6으로 올라간 게 문제입니다.
  # 어떻게 해결했나요?
  * 사용하는 react-router의 버전을 package.json에 명시합니다.

• 코드리뷰 규칙 문서 추가
  • MR 템플릿으로 어느 정도 통일은 갖췄으나 MR 크기와 코멘트 방식이 사람마다 달라서 추가 규칙을 문서로 작성
  • 리뷰이 규칙
    • 코드 리뷰의 설명은 최대한 자세하게 작성되어야 합니다
      • 리뷰 작성자는 본인이 알고 있는 사항을 리뷰어들도 알고 있을 것이라는 가정을 버리고 코드 리뷰에 대한 충분한 문맥이 전달될 수 있도록 코드 리뷰 설명을 자세히 작성해 주세요. (개발자 너 작가가 되라)
      • MR Template에 맞춰서 작성해 주세요. (규칙을 준수해 주세요...)
    • 작은 MR을 유지하세요
      • 리뷰어들이 코드 리뷰에 들어가는 시간을 줄이고 최대한 많은 버그들을 미리 발견해낼 수 있도록 코드 리뷰의 크기는 삭제를 포함해서 최대 300줄 미만으로 유지해 주세요.
        • MR 크기가 작아야 하는 이유
      • 적합한 MR 단위는 어떻게 되나요?
        • 하나의 티켓에서 여러 개의 MR을 작성해도 됩니다.
        • 리팩토링 작업은 분리해 주세요.
        • 작게 쪼개기를 참고해 주세요.
    • 라벨로 코드 리뷰의 우선순위를 표시하세요 (D-n 규칙)
      • 코드 리뷰가 완료되어야 하는 시점을 D-N 형식의 라벨로 코드 리뷰에 추가해 주세요. 예를 들어, D-3 은 3일 이내에 코드 리뷰가 리뷰어에게서 확인되어야 한다는 의미입니다.
      • 이슈가 없는 코드 리뷰는 D-3 라벨로 표기하고 당장 긴급하게 시스템에 반영되어야 하는 사항은 D-0 라벨로 표기해서 모든 리뷰어가 긴급하게 코드 리뷰를 할 수 있도록해 주세요.
      • 매일 라벨을 업데이트해주세요.
      • D-0이 된 다음 날까지 어느 리뷰어도 코드 리뷰를 시작하지 않았다면 리뷰 작성자는 스스로 해당 변경 사항을 코드 베이스에 반영(Merge)할 수 있습니다.
    • 최소 한 명의 리뷰어에게 리뷰를 받아야 합니다
      • 같이 프로젝트를 진행하는 팀원들의 코드 리뷰를 받습니다.
      • 필요하면 같이 프로젝트를 진행하지 않는 팀원을 리뷰어로 할당해서 요청합니다.
    • 피드백을 반영하면 코멘트를 남겨주세요
      • 피드백에 변경한 내용이 무엇인지 리뷰어에게 알려주세요.
  • 리뷰어 규칙
    • 리뷰어는 코드 리뷰의 코멘트에 코멘트를 강조하고 싶은 정도를 Pn 규칙에 맞춰서 표기해 주세요:

       P1: 꼭 반영해 주세요 (Request changes)
       P2: 적극적으로 고려해 주세요 (Request changes)
       P3: 웬만하면 반영해 주세요 (Comment)
       P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
       P5: 그냥 사소한 의견입니다 (Approve)

• 리뷰 작성자를 칭찬해 주세요
  • 리뷰어는 코드 리뷰에 별달리 코멘트할 내용이 없다면 변경 사항을 작업하기 위해 수고한 리뷰 작성자를 칭찬하는 코멘트를 남겨주세요.

위 내용을 보니 반성이 많이 되었습니다

깃랩의 MR 작성부터 너무나 못했었기 때문에 애초에 리뷰가 잘 시작되는걸 바라는게 욕심이었습니다

상대방을 배려하지 못하고 정보를 개떡 같이 올려 놓고 리뷰 잘해주세요 라고 원하는 것이 기본 자세가 안되었고 가장 먼저 고쳐야 할 부분으로 보였습니다

천 마디 말보다는 잘 정리된 그림이 낫겠죠?

## Attachment
* 이번 MR 의 Front 동작을 이해를 돕는 GIF 파일 첨부!
* 리뷰어의 이해를 돕기 위한 모듈/클래스 설계에 대한 Diagram 포함!

작게 커뮤니케이션 하고 공통으로 대화할 수 있는 문서 템플릿을 만드는 정도의 노력? 으로 엔지니어 문화로 창출한 부분은 부러웠습니다

하지만 글을 자세히 보면 하나 더 필요한 문화가 있습니다

라인 - 코드 분석 및 코드 스타일 확인을 거치자

뱅크샐러드 - 인건비가 가장 비싼것 , 코딩 스타일 ( Indent, Convention )

• 코드 리뷰에 임하는 자세
  • 코드 리뷰 과정에서 이루어지는 것
    • 일관된 아키텍처를 유지하고 있는지
    • 다른 해결 방법에 대한 의견 제시
    • 버그가 발생할 수 있는 가능성 제시
    • 기술적인 지식, 노하우 공유
    • 히스토리 전달

바로 일관성있는 코드 스타일에 대한 부분입니다 네이밍 규칙부터 언어적인 Case 예를 들면 Java는 Camel(소문자로 시작) 이지만 C#은 Pascal(대문자로 시작) 입니다

극단적으로 우아한형제들의 부트캠프 코스에 들어가려면 아래 제약사항을 지켜서 과제를 해야 합니다

else 를 쓰지않는 부분은 저도 연습중입니다

• Java Style Guide
  • 내부에서 공통의 코드 형태를 갖추어서 오타같은 사소한 실수들을 막고 가독성을 극대화 하는 것
  • 코딩 스타일을 맞춤으로서 알아보기 어려운 코드 작성 자체를 막아버리고 최소한의 코드 품질을 보장 함
  • 컨플루언스와 같은 사내 위키에 명시해서 규칙을 공유
• 정적 코드 분석과 코딩 스타일 확인은 SonarQube나 ESLint와 같은 툴
• 코딩 스타일의 자동화 관련하여 리서치 결과 SwiftFormat을 도입했고, 스타일 규칙을 팀 내의 합의된 코딩 스타일을 룰로 정했습니다. 빌드 Phase에 SwiftFormat을 실행시켜 자동으로 코딩 스타일을 맞춰지는 프로세스를 만들었습니다
  • 이건 또 새로운 툴 공부...

 

모든 이상적인 부분을 맞추기에는 분명 한계가 있고 결국은 전문화된 QA/QC 조직이 있어서 제조업에서 말하는 Six sigma (완벽에 가까운 제품이나 서비스를 개발하고 제공하려는 목적으로 정립된 품질경영 기법) 정도의 수준으로 관리하려는 것으로 보입니다

많은 SW 회사가 관리 상한/하안을 두고 불량률을 관리하지는 않을 것으로 믿고 싶네요 (인더스트리 내부는 품질 조직은 있을 것 같네요)

마지막으로 사내 컨벤션까지 설정해서 우리가 협의한 대로 코드를 잘 작성했는지 이 부분까지 결정이 되야 진정한 코드 리뷰 조직이 될 수 있을 것 같습니다 모든 사람이 다 다르게 작성하고 리뷰하면 그것 때문에 또 피로감이 생길 수 있으니까요

내용이 길어졌는데 결국 지금 해야할 최소한의 첫걸음은 제가 Merge Request를 진심으로 잘 작성해서 리뷰어를 감동시키는 것이 첫번째가 되야 할 것 같습니다

 

마지막으로 우아한 형제에서 진행하는 교육에서 실제 코드리뷰 사례를 보고 마칩니다

출처(NEXT-STEP) : https://github.com/next-step/java-racingcar