코드 리뷰를 전부 해야 할까?
Maybe We Shouldn't Be Reviewing All This Code
AI가 생성하는 코드가 인간의 검토 속도를 크게 초과하면서, 코드 리뷰의 역할에 대한 논쟁이 뜨겁다. Thoughtworks의 Rachel Laycock은 코드 리뷰가 버그 발견 이상의 가치(지식 공유, 멘토링, 공동 소유권 등)를 제공한다는 주장에 동의하면서도, 이를 리뷰 시점까지 미루는 것이 잘못이라고 지적한다. 그녀는 페어 프로그래밍, 트렁크 기반 개발, 디자인 세션 등 피드백을 더 일찍 제공하는 방법을 제안하고, 모든 변경 사항을 검토하는 대신 예외적인 경우에만 인간 리뷰를 적용하는 '예외적 리뷰'를 옹호한다. 이는 AI 시대에 엔지니어가 diff(변경 사항)가 아닌 시스템을 이해하는 데 집중해야 함을 시사한다.
우리는 엔지니어가 diff가 아닌 시스템을 이해하도록 해야 한다.
HN 토론
77- Arainach
이 방식은 확장성이 없어요.
가끔 하는 페어 프로그래밍은 엄청나게 가치 있을 수 있습니다. 저는 누구든 만나서 그들의 코드에 대해 직접 이야기하고, 설계를 브레인스토밍하고, 함께 디버거로 조사하는 것을 환영합니다.
하지만 하루 8시간 중 대부분을 그렇게 하라고 하면——일반적으로 대부분의 시간은 말할 것도 없고——서류 작성하는 것보다 더 빨리 그만둘 겁니다. 누군가가 항상 어깨 너머로 지켜보는 것은 스트레스와 과잉 자극의 세계라서, 저(그리고 다른 많은 사람들도)는 견딜 수 없을 것입니다.
- deterministic
저는 코드 리뷰가 많은 가치를 더한다고 확신하지 않습니다. 동료들 대부분이 능력이 떨어지고 전반적인 품질을 개선하려는 경우가 아니라면요.
그렇긴 하지만, 저는 코드를 작성하기 전에 경험 많은 개발자들과 이야기하는 것에서 많은 가치를 얻습니다.
- wgreenberg
저는 동료 검토에 대한 논박 글이 AI 생성 헤더 이미지를 사용하면서 쉽게 식별 가능한 문제(노트북 내용이 거꾸로 되어 있고, 한 아이는 가위로 손을 베려고 하며, 다른 아이는 기하학적으로 불가능한 "레고" 구조물을 만들고 있음)를 가지고 있는 것이 정말 웃깁니다. 출판 전에 다른 사람이 검토했다면 좋았을 텐데요!
- singpolyma3
> 대안적인 해결책을 탐구하고 싶다면, 그 중 하나를 구현하기 전에 그렇게 하는 것이 좋겠습니다.
귀엽게 들리네요. 하지만 그 중 적어도 하나를 구축하기 전에는 그것들이 실제로 무엇인지 알 수 없습니다. 몇 년 동안 명세를 작성하고 회의를 할 수 있지만, 구축의 첫 시간에 발견될 근본적인 무언가를 여전히 놓칠 것입니다.
- ramshanker
이 시점에서 저는 오픈 소스 프로젝트의 코드베이스 중 약 30%도 읽지 않았습니다. 저는 수동 테스트를 통해 우리의 작업을 알고 있습니다. AI는 제가 명시적으로 요청하지 않아도 계속해서 자신을 위한 테스트를 작성하고 있으며, 저는 불평하지 않습니다.