더 많은 코드 리뷰 = 더 냄새나는 코드? 노트

더 많은 코드 리뷰 = 더 냄새나는 코드?

68개의 리뷰 코멘트로 인해 함수가 28줄에서 42줄로 늘어났고, 실제 문제를 해결하는 62개의 수정이 이루어졌습니다. 문제는 리뷰어의 정확성이 아니라 코멘트에 대한 의사 결정 루틴이 프로젝트에 부족했다는 점이었습니다. AI 에이전트 시스템인 AgentCoop 프로젝트는 OpenAI의 Codex를 사용하여 자동 코드 리뷰를 수행했으며, 모든 코멘트를 처리해야 한다는 엄격한 규칙을 따랐습니다. 이로 인해 종종 더 넓은 영향을 고려하지 않고 코멘트를 수정하게 되었습니다.네 가지 주요 문제가 발생했습니다. 작고 정확한 수정으로 인한 범위 증가; 실제 영향과 관계없이 "보안" 또는 "가용성" 태그의 긴급 처리; 드물거나 존재하지 않는 문제에 대해 영구적인 코드 복잡성을 추가하는 잘못된 절충; 그리고 근본 원인이 아닌 코멘트가 가리키는 곳을 수정하는 것. 설정 파일을 손상시키는 업그레이드에 관한 "치명적인" 문제는 처음에 확대되었지만 나중에 문서의 한 단락으로 해결되었습니다. 실제 사용자 영향은 시스템 전체의 중단보다는 몇 분간의 구성 조정에 불과했습니다.팀은 이후 직감 이상으로 리뷰 코멘트를 평가하는 루틴을 개발했습니다. 첫째, 세 가지 빠른 질문을 통해 수정이 저렴한지(10줄 미만), 문제가 실제로 발생할 수 있는지, 그리고 조용히 실패하는지(최소한 로깅 필요)를 결정합니다. 저렴한 수정은 즉시 구현되고, 도달할 수 없는 코드 경로는 삭제되며, 조용히 실패하는 것은 우선순위가 지정되거나 명확하게 만들어집니다. "저렴한"에 대한 중요한 주의사항은 리뷰어의 제안이 아니라 가장 저렴하고 효과적인 수정을 고려하는 것입니다.첫 번째 단계를 통과한 코멘트에 대해서는 몇 시간 내에 정량적 평가가 수행됩니다. 여기에는 사고당 버그 비용, 연간 발생 빈도, 사용자가 수용할 수 있는 고통(승수 사용), 수정의 빌드 시간, 영구적인 연간 유지보수 비용을 추정하는 것이 포함됩니다. 이러한 값은 연간 절감액과 수정의 회수 기간을 계산하는 데 사용됩니다. 순 연간 절감액이 0 또는 음수이면 수정은 가치가 없는 것으로 간주됩니다.처음 예시로 든 설정 구문 분석 문제는 분석 시 순 절감액이 음수로 나와 수정해서는 안 되는 것으로 입증되었습니다. 사고 빈도를 추정하려면 추측이 아닌 특정하고 증거가 있는 부분에서 숫자를 구축해야 합니다. 경쟁 조건도 마찬가지로 트리거링 동작과 취약한 창을 고려하여 평가되며, 순수한 우연보다는 의도적으로 정렬된 시나리오를 우선시합니다.