ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール6コードレビューが役に立つ3つの理由

　ぼくがプログラミングを本業として飯を食ってきた30年そこそこの間で、一二を争う大きな変化と言えば、様々な形式のコードレビューが徐々に受け入れられるようになっていったことだ。

　ぼくは、1990年代初頭まで、コードレビューなる言葉を聞いたことすらなかった。コードレビューが行われていなかったと言ってるわけじゃなく、もちろん行われていたわけだけど、医療機器のファームウェアとかロケットの制御コードとか、失敗という選択肢の存在しない状況以外では、広まっていなかった。分かると思うけど、そういう状況ってのはバグが人を殺す類の状況だ†1。

†1　仮想の人間じゃなく、現実の人間だ。ぼくはビデオゲームのプログラマーで、仮想の人間がぼくのバグでいつも死んでる。

　30年前、ほとんどのプログラマーにとって、誰かが自分のコードに目を通すってことは……侵略を受けるような気分だった。確かに、人と共同作業をしてるなら、チームメイトのコードが持つインターフェイスを調べるくらいのことはやって、接続方法を見つけ出さなきゃいけないし、おそらくは誰か他人のコードを1行ずつステップ実行していく羽目になる。でも、実際にコードを1行1行見ていって、コードについて判断を下すってのは、ずいぶん奇妙な感じがしたものだった。誰かの日記を読むような、あるいは（今風に言えば）誰かのネット閲覧履歴を偶然見ちゃうような。

　何はともあれ、1990年代初頭にMicrosoft社で、コードレビューに関するポリシーが定められている部署にぼくは異動した。ぼくの担当するプロジェクトは、その部署全体の壮大な計画の中では、取るに足らない存在だった。そのためぼくにとって幸運なことに、ぼくと、ぼくが担当するプロジェクトのチームは、完全に忘れ去られたのだった。ぼくらに任されたことの中には、自分たちのコードレビュープロセスを決めるという項目もあった。部署全体での公式なコードレビュープロセスが実際どんなプロセスなのかさえ、ぼくには分かっていなかった。ぼくらは自分たちが正しいと思うことをやるだけで、誰かがぼくらをチェックすることは一切なかった。何かのぞっとするプロセスが自分たちに課されることを恐れていたので、他からの指導を頼むなんてことは、当然ながらやるつもりがなかった。許可よりも許しを請う方がずっといい ...