코드 리뷰를 어떻게 시작할 때 뭘 생각해야 하는지에 대한 재미있는 글이 있어서 짧게 기록해둔다.

Building a better code review process

글의 제목은 더 좋은 코드 리뷰에 대해 이야기를 하지만 것보다는 리뷰를 할 때 코드보다 더 신경써야 할 것들이 뭔지에 대한 이야기다.  코드 리뷰에서 우리가 주로 신경쓰는 부분이 “코드의 품질”이다.  사실 나도 다른 사람의 코드를 리뷰할 때 주로 이 부분을 본다. 얼마나 읽기 편하게 작성했는지, 재사용이라는 관점을 얼마나 반영했는지, 적절한 테스트 코드로 보장이 되는지 등등을 확인할려고 한다.

하지만 이 글에서는 “리뷰의 시작은 코드가 아니다!” 라고 이야기한다.  먼저 확인해야 할 부분은 코드가 아니라 “사용자, 제품“라고 말한다.  리뷰 대상 코드가 실 환경에 배포되면 이로 인해 변경되는 기능이 있다. 변경된 기능이 사용자에게 미치는 영향은 어떤 것이고, 그리고 인한 사이드 이펙트가 없는지를 먼저 따져봐야 한다.

작성된 코드가 사용성의 어떤 부분을 개선하기 위해 목적을 가지고 있는지를 알아야 한다. 이걸 알아야 작성된 것이 제대로 작성된 것인지, 그게 최선인지를 따질 수 있기 때문이다.

이 글을 읽으면서 지금까지 해온 코드 리뷰가 기능적 혹은 형식적이지 않았나 하는 생각이 들었다.  리뷰를 위한 리뷰를 했을 뿐이라는 생각이다. 리뷰의 결과로 반영될 제품에 이 코드가 어떤 변화를 일으키고, 그 변화가 사용자에게는 어떤 도움을 줄지에 대해 생각이 모자랐다.

리뷰 요청 메시지를 작성할 때 “사용자 기능 XXX를 YYY로 변경해서 사용자가 ZZZ 라는 이점을 얻을 수 있다” 라는 형식이 되면 좋을 것 같다.  메시지를 작성하면서 사용자에게 도움이 되는 코드를 작성하고 있는지 한번 더 돌이켜 볼 수 있지 않을까?  “장인(Craftsman)”이라는 관점에서 작성하는 코드의 매력도 물론 있기 하지만 결국 우리가 작성하는 대부분의 코드는 사람을 지향한다. 사람에게 도움이 되는 코드를 작성하는게 이성적 관점에서 옳다.

글을 작성한 분이 코드 리뷰를 진행하기전에 스스로 반문해보면 좋을 질문 리스트가 있어서 옮겨 적어본다.

• Does this change solve a real problem for the customer?
• Is the solution robust, or merely adequate?
• How do we know that this change is a good investment, relative to other things we could be doing instead?
• What new problems might arise as a result of this change, and how will we mitigate them?
• Can the change be easily reversed and/or gracefully degraded if something goes wrong?
• Are there ongoing maintenance costs associated with this change? What are they?

리뷰 진행전에 이 질문들에 대한 명확한 답을 본인이 할 수 있다면 통과할 가능성이 높다.  그만큼 사용자, 제품에 한발짝 도움이 되는 코드를 본인이 작성하거나 리뷰를 해주고 있다는 의미이기 때문이다.

크게 동감한다.