코드 리뷰, 어떻게 하면 더 효율적으로 할 수 있을까?

기존 웹 기반 PR 리뷰 인터페이스(Interface)는 반복적인 수정 사항에 대한 리뷰를 어렵게 만든다는 지적이 제기되었다. 특히, force push를 사용하면 이전 버전의 변경 사항을 다시 검토해야 하는 비효율성이 발생한다. 이러한 문제점을 해결하기 위해, 작성자는 git log -p --reverse 명령어를 사용하여 변경 사항을 확인하고, git range-diff를 통해 두 버전 간의 차이점을 비교하는 방법을 제시했다. 또한, 리뷰 과정에서 주석을 추가하기 위해 vim을 활용하는 방법을 소개했다.

작성자는 force push 이후의 리뷰 과정을 개선하기 위해, git checkout -b v1 origin/feature를 통해 원격 브랜치(Remote Branch)에서 브랜치를 생성하고, git fetch 및 git checkout -b v2 origin/feature를 사용하여 수정된 버전을 확인하는 방법을 제안했다. 이를 통해, 기존의 전통적인 워크플로우(Workflow)와 유사하게 v1과 v2 버전을 비교할 수 있다. 또한, spr와 같은 도구를 사용하여 amend 및 rebase를 로컬에서 수행하고, 이를 새로운 커밋(Commit)으로 변환하여 원격 저장소에 병합하는 방법을 제시했다.

Gerrit, GitLab, Review Board 등 다양한 코드 리뷰 도구의 장단점이 논의되었다. Gerrit은 각 push를 'patchset'으로 추적하여 diff of diffs를 효율적으로 비교할 수 있는 기능을 제공한다. GitLab은 push된 버전을 추적하고 임의의 diff를 지원하지만, rebase 시 리뷰어(Reviewer)에게 불필요한 변경 사항을 보여줄 수 있다는 단점이 있다. Review Board는 interdiff 필터링 알고리즘을 사용하여 업스트림(Upstream) 변경 사항을 제거하고, 작성자의 변경 사항만 표시하는 기능을 제공한다.

커뮤니티에서는 top-posting 방식의 이메일 커뮤니케이션(Email Communication)에 대한 비판이 제기되었다. 특히, 긴 이메일 체인(Email Chain)에서 내용을 파악하기 어렵고, HTML 이메일의 표준화 부재로 인해 가독성이 떨어진다는 지적이 있었다. 이에 대한 대안으로, Slack과 같은 실시간 커뮤니케이션 도구 또는 Lobste.rs와 같은 포럼(Forum)을 활용하는 방안이 제시되었다. 또한, atomic commit과 bisectable commit을 통해 코드 리뷰의 효율성을 높이는 방법도 언급되었다.