GN⁺: Unified vs. Split Diff

• 코드 리뷰에서 unified diff와 split diff 사용의 장단점 설명
• unified diff와 split diff는 간단하고 작은 변화에 적합
• 크고 복잡한 변화에 대해서는 unified diff나 split diff가 이상적이지 않음
• 저자는 특정 시점의 전체 코드베이스를 검토하는 것을 선호하며, 최근에 변경된 영역에 초점을 맞추되 일반적인 검토도 수행
• 이상적인 diff 뷰는 코드의 현재 상태를 왼쪽에 표시하고, 미묘하게 강조된 변화와 함께 현재 보이는 코드베이스의 unified diff를 오른쪽에 보여줄 것이라고 저자는 제안
• 이 검토 형식은 실제 코드보다는 diff를 검토하는 데 초점을 맞춘 기존 도구에서 잘 지원되지 않는다고 지적함
• 저자는 이 검토 스타일에 대해 로우테크 워크플로우를 사용하며, 로컬에서 pull request를 확인하는 스크립트를 사용. 이 스크립트는 pull request의 모든 커밋을 지우지만 모든 변경 사항은 유지
• 저자의 워크플로우는 변경된 파일을 쉽게 탐색하고 검토된 hunks를 표시할 수 있지만, 상태 버퍼와 편집기에서 현재 열린 파일 사이의 자동 동기화는 부족
• 저자는 이런 방식으로 코드를 검토하기 쉽게 해주는 도구를 원하며, 맞춤형 ad-hoc 도구를 만들 필요 없이 이를 가능하게 해주는 도구를 원함
• 저자는 또한 글이 코드 검토 방법에 대해 논의하고 있지만, 코드 검토의 주요 목표는 반드시 코드를 검토하는 것이 아니라는 점을 지적하며, 이 주제에 대한 관련 게시물을 링크로 소개

[neo]

Hacker News 의견

• 본 기사는 코드 리뷰에서 통합 diff와 분할 diff의 차이점에 대해 논의합니다.
• 일부 댓글 작성자들은 리뷰 유형이 팀과 티켓에 따라 달라지며, 일부는 두 번째 눈으로의 정신 검사를 선호하고, 다른 일부는 깊고, 구조적인 기능 사전 병합 리뷰를 선호한다고 주장합니다.
• difftastic이라는 도구가 언급되며, 이 도구는 더 세밀한 diff 강조를 위해 구조적 diffing을 사용합니다.
• 일부 댓글 작성자들은 PR을 열어 리뷰하는 변화를 검토하기 위해 vim을 사용하는 스크립팅을 사용합니다.
• 대규모이고 복잡한 코드베이스에서 코드 리뷰의 어려움이 강조되며, 문제는 도구보다는 문화와 지식 공유에 더 관련이 있습니다.
• GitHub의 기능 중 하나인 브라우저 내에서 전체 IDE로 들어가는 .을 누르는 것이 전체 파일의 맥락에서 변화를 보는 데 유용하다고 언급됩니다.
• 일부 댓글 작성자들은 분할 diff에서 불필요한 맥락을 제거하는 저자의 선호도에 의문을 제기하고, 다른 일부는 p4merge와 같은 다른 도구의 기능을 그리워합니다.
• GitHub의 VSCode를 브라우저에서 diff 뷰를 보기 위해 사용하는 것이 전체 파일과 더 읽기 쉬운 복잡한 diffs를 보는 데 제안됩니다.
• Meld는 이러한 사용 사례에 잘 작동하는 도구로 제안됩니다.