조 은, Eun Cho Front-End Lead at ZET Team - Dable [email protected]
많은 개발 조직에서 코드 리뷰의 가치를 중요하게 여기고, 코드 리뷰를 통해서 좋은 코드를 생산해내는 데 초점을 맞추고 있는 데에 비해서 코드 리뷰를 어떻게 할지는 크게 고민하지 않는 모습을 종종 보았습니다. 저는 아무리 좋다고 알려진 것이라도 조직 내에 어떻게 도입하는가에 따라서 강력한 은탄환이 되기도 하고, 독약이 되기도 한다 생각합니다.
아직 ZET 팀의 프런트엔드 개발 파트는 규모가 아주 작습니다. 저를 포함하여 2명이 프런트엔드 개발자로 업무를 진행하고 있으며, 채용을 위한 다양한 노력을 수행하고 있습니다. 다만 아래 글에서 이야기하는 코드 리뷰 원칙은 조직 규모와 상관 없이 적용 가능한 원칙이라 생각합니다. 이 글에서는 ZET 팀의 프런트엔드 개발자들이 어떻게 코드 리뷰를 진행하고 있는지, 코드 리뷰를 왜 하는지, 코드 리뷰를 위해 어떤 규칙을 정하였는지 등을 이야기합니다.
코드 리뷰란 어디까지나 좋은 코드를 생산해내기 위한 과정 중 하나로, 좋은 코드란 무엇인가에 대한 고민이 항상 병행되어야 합니다. 좋은 코드란 제품에 따라서도 다르고, 팀에 따라서도 다르지만 ZET 팀 FE 파트가 생각하는 좋은 코드의 기준은 아래와 같습니다.
읽기 좋은 코드란 코드에서 개발자의 의도를 파악할 수 있으면서, 이 코드가 실제로 어떤 역할을 하는가를 이해할 수 있는 코드입니다. 따라서 코드 리뷰 과정에서는 특정한 코드, 특히 함수나 메서드, 클래스 이름만 보고도 관심사를 이해할 수 있어야 한다고 생각하고 있습니다.
코드 리뷰를 진행하는 리뷰어, 코드 리뷰를 받는 코드 작성자 모두 좋은 코드를 만들어 나가는 데에 최선을 다해야 합니다. 어떤 코드라도 코드 뒤에는 사람이 있다는 점을 반드시 기억하고, 좋은 코드를 작성하기 위해 서로 지속하여 커뮤니케이션하고, 커뮤니케이션하는 과정에서는 항상 정중하고 예의 바르게 서로 커뮤니케이션을 수행하도록 합니다.
코드를 작성한 사람은 자신의 코드를 리뷰해 줄 수 있는 적절한 코드 리뷰어를 찾을 필요가 있습니다. 코드 리뷰어로는 해당 제품을 함께 개발하는 동료, 그리고 해당 제품에 대한 이해도가 있는 시니어 엔지니어가 적절하다고 봅니다.
어떤 분들은 프런트엔드 개발자이기 때문에 반드시 모든 리뷰를 프런트엔드 개발자가 수행해야 한다고 인지하기도 하지만, 때로 백엔드 개발자도 프런트엔드 코드를 보고 프런트엔드 코드의 동작 방식을 이해할 수 있도록 코드를 작성해야 한다고 생각합니다.
좋은 코드는 언어에 상관없이 이 코드가 어떤 역할을 수행하는 지 명확하게 보여줘야 합니다. 따라서 좋은 코드를 작성하기 위한 노력을 기울일 때에는 이 코드를 어떤 개발자가 읽어도 이해할 수 있도록 명확하게 작성하는 게 중요하다고 생각합니다.
개발자의 코딩 경험이 쌓이면서 기술 선호도가 어느정도 결정되고, 특정한 기술을 사용하는 걸 더 우선시 하는 모습을 종종 보게 됩니다. 하지만 리뷰를 해나가는 데에 '저는 이런 방식을 선호합니다'라고 말하는 건 설득을 하고자 하는 모습도 아니거니와, 설득을 위한 좋은 재료가 아닙니다.
그러니 코드 리뷰를 진행하면서 다른 사람의 코드에 수정 코멘트를 남길 때에는, 이 코드가 수정이 필요한 이유를 기술에 의거하여 리뷰를 남기도록 합시다. 한편 누군가가 코드 수정을 요청했을 때, '이 방식이 당신이 선호하는 방식인가요?' 라고 물어보는 것도 좋은 커뮤니케이션은 아니라 생각합니다.