코드 검토를 통해 배운 5가지 교훈

“이 프로젝트의 코드 리뷰는 시간 낭비입니다.”

“코드 리뷰를 할 시간이 없습니다.”

“나의 못된 동료가 아직 내 코드를 검토하지 않았기 때문에 출시가 지연되었습니다.”

“내 동료가 나에게 코드를 변경하라고 요청했다는 것을 믿을 수 있습니까? 그래도 코드를 변경해야 하나요?”

왜 코드 리뷰를 해야 하나요?

전문 소프트웨어 개발자의 가장 중요한 목표 중 하나는 작업 품질을 지속적으로 개선하는 것입니다. 하지만 팀워크를 통해서만 우리의 노력을 한 곳에 집중하고 소프트웨어 품질을 향상시킬 수 있습니다. 코드 검토는 이 목표를 달성하는 가장 중요한 방법 중 하나입니다. 특히 코드 검토를 통해 다음을 수행할 수 있습니다.

다른 관점에서 결함과 더 나은 솔루션을 발견합니다.

귀하의 코드를 잘 아는 사람이 한 명 이상 있는지 확인하세요.

선임 개발자의 코드를 통해 신입사원 교육을 도와주세요.

지식 공유를 장려합니다.

검토 중에 다른 사람에게 들키지 않도록 개발자가 더 나은 코드를 작성하고 코드의 문제를 해결하도록 동기를 부여하세요. 　

코드 리뷰는 철저해야 합니다

그러나 실제로 코드 리뷰에 시간과 에너지를 쏟지 않으면 위의 목표는 달성하기 어렵습니다.

제 생각에는 원래 개발 시간의 약 25%를 코드 검토에 투자해야 한다는 것입니다. 예를 들어 개발자가 프로그램을 구현하는 데 이틀이 걸린다면 검토하는 데 약 4시간이 걸립니다.

물론 시간이 가장 중요한 것은 아닙니다. 중요한 것은 코드를 올바르게 검토할 수 있는지 여부입니다. 검토 중인 코드를 이해해야 합니다. 즉, 해당 구문을 알아야 할 뿐만 아니라 코드가 애플리케이션의 컨텍스트에 어떻게 적합하고 구성 요소나 라이브러리의 일부가 되는지 이해해야 합니다. 각 코드 줄의 의미를 파악할 수 없다면 검토가 적절하지 않으며 그다지 가치가 없을 것입니다. 이것이 바로 잘 실행된 코드 검토를 신속하게 완료하는 것이 대부분 불가능한 이유입니다. 타사 API가 올바르게 사용되는지 확인하기 위해 특정 기능을 트리거하는 다양한 코드를 연구하는 데 시간이 필요하기 때문입니다.

검토할 때 코드 결함 및 기타 문제를 찾는 것 외에도 다음 사항도 확인해야 합니다.

필요한 모든 테스트를 포함합니다.

적절한 디자인 문서가 작성되었습니다.

테스트와 문서 작성에 능숙한 개발자라도 코드를 변경할 때 코드 업데이트를 잊어버리는 경우가 많습니다. 코드 검토를 통해 이 정보가 시간이 지나도 쓸모 없게 되지 않도록 해야 합니다.

과도한 코드 검토를 피하세요

개발자는 검토 작업의 백로그를 정리하기 위해 노력해야 합니다. 한 가지 접근 방식은 아침에 코드 검토를 수행하고 자체 개발 작업을 시작하기 전에 검토를 완료하는 것입니다. 물론 점심 식사 전후나 하루가 끝날 때에도 코드를 검토할 수 있습니다. 전체적으로 코드를 부담이 아닌 일상 작업의 일부로 다루어야 하므로 다음을 피해야 합니다.

검토 작업의 백로그를 처리할 시간이 없습니다.

심사 미비로 출시가 늦어졌습니다.

귀하에게 전달된 후 인식할 수 없을 정도로 변경된 관련 없는 코드를 다시 검토하는 것은 어리석은 일입니다.

시간관계상 급하게 모션을 진행했습니다.

검토 가능한 코드 작성

