問題がないかどうかチェックするために、確かめる箇所と確かめかたをコードの「読み進めかた」と呼びます。仕様との不整合をコードレビューで確認することは、多くのコードレビューにあてはまると思いますので、これを具体例として見てみましょう。 

あっさりとしていますが、この「仕様」に該当する部分を仕様から取り出し、対応するコードを確認します。

もう少し具体的に、独自にオンラインショッピングサイトを開発している場合を考えてみましょう。

仕様に「会員ステータス、買い物の総額、キャンペーンといった条件で送料を無料にする」といった部分があるとします。これらを実現しているコードを確認して、条件を満たしていれば送料が無料になるような実装になっているかどうかを確かめるといったように確認していきます。このとき、上の「確かめる箇所」と「確かめかた」は以下のように具体的に書けます。

確かめる箇所としてプロダクトコードを前提としましたが、テストコードがあれば、テストコードも確認する箇所に含まれます。

プロダクトコードであれば、その箇所が期待通り実現できているかどうか確かめます。テストコードでは、そのテストでバグがみつかるかどうかを確かめます。確かめかたは、送料無料の条件が正しく反映されるかです。同時に条件がそろっていなければ送料が加算されることも確かめます。

仕様として明示はされていないけれど、実現する必要のあるものを「暗黙の仕様」と呼びます。これも同じように確認しなければなりません。オンラインショッピングサイトの商品検索機能として

「検索キーワードを含む商品の一覧を表示する。1 画面に表示する結果は 30 件とする」

といった仕様が明示されているとします。このときの暗黙の仕様として

「検索結果が表示されるまでの時間は長くても数秒程度にする」

があります。表示に時間がかかるとユーザーがその機能を使わなくなるからです。この暗黙の仕様をあるべき姿と考え、確かめる箇所と確かめる方法を考えてみましょう。

確かめる箇所は、検索対象となる商品情報のデータ構造、検索部分、検索結果を表示する部分です。データベースの検索 API を使う場合や SQL で問合せする場合には、その部分が確かめる箇所です。

確かめかたは、扱う商品種類数や同時に検索される回数が増えても短時間で検索結果が表示できるかどうかです。たとえば、データベースに保存した商品数が増えるにつれ商品検索にかかる時間が長くなり、100 種類で 0.5 秒、10,000 種類を超えると 10 秒かかるとします。商品種類数が少ないうちは問題とはいえませんが、商品種類数が多くなると問題です。

将来、10,000 種類を超える商品を扱うことがわかっている場合には、商品種類数が多くなっても検索時間が短くて済むような API を使ったり、アルゴリズムを選ぶ必要があります。

慣れてくると対象コードのレベルも推測できるようになり、「これくらい書けているコードなら、仕様との不整合はほとんどないだろうから、違う読み進めかたをしよう」、「この仕様の例外的な部分だけ、不整合がないか確認しよう」といった具合に、読み進めかたを選ぶはずです。それに加えて、「この部分がおかしいということは、こっちもおかしいかもしれない」といった、同時に起こりやすい問題も推測すると思います。

「この商品を買った人はこの商品も買っています」のバグ版で、「このバグを作り込んだ人はこのバグも作り込んでいます」を想像しながら、読み進めることがあると思います。

地道ではありますが、こういった読み進めかたを増やしていくことで、「問題がないかをこのくらい確かめておけば大丈夫」という実感が持てるようになると思います。そうした実感がなければ、「だいたい 30 分くらいみたからいいか」というような所要時間で質を判断するようなレビューになってしまいます。漠然とながめていていも、読み進めかたを考えてじっくり見ても、時間は過ぎていきます。自分なりの読み進めかたが身についてくると、問題がないかどうかを素早く判断できたり必要のない箇所を読み飛ばしたりして、問題を早く見つけることができるようになるはずです。

読み進めかたは、仕様との不整合だけではなく、様々なものがあります。コードの読みやすさはその代表例です。

言語固有の勘違いしやすい書き方も同じように見つけることができます。次を見てみましょう。 

以下は、C、 C++、Java で使われる switch case 構文です。switch 文の後の変数 value の値によって条件分岐するための構文です。

switch (変数名) と書いて、case 値: と書くと、変数名の値ごとに実行する文を書けます。case のどの値にもあてはまらなかったときに default: の後の文が実行されます。if 文を羅列するよりも見通しがよくなるので、1 つの変数の値によって様々に分岐するときに使われます。

しかし、case の後に break をいれておかないと、次の case 以降の文も実行されます。

この構文の例では、変数 value の値が 1 (case: 1) にあてはまる場合でも、default 以降の文が実行されるため、switch 文の実行後の return_value は常に -1 になります。変数 value の値が 0 のとき (case: 0) のときには、break; があるので return_value は 1 となります。

このような問題を見つけるための読み進めかたは、次のようにまとめられます。

ここまでで、仕様との整合性、読みやすさを例として読み進めかたを説明してきました。要素技術に関しても同じように読み進めることができますが、要素技術に関しての読み進め方については後編でご紹介することにしましょう。

後編では読み進めかたの効率化の方法として、読み進めかたの整理と自動化の利用を紹介します。どうぞお楽しみに。