確かに、MRで一番気になるのは「この変更が、私たちを uglier（見た目が悪く）、buggier（バグが多く）、maintainable（メンテナンスしづらい）な道に導くのか」ということだよね。人は一般的に既存のパターンを真似るから、例えば誰かが新しい内部日付時刻フォーマットを追加すると、すぐにコードベースが分岐して、一貫性のないバージョンがいくつも出回ることになる。その他の問題（小さなバグや冗長なコード）は簡単に修正できるけど、パラダイムの腐敗はそうはいかない。

私の考えでは、コードレビューは著者の所有からチームやプロジェクトの所有に移るゲートだと思ってる。私がレビューしているコードはあなたのコードじゃなくて、私たちのコードになる直前のコードなんだ。もちろん、メンテナンス性はその大きな要素だよ。

確かに、メンテナンス性を確保するのはコードレビューの利点の一つだけど、それが唯一の目的だと言うのは大胆な主張だと思う。例えば、コードレビューはチームがコードの変更を把握し、コードベース全体の責任を共有するためのツールでもあるからね。

これだとレビューアや著者が怠けるだけだよ。コードレビューの目的は多面的なんだから。維持が難しい？そうだね。バグがあるかも？うん。もっとシンプルに/クリーンにできる？そうだね。プロジェクトのコードスタイルに合ってる？うん。誰かにコードを理解してもらう？そうだね。ジュニアメンバーを onboard する？そうだね。デザイン決定の健全性をチェックする？そうだね。この軽いノートは、怠け者のコードレビューアの自己正当化に過ぎない。

コードレビューで最も重要な部分は知識の移転だと思う。私たちの小さなチームは、急いでない限り、PRがマージされる前に全員が承認するんだ。これでチーム全体がコードベースの状態をざっくり把握できる。例えば「このシステムが消えた！」みたいに、盲目的に驚くことがないんだ。もっと孤立した場所で働いていたときには、そういうことがあったからね。それに、どうやって動いているのか質問する場にもなるから、理解を深めることができる。高機能なチームでは、全ての開発者が自分が触れない部分も含めて、システム全体をある程度理解しているべきだと思う。もう一つ大事な機能は、組織の知識のチェックだね。最近、テーブルに小さな変更を加えたときに、同僚がそのテーブルに書き込むマイクロサービスを考慮していないことを指摘してくれたんだ（そう、テーブルを共有するのは悪いデザインだけど、関係ない）。そのマイクロサービスが存在していることすら知らなかったし、そのテーブルにアクセスできることも知らなかった。でも、この組織の知識のチェックが大きな問題やデータクリーンアップの状況を防いでくれたんだ。