Home 좋은 코드 리뷰를 위한 규칙
Post
Cancel

좋은 코드 리뷰를 위한 규칙

1. 글을 작성하게 된 계기


평소 어떻게 하면 서로가 성장하는 코드 리뷰를 할 수 있을까? 에 대해 관심이 많았습니다. 같은 시간을 투자해 개발하더라도, 어떤 피드백 을 받는지에 따라 새로운 지식을 습득하기도, 성장하기도 하며, 또는 감정이 상해 개발을 하기 싫어질 수도 있기 때문입니다.

어차피 같은 시간을 투자해 개발할 거라면, 재미있게, 또 새로운 내용을 습득하며 개발하면 좋잖아요? 😊





이러한 고민을 하며 코드 리뷰를 할 때 적용할 만한 규칙을 생각/정리했고, 이를 기록해 두기 위해 글을 작성하게 되었습니다.

주관적 기준으로, 하나의 참조로만 봐주시면 감사하겠습니다.





2. 코드 리뷰 규칙


괜찮다 싶은, 프로젝트에서 도입했던 규칙은 다음과 같은데, 이에 대해 살펴보겠습니다.

  1. 적절한 이모티콘을 사용한다.
  2. 가급적 상세히 답한다.
  3. 정답을 알려주기 보다 상대방이 성장할 수 있도록 여지를 준다.
  4. 너무 과몰입 하지 않는다.
  5. 코드 리뷰 주기를 일정하게 가진다.





2-1. 적절한 이모티콘을 사용한다.

상대방과 대면하고 있을 때, “이거 왜 이렇게 했어요?”라고 물으면 비언어적 요소(감정, 말투, 톤) 를 캐치해 상대방의 의도 를 알 수 있습니다. 하지만 같은 질문을 로 전달하면, 비 언어적 요소가 전달되지 않기 때문에 내 의도가 잘 전달되지 않으며, 오해가 생길 수도 있습니다. 따라서 코드리뷰 과정에서 비언어적 요소를 전달하기 위해, 적절한 이모티콘을 사용합니다.

   - ex1) 이거 어떤 의도로 구현하신 거에요? 👀 (궁금)
   - ex2) 만족한 질문/답변, 혹은 확인한 내용에 대해 👍 표시 (만족)

image







2-2. 가급적 상세히 답한다.


나는 이 코드를 작성했기 때문에 코드의 의도, 로직을 명확히 알지만 리뷰어는 문맥 파악이 되지 않은 상태 입니다. 따라서 해당 코드(혹은 개념)에 대해 가급적 상세히 답변 합니다.

image







2-3. 정답을 알려주기 보다 상대방이 성장할 수 있도록 여지를 준다.


1부터 10까지 더하는 프로그램을 만들 때, 아래 두 가지 방법 모두 정답입니다. 심지어 홀수, 짝수를 나눈 후, 마지막에 더해줘도 되겠죠?

1
2
3
4
5
6
7
public int sum() {
    int result = 0;
    for (int number = 1; number <= 10; number++) {
        result += number;
    }
    return result;
}
1
2
3
4
5
6
7
public int sum() {
    int result = 0;
    for (int number = 10; number >= 1; number--) {
        result += number;
    }
    return result;
}







즉, 코드에 정답은 없기 때문 에 곧바로 자기 생각이나 구현 방법을 알려주기보다 상대방이 그 부분에 대해 학습할 수 있는 키워드 를 줘서 성장의 여지를 줍니다.

image

단, 실무라면 수도 코드 를 제시해서 빠르게 수정/배포할 수 있도록 해야겠죠?







또한 리뷰를 주고 결론을 맺지 않으면 코드 리뷰를 받는 사람이 혼란스러울 수 있으므로 자신만의 결론을 내릴 수 있도록 항상 끝맺음을 지어줍니다.

image







2-4. 너무 과몰입 하지 않는다.


개발에 과몰입(?)하면 코드에 대한 부정적 리뷰를 받았을 때 내가 부정 당하는 느낌 이 들 수도 있습니다. 하지만 코드와 나는 동일하지 않으며, 코드 리뷰는 단지 내가 작성한 코드에 대한 상대방의 의견/판단 일 뿐입니다. 이에 대해 너무 기분 나빠하지 않습니다. 물론 리뷰어도 최대한 예의를 지켜서 하는 것이 좋으며, 내가 틀린 부분이 있다면 인정하고 즉각 반영 합니다.

image







2-5. 코드 리뷰 주기를 일정하게 가진다.


코드 리뷰 주기를 일정하게 가져갑니다. 한 코드 리뷰 후 계속해서 리뷰가 없다면 문맥이 끊어지고, 어떤 작업을 했는지 잊어버리게 됩니다.

image







3. 정리


프로젝트에 도입했던 코드 리뷰 규칙에 대해 살펴보았습니다. 아직도 코드 리뷰는 여전히 어렵고, 잘 못하지만, 회의를 통해 나름대로 괜찮다 싶은 규칙을 선정하고 팀 문화에 맞게 녹여냈습니다. 더 좋은 규칙이 많겠지만 아직까진 잘 생각나지 않습니다. 혹시 더 괜찮은 방식이 있다면 댓글로 알려주시면 감사하겠습니다.

   - 효과적인 코드리뷰를 위한 리뷰어의 자세
   - 효과적인 코드 리뷰를 위해서
   - 우리 팀의 코드리뷰 문화, 이렇게 조금씩 발전했어요
   - 공통시스템개발팀 코드 리뷰 문화 개선 이야기



This post is licensed under CC BY 4.0 by the author.

Singleton Pattern

멀티 모듈에서 RestDocs 문서가 흩어질 때, 어떻게 해결할까?