[WebDev] How not to do code reviews

 

How not to do code reviews - Aviator Blog

---

How not to do code reviews

전통적으로, 코드 리뷰는 엔지니어가 동료의 코드를 오류를 찾고 가독성, 효율성, 유지보수성을 보장하기 위해 면밀히 검토하는 것을 포함했다.

 

이 방식은 특히 대규모 팀에서 병목 현상을 유발했다. 왜냐하면 적합한 리뷰어들이 필요할 때마다 변경을 검토할 여유가 항상 있는 것은 아니기 때문이다. CODEOWNERS 같은 것들이 이 이슈를 해결하려고 하지만, 그것들은 지식 사일로를 생성하고 도메인 전문가들에게 부담을 주는 결과를 초래할 수 있다.

 

이 모든 것들은 좌절을 불러일으키고 진전을 방해한다. 이 결과는 팀의 릴리즈 타임라인과 팀의 사기에 영향을 미친다.

 

좋은 소식은 1970년대처럼 버그를 식별하기 위해 코드 리뷰에 의존할 필요가 없다는 것이다. 요즘에는 자동화된 테스팅과 정적 코드 분석기를 사용하여 버그를 찾는 것이 더 나은 선택이다. 현대의 코드 리뷰는 에러를 찾는 것을 넘어서 장기적으로 건강한 코드 베이스를 유지할 수 있는 팀으로 성장하는데에 초점을 맞출 수 있다.

 

The Traditional Approach: Error-Driven Code Reviews

코드 리뷰는 1976년에 발표된 Michael Fagan의 논문 "Design and Code Inspections to Reduce Errors in Program Development"에서 처음 묘사되었다.

 

그는 형식적인 검토 과정에 중점을 두었는데, 이는 정상적으로 작동하지 않거나 부정확한 결과를 생성해내는 런타임 동장에 영향을 미치는 기능적인 문제를 중심으로 error-driven 검토를 강조했다. 그의 프로세스는 잠재적인 오류를 찾는데에 집중되어있다. 이것은 개발자들이 미리 정의된 입력을 코드 상에서 수동으로 실행하고 미리 정의된 출력이 올바르게 출력되는지를 검증하는 것을 포함한다. 만약 코드가 올바르지 못한 출력을 생성하면, 재잭업이 필요했으며 동일한 방식으로 다시 테스트를 진행했어야 했다.

 

오류 중심적 접근 방식은 코드의 유지보수성, 가독성 및 미래의 변경사항에 영향을 끼치는 성장 가능성 문제들을 무시하는 경향이 있다. 이러한 결함들은 장기적으로 코드의 민첩성을 방해하고 개발 비용을 증가시키는 기술 부채를 야기한다.

 

오류 중심적 접근은 또 다른 과제를 불러온다. 코드베이스와 기술에 익숙한 경험이 풍부한 엔지니어들에게 너무 의존하게 되기 때문에 누가 코드 리뷰를 해야하는지를 결정하는 것은 매우 큰 문제가 된다. 문제를 감지할 충분한 경험을 가진 엔지니어가 제한되어있기 때문에, 이는 코드 리뷰에 지연을 가져오며 개발 프로세스를 느리게 만든다.

 

가장 중요한 것은 이 접근법이 팀의 가장 경험이 많은 구성원을 계속해서 리뷰와 디버깅의 끝없는 사이클에 가두고 있다는 것이다. 이는 코드

소유자들 사이에 지식 사일로를 만들고 지식 공유를 방해하여 나머지 팀원들이 코드베이스에 대한 지식을 확장하는 것을 막고있다.

 

The Modern Approach: Code Reviews as Knowledge Sharing

지난 20년동안, 정적 분석기 및 자동화된 테스트같은 개발 도구들은 기능적인 에러들을 찾는데에 많은 발전을 해왔다. 이러한 툴들은 개발자가 지식 공유, 코드 구조 그리고 장기적인 코드 유지보수와 같은 고수준의 관심사에 집중할 수 있게 한다.

The Role of Automated Tests

자동화된 단위 혹은 통합 테스트는 논리적인 버그를 찾는데에 사람보다 더 우수하다.

 

자동화된 테스트는 코드를 즉시 실행하고 다양한 입력이 올바른 출력을 생성하는지 바로 확인할 수 있으며, 일관되게 문제를 식별할 수 있다.

