새삼 코드리뷰를 왜 해야 하나 의문이 들었다. 막연히 ‘하면 좋겠지’라는 생각은 든다. 그런데 의심은 없어지지 않는다. 정말로 좋을까? 하나 마나라면? 오히려 악영향을 주지 않을까?
코드리뷰의 본질을 고민해볼 필요가 있다.
코드리뷰는 사람만 할 수 있는 일이어야 한다. 자동화 도구로 확인할 수 있는 부분은 코드리뷰에서 신경 쓸 필요가 없다. 다음 것들은 신경 쓰지 않아도 된다.
하지만 더 좋은 성능을 낼 수 있는 방법, 더 읽기 좋은 코드를 위한 방법, 변화에 대응하기 쉬운 하드웨어가 아닌 소프트웨어를 만드는 방법을 위해 개선할 수 있는 여지가 있다면 이는 코드리뷰를 통해야 한다.
코드리뷰는 클린 코드와 클린 아키텍쳐를 위해서 행해져야 한다.
그렇다면, 그런 코드리뷰를 잘하려면 어떻게 해야 하는가? 공부해야 한다. 무엇이 읽기 좋은 코드인지, 변화에 유연한 코드를 어떻게 만드는지 알아야 한다. 개인의 사소한 취향이 코드리뷰에 사용되지 않아야 한다. 사실이나 논리적인 근거가 뒷받침되지 않은 견해는 존중되어져서는 안된다.
물론, 소프트 스킬도 중요하다. 하지만 이런 것은 우선순위가 낮은 것 같고 나중에 사람들과 부딪히면서 배워도 될 것 같다.
시니어 개발자가 없는 현재 개발팀에서 코드리뷰 과정을 업무 프로세스의 일부분으로 강제할 지 고민하고 있었는데 코드리뷰의 본질을 고민하고 보니 지금은 코드리뷰를 강제하지 않아야겠다는 결론을 내렸다. 클린 코드와 클린 아키텍쳐를 먼저 공부하고 이에 대해 논의하는 시간을 가지는 것이 코드리뷰를 위해 시간을 할애하는 것보다 훨씬 나을 것 같다. 시간이 되는 대로 아키텍쳐 공부한 내용을 공유하는 시간을 갖자. 그리고 이를 기반으로 작성되었던 코드를 어떻게 개선할 수 있는지 구체적인 방법을 제시하자.