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 ツールを作る必要なくそれを可能にするツールを望んでいる
• また著者は、この記事がコードレビューの方法について論じている一方で、コードレビューの主な目標は必ずしもコードそのものをレビューすることではないとも指摘し、このテーマに関する関連投稿をリンクで紹介している

[GN⁺]

Hacker Newsの意見

• この記事では、コードレビューにおける unified diff と split diff の違いについて議論しています。
• 一部のコメント投稿者は、レビューの種類はチームやチケットによって異なり、第二の目としての軽いチェックを好む人もいれば、マージ前の深い構造的な機能レビューを好む人もいると主張しています。
• difftastic というツールが言及されており、このツールはより細かな diff の強調のために構造的 diffing を使用します。
• 一部のコメント投稿者は、PR を開いてレビュー対象の変更を確認するために、vim を使ったスクリプトを使用しています。
• 大規模で複雑なコードベースにおけるコードレビューの難しさが強調されており、問題はツールよりも文化や知識共有に深く関係しています。
• GitHub の機能の1つとして、ブラウザ内で完全な IDE に入るために . を押すことが、ファイル全体の文脈の中で変更を見るのに有用だと言及されています。
• 一部のコメント投稿者は、split diff で不要な文脈を取り除くという著者の好みに疑問を呈しており、他の人たちは p4merge のような別のツールの機能を懐かしんでいます。
• ブラウザ上の GitHub の VSCode を使って diff ビューを見ることで、ファイル全体や、より読みやすい複雑な diff を確認できると提案されています。
• Meld は、このようなユースケースにうまく機能するツールとして提案されています.