제어할 수 없는 코드 백로그 문제에 책임이 있는 사람은 리뷰어뿐만이 아닙니다. 예를 들어, 동료가 대규모 프로그램에 지저분한 코드를 추가하는 데 일주일을 소비했다면 릴리스된 패치는 검토하기 어려워지고 이해하고 조사해야 할 콘텐츠가 너무 많아지게 됩니다. 코드의 목적과 기본 구조조차 불분명합니다. 이것은 코드 작성이 하는 일이 아닙니다.

검토 가능한 코드를 작성하기 전에 몇 가지 준비를 해야 합니다. 어려운 아키텍처 결정을 내려야 하는 경우 먼저 검토자와 논의하는 것이 가장 좋습니다. 이렇게 하면 코드를 더 쉽게 검토하고 이해할 수 있습니다. 왜냐하면 그들은 여러분이 달성하려는 목표와 달성 방법을 미리 알고 있기 때문입니다. 또한 나중에 검토자가 완전히 다르고 더 나은 접근 방식을 제시하는 경우 코드의 상당 부분을 다시 작성하지 않아도 됩니다.

프로젝트 아키텍처는 디자인 문서에 자세히 설명되어야 합니다. 이는 새로운 프로젝트 직원이 기존 코드 베이스를 더 빨리 이해할 수 있게 하고 검토자가 업무를 더 잘 수행하는 데 도움이 되기 때문에 중요합니다. 또한 단위 테스트를 통해 검토자는 개별 구성 요소의 사용법을 더 잘 이해할 수 있습니다.

패치에 타사 코드도 포함된 경우 별도로 제출하세요. 코드 중간에 jQuery 9,000줄을 삽입한다면 검토 난이도가 크게 높아질까요?

검토 가능한 코드를 만드는 가장 중요한 단계 중 하나는 코드 검토에 주석을 다는 것입니다. 이를 위해서는 직접 사전 검토한 다음 검토자가 이해하는 데 도움이 될 것이라고 생각되는 곳에 의견을 추가해야 합니다. 주석 후 코드 검토에는 상대적으로 시간이 거의 걸리지 않습니다(보통 몇 분). 물론 적절한 경우 코드 주석을 계속 사용해야 합니다. 또한, 연구에 따르면 개발자 자신이 코드에 주석을 달 때 기존 결함을 많이 발견하게 되는 것으로 나타났습니다.

코드 리팩토링

때로는 코드 베이스를 리팩터링해야 할 때도 있습니다. 대규모 애플리케이션이 발생하는 경우 며칠(또는 그 이상)이 걸리고 많은 수의 패치가 생성될 수 있습니다. 이 경우 코드 검토를 위한 표준 프로세스를 구현하는 것이 비현실적일 수 있습니다.

가장 좋은 해결책은 코드를 점진적으로 리팩터링하는 것입니다. 먼저 합리적인 범위를 지정하고 해당 코드 베이스를 결정한 다음 목표 방향으로 수정 및 재구성합니다. 첫 번째 부분이 완료되면 검토하고 게시한 다음 두 번째 부분을 리팩터링하여 모두 완료될 때까지 진행하세요. 이러한 단계적 접근 방식이 항상 가능한 것은 아니지만, 생각하고 계획할 때 이 접근 방식을 사용하면 리팩토링 시 대규모 모놀리식 패치를 피할 수 있습니다. 물론 이 접근 방식에는 리팩토링 시간이 더 많이 필요할 수 있지만 더 높은 품질의 코드가 생성되고 검토 프로세스가 더 쉬워집니다.

코드의 증분 리팩토링이 여전히 가능하지 않다면 또 다른 해결책은 페어 프로그래밍입니다.

분쟁 해결

팀원 모두가 재능이 있다는 것은 의심의 여지가 없지만 특정 코딩 문제에 직면할 때 이는 쉽게 의견 차이로 이어질 수도 있습니다. 개발자로서 우리는 열린 마음을 갖고 리뷰어의 다양한 의견을 기꺼이 수용해야 합니다.

리뷰어로서 재치 있게 말해야 합니다. 제안을 하기 전에 자신의 의견이 정말 더 나은지 아니면 단지 취향이 다른 것인지 생각해 보세요. 실제로 개선이 필요한 코드 영역을 선택하면 전체 설득 프로세스가 훨씬 간단해집니다. 그리고 "눈을 감고 작성한 알고리즘이 당신의 것보다 더 효율적일 수 있다"보다는 "여기서 고려해 볼 가치가 있다...", "누군가가 제안한..."과 같은 말을 해야 합니다.