The software code review process is a systematic, peer-driven quality assurance procedure that scrutinizes code when a developer submits a pull or merge request. 

コードレビューの手順が不十分だと、避けられない遅延や些細なことでボトルネックが生じる可能性があると非難される一方で、適切なコードレビューはバグを早期に発見し、メンター関係を育み、責任を共有する民主的な方法と見なされている。

それがすべてだと思っていたが、そうではない。

シニアソフトウェアエンジニアのMark Dominus氏はThe New Stackに対し、多くの企業が明らかにコードレビューを実施しているものの、「レビューの結果として何を目指すべきか」を明確にしていないと指摘し、それが問題だと述べた。

「ジュニアエンジニアが初めてコードレビューをするよう言われたとしましょう。成果物は何でしょうか。私が働いた多くの場所では、成果物は明示されていませんでした」とDominus氏は言う。 

この件に関するMastodonの投稿で、Dominus氏は「コードレビューでバグを見つけることに依存している人は、愚者の楽園に生きている」と書き、主な理由は「一般的にコードを調べるだけでバグを見つけることは不可能」だからだと述べた。彼はコメントを強調し、「コードレビューの主な目的」は将来メンテナンスしにくくなるコードを見つけることだと述べた。

コードレビューで悪い結果を招く確実な道

ソフトウェアエンジニアが変更セットをのんびり歩き回り、気に入らない点を指摘することを期待されるシナリオでは、悪い結果につながるとDominus氏は指摘する。つまり、人々が物事の進め方に関する自分の好みを押しつけようとし、一般的に議論が起こるようになる。

“Finding bugs, just from examining a change set, is extremely difficult and requires a certain amount of luck.” – Mark Dominus. 

「上司がジュニアエンジニアに少し詳しく指示する場合もあります。例えば『バグがないか探してみて』と。これはジュニアを不快な立場に置くことになります」とDominus氏は説明する。「バグが見つかれば素晴らしい。でも見つからなかったらどうでしょう。変更セットを調べるだけでバグを見つけることは非常に難しく、ある程度の運が必要です。」

彼は別のアプローチを提案する。ソフトウェアチームのプロジェクトリーダーがコードレビュープロセスを主導し、「2時間かけて見て、理解できないことがあればメモに残し、すべてを終えられなければどこで止まったかをメモに残して」と言う方法だ。

本当のソフトウェアエンジニアリングの価値を提供する道

「レビュアーがすべてを見る時間がない場合、貴重なことを学べます。変更が大きすぎるか、複雑すぎて2時間で理解できないということです。おそらく変更セットを2つ以上の小さな提出物に分割し、それぞれを別々にレビューすべきでしょう。レビュアーがどれだけジュニアで経験が少なくても、二日酔いであっても、求められたものを提供でき、それが本当のエンジニアリングの価値を持つことになります」とDominus氏は説明する。 

その本当のエンジニアリングの価値は、この場合、肯定的なネガティブだ。チームは他のチームメンバーが理解できないコード、または現在のコードレビュープロセスにとって変更セットが扱いにくすぎることを特定できた… またはその両方だ。

コードレビューは劇場。近々あなたのお近くで上演

これらの見解に広く同意する、高負荷のeコマースプラットフォーム企業でQAエンジニアを務めるMikhail Golikov氏はThe New Stackに対し、チームがバグを検出するためにコードレビューに依存している場合、「コードレビューは劇場」だと述べた。

“When a team treats review as its bug filter, it ships with a warm feeling and no evidence, then finds out in production,” – Mikhail Golikov. 

「人間がdiffをざっと読むだけでは、競合状態や負荷がかかったときにマイナスになる割引を見抜くことはできません。レビューは後でメンテナンスしたくなるコードのためのものであり、テストは今壊れているコードのためのものです」とGolikov氏は強調する。「レビュアーはきれいなdiffを読み、理にかなった名前と整然とした関数を見て、承認をクリックします。それでは、アプリの重要な部分が誤動作し、ユーザーに壊れたサービスを提供しているかどうかはわかりません。」

オープンソースのPythonテストツールのメンテナーでもあるGolikov氏は、これらのエラーを引き起こす種類のバグは、開発者が読めるコードの中には存在しないと説明する。代わりに、それらはコードがランタイムで到達する状態の中に存在する。 

証拠もなく心地よい感覚で出荷してはいけない

「チームがレビューをバグフィルターとして扱う場合、証拠もなく心地よい感覚で出荷し、その後本番環境で問題を発見することになります」とGolikov氏は確認する。「レビューは『6ヶ月後にこれをメンテナンスしたくなるか』という質問のためのものであり、『実際の入力に対してテストを実行したときに正しく動作するか』という質問のためのものです。午後5時に人間がプルリクエストをざっと読むためのものではありません。」

AIの時代にagenticコーディングツールの存在感が増す中、コードレビュープロセスを変える必要があることについては、開発者とベンダーの双方にほとんど異論がない。

Judah Taub氏（Hetz Venturesのマネージングパートナー）はこの主張に同意し、エンジニアリングチームが何年もコードレビューをバグに対する最後の防衛線として扱ってきたが、それは実際には彼らの強みではなかったとThe New Stackに語った。

“The role of the engineer continues to move further away from the actual code and toward validating architecture, intent and business logic. In the future, even that may be automated,” Judah Taub.

「コードレビューはスタイル、アーキテクチャ、可読性、メンテナンス性を捉えます」とTaub氏は言う。「テストはバグを捉えます。本番環境はそれ以外のすべてを捉えます。最高のエンジニアリング組織は、何百行ものコードに埋もれた微妙なエッジケースを別の開発者が発見することに頼りません。彼らはプルリクエストが人間に届くずっと前に、正しさを自動的に検証するシステムを構築します。コードレビューは、次のエンジニアがコードをシームレスに作業できるようにするためのものです。」

コードレビューの未来

AI生成コードが今や戦いに加わる中、Taub氏は避けられない新しい均衡は、人間がコードを直接レビューするのを減らし、ますますAIによるコードレビューのレビューを行うようになるだろうと考えている。 

「エンジニアの役割は実際のコードからますます離れ、アーキテクチャ、意図、ビジネスロジックの検証に向かっています。将来的には、それさえも自動化されるかもしれません」と彼は予測する。

ここから主要なトレンドを抽出できるとすれば、ソフトウェアエンジニアリングチームは、現在90年代に留まっているのであれば、確実にそこから脱却する必要があるということだ。 

クラウドネイティブ、プラットフォームエンジニアリング、そしてvibe codingからagentic codingへの流れ（必要に応じてビッグデータ、DevOps、エンタープライズオープンソースへの標準化を追加できる）の複合的な革命により、ソフトウェア開発者の働き方が変わったので、当然ながら、何が起きたかをレビューする方法にも相応の変化があるべきだ。

YOUTUBE.COM/THENEWSTACK

Tech moves fast, don't miss an episode. Subscribe to our YouTube channel to stream all our podcasts, interviews, demos, and more.

Group Created with Sketch.