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

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

왜 이렇게 짰어요?

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

이렇게 하면 어떨까요?

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

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

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

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

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

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

무슨 말이 더 필요할까.

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

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

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

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

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

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

 

https://blog.silentsoft.org/archives/20

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