하지만, 효과적인 자동화 테스트에는 적절한 테스트를 작성하기 위한 규칙이 필요하다. 잘못된 입력을 식별하고 코드가 어떻게 응답해야하는지 결정해야하며, 다양한 테스트 케이스를 확인하기 위해 자동화된 테스트를 작성해야한다. 리뷰어들은 또한 기존 테스트로 커버되지 않는 엣지 케이스를 찾기 위해 코드의 변경과 자동화된 테스트들을 분석해야한다.

 

하지만 모든 새로운 코드에 대해 자동화된 테스트를 작성해야하는 이 시간들을 포함한 개발 시간은 리뷰 프로세스에서 만회된다. 리뷰어들은 버그를 찾기위해 각각의 입력에 대해 수동으로 테스트하는 것 대신 자동화된 테스트에만 의지하면 되기 때문이다.

The Role of Static Analyzers

자동화된 테스트는 코드의 논리적 문제를 감지할 수 있지만, 코드의 취약점을 감지할 수는 없다. 자동화된 테스트는 소프트웨어가 실행되는 방식에 초점을 두고 있으며, 실행에 사용되는 것에 대해서는 주목하고 있지 않다. 정적 코드 분석기는 이 문제를 해결한다.

 

정적 코드 분석기는 잠재적인 보안 이슈를 위해 코드와 종속성을 분석한다. 만약 취약점을 찾는다면, 코드 작성자에게 이것을 고치도록 알림을 주어 해당 코드를 수정하거나 종속성을 업데이트 하도록 한다.

 

정적 코드 분석기는 스타일 가이드를 강제할 수도 있다. 사용자의 스타일 가이드를 사용하도록 구성된 정적 분석기는 변경된 코드를 검토하고 잘못된 명명이나 공백 문제와 같은 해당 가이드라인을 위반하는 행을 식별할 수 있다.

 

현대의 AI 기반 정적 코드 분석기는 더 많은 문제를 식별할 수 있다. 이는 코드 베이스를 학습하여 코드의 구조를 이해할 수 있다. 새로운 변경사항이 생기면, 코드가 코드 아키텍처와 일치하는지 확인할 수 있다. 또한 코드가 요구사항을 완전히 충족시키는지 확인하고 만약 그렇지 않다면 작성자에게 이를 알린다. AI 기반의 코드 분석기는 큰 그림을 이해하는데에 뛰어나기 때문에 이전에 오직 ‘사람’들만이 캐치할 수 있었던 유지 보수성과 코드 아키텍처 문제를 탐지할 수 있다.

 

자동화된 테스트 처럼 정적 분석기를 사용한다는 것은 사람 리뷰어가 더이상 필요하지 않다는 것을 의미하지는 않는다. 리뷰어는 여전히 그들의 결과를 검토해야하지만, 훨씬 더 적은 시간이 소요된다.

Code Review for Knowledge Sharing

코드 리뷰는 ‘장기적으로 건강한 코드 베이스를 구축하고 더 견고하고 적응력있는 팀을 형성하는 것’이라는 새로운 목표를 가지게 되었다.

이제 코드 리뷰는 협업과 지속적인 학습을 촉진하기 위해 진행되어야 한다. 이 피드백과 토론은 더이상 현재의 코드를 개선하는데에 사용되는 것이 아니라 더 건강한 코드 베이스를 구축할 수 있는 팀으로 성장하는데에 사용된다.

 

코드 리뷰는 문제를 토론하여 경험이 적은 엔지니어들에게 고수준 프로그래밍 개념을 노출시키고 큰 그림을 이해하도록 돕는 것이다. 따라서 경험 수준에 관계없이 모든 엔지니어가 리뷰 프로세스에 기여하고 이로부터 이익을 얻을 수 있도록 하는 것이 목표이다.

 

여전히 문제와 개념을 철저히 논의하고 설명하는 것이 중요하다. 리뷰 프로세스에 참여하지 않은 다른 엔지니어들도 나중에 이런 토론을 읽어서 특정 변경 사항이 왜 이루어졌는지와 그것이 전체적인 그림 속에서 어떻게 맞는지를 이해할 수 있다.

---

👩‍💻 Opinion

최근 Github Copilot을 사용하면서 드는 생각이었다.

더 이상 오류를 찾고 좀 더 효율적인 코드를 제안하는 코드 리뷰는 의미가 없어졌다고 생각한다. 어쩌면 이미 AI에게 검증받은 더 좋은 코드를 작성했을 것이다.

그렇다면 Knowledge Sharing을 위해 코드 리뷰를 해야한다는 것에 많은 공감을 한다. 코드 리뷰가 ‘버스 지수’를 높이는 일이 되어야 한다. 동료들과 나와의 지식 수준을 계속해서 맞춰 나가기 위한 최고의 방법이자 수단이다.