코드 리뷰를 잘 받기 위해 리뷰어의 경험 설계하기

우리는 프로그램을 개발하면서 코드를 작성하고 작성된 코드를 리뷰를 받고 기존 코드 베이스에 통합하는 과정을 거치게 되는데요.

코드 리뷰를 통해서 작성된 코드에서 버그를 찾거나, 더 좋은 설계에 대한 고민을 나눌 수 있기 때문에 코드 리뷰는 개발 프로세스에 있어서 중요한 요소로 여겨지고 있어요. 하지만 코드 리뷰라는 과정에서 PR의 크기가 크거나, 남들이 잘 모르는 도메인에 대해서라면 좋은 리뷰를 받기가 어려운데요. 이런 상황에서 코드 리뷰어의 경험을 설계하여 좋은 코드 리뷰를 만들 수 있는 방법에 대해 예시와 함께 설명해보려고 해요.

코드 리뷰에 대해서 생각해 봐요

• 남이 작성한 코드를 읽고 리뷰하는 것은 많은 비용이 들어요.
• 그렇기 때문에 리뷰어의 코드 리뷰를 돕기 위한 무언가가 필요해요.
  • 도메인 지식
  • 문제를 해결한 방식과 그 이유
  • 작업의 핵심이 되는 부분
  • 의미 없는 diff 제거
  • 기타 등등
• 이런 경험을 설계하는 것은 코드 작성자는 물론이고 리뷰어를 위해서도 필요해요.

먼저 리뷰어의 경험을 설계하는 단계를 이렇게 정의했어요

단계 세분화 (가장 작은 단위)

• 도메인 지식 찾기
• 해결하려는 문제 찾기
• 기술적인 해결 찾기
• 에너지를 가장 많이 쏟았던 부분 찾기
• 사이드 이펙트 찾기
• 요약 및 가장 중요한 포인트 찾기

단계별로 실행 가능한 액션

• 문제를 이해하기 위해 필요한 도메인 지식을 간단하게 작성한다.
• 작성한 코드가 어떤 문제를 해결하려는 것인지 글로 작성한다.
• 문제를 기술적으로 어떻게 해결했는지 글로 작성한다.
• 내가 작업하면서 가장 많이 시간을 쏟았거나 고민했던 부분을 글로 작성한다.
• 해당 작업을 통해서 다른 부분에도 영향이 갈 수 있는지 확인하고 글로 작성한다.
• 이제 위에서 작성한 내용들을 각 단계별로 간단하게 1~2줄로 축약하고 그중에서 리뷰어가 가장 집중해서 봐야 할 부분에 대해서는 따로 언급한다.

리뷰어의 경험을 설계하는 단계와, 각 단계별로 어떤 액션들을 해보면 좋을지를 작성했어요.

그리고 예시를 통해서 실제로 어떤 식으로 접근하면 좋을지 알아보려고 해요.

로또 프로그램을 예시로 경험을 설계해요

기존에 웹을 기반으로 만들어져 있던 로또 프로그램이 있다고 가정할게요.

여기서 연금 복권을 판매할 수 있는 기능도 추가하고자 하는 상황이에요.

저는 프론트엔드 개발자로서 해당 요구 사항을 전달받아서 해당 기능을 추가했고

코드 리뷰를 받기 위해서 PR을 올리려고 해요.

 

1. 해당 PR을 이해하기 위한 도메인 지식에는 어떤 것들이 있는지 작성해 봐요.

(여기서는 연금 복권이라는 상품에 대해 가상의 규칙을 만들었어요.)

• 연금 복권은 구매자의 나이에 따라 가격이 다르다.
• 연금 복권은 구매자의 나이에 따라 구매할 수 있는 수량이 다르다.
• 연금 복권은 한 사람이 1달에 50장을 넘게 구매할 수 없다.
• 연금 복권 당첨금 수령은 판매처에서는 신경 쓰지 않아도 된다.

2. 작성한 코드가 어떤 문제를 해결하려고 하는 것인지 작성해 봐요.

