俺のコードのどこが悪い？ -コードレビューを攻略する40のルール-

コードレビューは、アプリケーションの品質を向上させる上でとても重要な取り組みだと認識されるようになっています。そんなコードレビューですが、私も以前、叩かれてへこんだりしたこともありました。そうこうしているうちに慣れて、むしろ指摘してもらえることで知らなかったことを知る機会となり、プログラマとして成長する良い機会でもあると、いまは考えています。

例えば、本書の中で、行の折り返し位置の体裁について2通りの折り返し方法を紹介しています。

横幅最大値を超えた時点で機械的に折り返し
構文木上の、より上位の要素において折り返し

後者の構文木の上位要素という考え方は、私には全くなかった考え方で純粋にそんなやり方もあるんだなぁとおもしろかったです。知らないことを知る場として楽しめるようになると良いけれど、お仕事だと厳しい意見もちらほら聞くかもしれませんね。

さて、本書の「レビュー準備編」では、コードレビューでへこまないための心構えや、そもそもコードレビューはどんな風にやれば良いの？といった、体系的な方法論とチェック項目を網羅しています。レビューチェックシートのサンプルも掲載されていて参考になります。

主題の「レビュー実践編」ですが、本書はコードレビューのためだけのノウハウ本ではなく、C/C++/Java といった言語仕様まで突っ込んだ特性を、コラムで説明しながら、こういう仕様の落とし穴があるからコードレビューでそこを注意しましょうといった解説になっています。私は C/C++/Java の開発経験がほとんどないので、へー、そういう仕様なのかと興味深く読ませてもらいました。コラムだけでも、著者の培ってきた実業務の経験が垣間見えたりします。

著者自身もあとがきにこのように書かれています。

あらゆる知識はお互い密接に関連しあっています。ということは、「汝、〜〜すべからず！」の裏側にも、コンパイラやインタプリタ、OS、CPU などの愉快な仕掛けが隠されているわけです。プログラマにとってこんな楽しいものはありません。レビュー項目に隠された、そんな楽しさの一端をなんとかして伝えたい、そんな目的をこっそり忍ばせて書き進めた結果、コラムや脚注がやたらと多い、珍妙な本になってしまいました。

いくつか私にとって興味深かったコラムを紹介すると、以下のようなものがあります。コードレビューを、プログラミングに関する背景を教える場と捉えても良いかもしれませんね。

switch 分岐の効率

if/else 文は条件指定が増えるほど条件判定を実施するコストが増えるが、switch 文では case ラベルが増えてもアドレス格納テーブルのサイズが増えるだけで条件判定のコストは増えない。

スタック渡しによるコスト

x86 アーキテクチャの 32 ビットモードはスタック渡しで、64 ビットモードはレジスタ渡しになる。6引数の関数を呼び出すために引数を準備するコストは、スタック渡しが 6.0 クロックに対してレジスタ渡しが 0.1 クロックだった。

言語として「頼り過ぎ」に舵を切った Python

Python のイテレータは next() で次要素の取り出そうとするが、要素が無ければ StopIteration 例外を発生させる。例外を多様する実行制御をもつ言語特性がある。これは用語集にもある EAFP の考え方の違いですね。

fork() の使用

fork した子プロセスで execv() などの exec 系システムコールを使用して子プロセスを上書きする

「具象」から「抽象」へ

最初に基底クラスから定義しようとして上手くいかないのは「抽象」は多くの「具象」をもとに「抽象」化されるので、その順番でやってみると良い。

コラム単体を読んでもおもしろそうなので、コラムのインデックスがあると良かったなと思います。

読んでいるとコラムで横道に逸れることも多いのですが、もちろん本文も技術的背景が詳しく説明されています。読み進めていくとコードレビューというよりは、プログラミングのコツを教えてくれるように受け取れます。はまるポイントをコードレビューでチェックしようとしているのですから、プログラミングの深い洞察につながるのは道理ではありますね(^ ^;;

「レビュー実践編」はかなり幅広い内容を網羅していてプログラミングの気を付けるポイントとして実用的な項目がたくさんあります。本書で一通りチェックしてからコードレビューに臨むと指摘される項目がずっと少なくなると思います。とても勉強になりました。

リファレンス:
『俺のコードのどこが悪い？』へのご意見・ご要望・誤記情報 - 彷徨えるフジワラ
 技術系執筆情報