코드 리뷰, 5가지만 기억하자.

코드 리뷰는 좋은 품질의 소프트웨어를 만들기 위한 필수 요소이다.

필자가 속한 팀에서 코드 리뷰를 하면서 아쉬웠던 부분을 꼽자면 바로 Attitude이다. 1:N으로 진행하는 리뷰에서 N명의 리뷰어 중 1명이라도 감정적으로 발언하게 되는 경우 리뷰를 받는 사람은 피곤하고 속상할 수 밖에 없다. 아무리 코드 리뷰가 더 좋은 소프트웨어를 만들자는 취지에서 한다고 하더라도, 기껏 노력해서 열심히 코드를 짰는데 언짢은 소리를 들으면 그 누가 좋아라할까.

해서, 필자가 느낀 ‘서로 이 정도만 숙지해도 괜찮지 않을까’하는 부분을 5가지로 정리해 보려 한다.

계속 진행하기 전에 용어는 아래와 같이 정의하고 넘어가겠다.

• 리뷰자 : 다른 사람이 작성한 코드를 리뷰하는 사람(들).
• 리뷰이 : 본인이 작성한 코드를 다른 사람들에게 설명하고, 리뷰받는 사람.

1. (너무나 당연하지만) 리뷰자는 리뷰이의 코드에 대해 공격적인 질문은 자제하자.

왜 이렇게 짰어요?

이런 질문은 듣는 사람도 기분나쁘고, 리뷰를 지켜보는 사람 입장에서도 안타깝다. 코드 리뷰의 취지를 기억하자. 우리는 코드 리뷰를 통해 미연에 버그를 찾고, 더 좋은 소프트웨어를 만들기 위해 하는 것이지, 남이 짠 코드를 비난하고 내가 더 우위에 있다는것을 각인시키기 위해 하는 것이 아니다.

이렇게 하면 어떨까요?

이렇게 운을 띄우자. 단, 반드시 이유를 제시하여 본인의 취향 강조가 아님을 명백히 하는것이 좋겠다.

2. 리뷰자는 리뷰이의 설명을 다 듣고 발언하자.

리뷰이가 코드와 의도를 설명하는 중에 자꾸 리뷰자가 첨언하면 흐름이 끊겨 리뷰이도 피곤해지고, N명의 리뷰자도 피곤해진다. 코드에 대한 개선 사항이나 의문 사항은 바로 얘기하지 말고, 메모 또는 기억하고 있다가 정리해서 발언하는 것이 한번 더 생각하게 되므로 감정적인 발언을 하지 않게 되는데 효과적이다. 이때, 리뷰이는 너무 길어지지 않도록 (클래스 단위나 비즈니스 단위로) 적당히 끊어서 진행하는 요령이 필요하겠다.

3. 리뷰자가 좋은 코드를 발견했을 때 칭찬과 격려의 발언은 리뷰 중 그때그때 하자.

이 코드는 되게 좋은 것 같아요.

코드를 보니 꽤나 고생하셨겠네요..

무슨 말이 더 필요할까.

4. 불필요한 논쟁은 서로 자제하자.

변수를 여러 줄에 걸쳐 밑으로 선언하는 것과 콤마로 이어서 옆으로 전개하는 것에 대해 토론하는 것 만큼 아까운 코드 리뷰는 없을 것이다. (당연히 이런 논쟁이 그 코드 리뷰의 주 쟁점은 아니었지만) 취향을 존중하자. 그럼에도 불구하고 자꾸 눈에 거슬린다면 과반수 이상의 동의를 얻고 코드 컨벤션을 정의하는 것도 불필요한 논쟁을 피하는 좋은 방법이 될 수 있겠다.

5. 좋은 코드의 방향을 제시하되, 코드 수정을 강제하지 말자.

이 줄은 이렇게 바꾸셔야 합니다.

정책인가? 그렇다면 수용해라. 표준인가? 역시 수용해라. 바꾸지 않으면 에러가 날 가능성이 있는가? 당장 수정해라.

바꿔도 그만, 안바꿔도 그만인 코드에 대해서 강제하지 말라는 얘기이다. 정책도 아니고, 에러의 가능성도 없다면 코드의 수정은 리뷰이에게 맡겨라. 그런 코드를 강제해서 리뷰 결과 Fail을 받는다면, 팀원 스스로도 질책하게 되고, 나아가 어느 순간 전체 팀원들의 사기가 떨어진다. 이런 위협 요소는 없앨 수 있다면 가능한 없애야 한다.