(우리가 겪고 있는 문제에 대한 설명을 작성해요.)

• 구매자의 나이에 따라서 가격과 구매할 수 있는 수량이 달라져서 이런 예외처리를 효과적으로 할 수 있어야 한다.
• 한 사람당 1달에 50장을 넘게 구매할 수 없기 때문에 총 몇 장을 구매했었는지에 대한 기록을 잘 기록할 수 있어야 한다.

위의 두 규칙들은 PR보다 어떤 툴을 사용하냐에 따라서 Github, Jira 등의 이슈에 같이 작성해 주면 좋을 것 같아요.

 

3. 문제를 해결하기 위해 기술적으로 어떻게 접근했는지를 작성해 봐요.

• 일관된 예외처리를 하기 위해 validation을 다루는 하나의 모듈을 만들었다.
• 리액트로 웹 프로그램을 만들고 있었기 때문에 선언적인 에러 처리를 하고자 에러바운더리를 사용했다.
• 나이와 수량에 대해서는 어디서든 동일하게 사용될 수 있도록 매직넘버를 없애고 상수화하여 관리했다.
• 프론트에서는 UX를 위한 에러처리를 주로 하고, 서버에서 조건을 더욱 엄격하게 검증하도록 백엔드 개발자와 협의를 했다.
• 당첨금 수령을 우리가 만든 프로그램에서 하는 줄 알고 찾아오는 사람을 위해 별도의 안내 팝업을 만들었다.

4. 작업하면서 가장 많이 시간을 쏟았던 부분을 작성해 봐요.

(이 부분이 사실상 코드에서 가장 중요한 부분이 될 거예요)

• validation을 위한 모듈을 만드는데 시간을 많이 쏟았다.
• 에러 처리를 어떻게 하는 게 사용자 경험에 좋을지 고민이 많이 되었고 Alert를 띄워서 사용자에게 인지시켜줬다.

5. 작업한 코드에서 다른 도메인에 영향을 줄 수 있는 사이드 이펙트가 있는지 작성해 봐요.

• 지금 상황에서 연금 복권 기능이 추가되었다고 해도 기존 로또 기능에는 영향이 없을 것으로 보인다.
• 그래도 혹시 모르니 걱정되는 면이 조금 있다.

6. 위에서 작성한 내용들로 작업을 요약하고 중요한 포인트를 작성해 봐요.

• 결국 예외 처리를 선언적이고 명확하게, 일관되게 가져갈지에 대한 고민이 가장 컸다.
• 또한 혹시나 이 기능이 다른 도메인에 영향을 줄지 다시 한번 확인은 해봐야 할 것 같다.

이제 PR을 올리기 전에 작업을 하면서 가장 많은 시간을 쏟았던 부분, 중요한 포인트들을 작성하고 리뷰어가 어떤 부분에 신경을 써줬으면 좋겠는지 리뷰어에게 전달해요. 이런 과정을 거치고 PR을 올리게 되면 코드를 작성한 나 스스로도 다시 한번 작업 내용을 정리할 수 있고, 코드를 보는 리뷰어도 내가 무엇에 집중해야 하는지 알 수 있어서 더욱 효과적인 리뷰를 할 수 있어요.

마무리

사람은 어떤 일을 하더라도 내가 무엇에 집중해야 하는지를 알고 모르냐에 따라서 일의 효율이 매우 달라지게 되는데요. 코드 리뷰를 하는 과정 속에서도 리뷰어는 내가 무엇에 집중해야 하는지 알고 있어야 더욱 효율적인 리뷰를 할 수 있어요. 하지만 개발자의 특성상 코드 리뷰에 많은 에너지를 쏟을 수는 없는데요. 따라서 코드를 작성한 사람이 코드 리뷰어의 경험을 어떻게 설계하냐에 따라서 코드 리뷰어의 시간을 아껴주는 것은 물론이고 의미 있는 코드 리뷰를 만들 수 있다고 생각하고 있어요. 따라서 이런 관점으로 코드 리뷰어의 경험을 설계해 보시는 것을 추천드리고 싶어요.