AIなしでのコーディング：革新的な新しい働き方

多くのチームがコードレビューを先延ばしにしたり、形だけ行ったり、各PRで終わりのないやり取りに陥ったりしています。その理由について考えてみましょう。

神話1 よくある誤解：コードレビューが難しいのは退屈でPRが長すぎるからだ。現実：コードレビューが難しいのは、プログラミングの認知作業を中間ステップなしで複製するからである。エンジニアはコードレビューを嫌う傾向があるが、それを仕事の不快な一部として受け入れるのではなく、なぜなのかを問うべきだ。

PRの長さが問題ではない。一部のチームは小規模なPRの規範を確立することでレビュー時間の短縮と精神的疲労の軽減を実現しているが、それは単にPRが短いからではなく、著者がより多くの整理とドキュメント化を行うからである。例えば、理想的には1000行の変更が必要な場合、200行以下のPRに分割するには、少なくとも5つのPRが必要で、それぞれが独立した単位として意味を持つようにするために、多くの「ストーリーテリング」が必要になる。小規模なPRは、著者が段階的に説明することを強制するため、レビューが容易になる。その説明がないと、レビュアーはPRに込められたすべての推論とコンテキストを再構築しようとし、それはコードを書くよりも多くの精神的エネルギーを消費する。

ギャップを埋める方法はいくつかある：大きなPRを小さく分割する（フィーチャーブランチを対象とする）、解決する問題とその解決方法を事前に文書化する、PRにコメントを残して考えを説明する、ペアプログラミングやモブプログラミングを利用する、対話的リベースを使用する。これらによりコードレビューは容易になる。

神話2 よくある誤解：コードレビューの主な目的は悪いコードがアプリケーションに入るのを防ぐことだ。現実：コードレビューの主な目的はチームの調整である。間違いを発見することも重要だが、最も価値があるのは調整である。コードレビューはチームが変更内容と理由を理解し、そのコードを保守する責任を負うことを確認する仕組みだ。同意ではなく調整が重要である。副次的な目的は指導である。レビュアーは技術を教え、知識を深めることができる。

この考え方はコードレビューを簡素化する。レビュアーの最も重要な仕事は「何を」「なぜ」を理解することであり、それは高レベルで行える。次に指導、最後にエラー発見である。エラー発見は最も困難だが最も重要でない仕事であり、他の人々やツールと共有される。

神話3 よくある誤解：コードレビューはソフトウェア品質の最終的なゲートキーパーである。現実：コードレビューは形式的なものとして機能するときに最も効果的であり、単独ではコードベースを保護するのに不十分である。PRは驚きであるべきではない。チームは変更が来ることを事前に知っているべきだ。それでも、コード作成者とレビュアーの間には知識のギャップが存在し、信頼がそのギャップを埋める。しかし、信頼だけに頼るのではなく、複数のセーフガード（人間と自動化）が必要である。コード作成者が誠実でなければ、どんなレビュアーも品質の低下を防げない。

神話4 よくある誤解：コードレビューを正しく行えば多くの問題を解決できる。現実：コードレビューはあらゆる意味のある成果に対して補足的であり、単独で問題を解決するほど強力ではない。コードレビューが禁止された場合、チームはペアプログラミング、計画的な変更、技術的負債への対処、QAやプロダクトとの協力強化、ドキュメント化、トレーニング、自動テストと静的解析の強化などを行うだろう。これらはコードレビューよりも効果的である。コードレビューは多用途だが非効率的でもあり、より効果的な方法を見つけるのがテクニカルリーダーの仕事である。

結論として、コードレビューは皆が役割を果たせば疲れるものではない：作成者は十分なコンテキストを提供し、レビュアーは優先順位を理解し、チームは効果的なセーフガードに投資する。プロセスが改善されるにつれ、コードレビューはより速く、より簡単になる。