コードレビュー
コーディングの後は、単体テストに入る前にコードレビューを行います。
さて、コードレビューの目的は何でしょうか。バグを見つけることでしょうか。
昔々、３０年前、ホスト系システムを開発していた頃、テストで使用するマシンは、とても高価で、使用できる時間も１日に１時間を割り当ててもらえるかどうか、という環境でした。
従って、同じテストを繰り返さなくするか、テスト時間をいかに短くするか、いかに効率良く行うか、に努めました。それが、マシンを使用する前、テスト前にバグを検出することでした。机上デバッグと呼ばれた工程です。
この机上デバッグにおいて検出したバグ件数が、計画時に目標とした値に達しないとテストに着手できませんでした。
テストで使用するサーバやＰＣのコストや性能を意識せずにテストができる環境においては、机上デバッグを行うよりも、逆にマシンを使用したテストを行った方が、効率的でコストパフォーマンスも高くなるかと思います。
ということで、コードレビューと机上デバッグは、違うことと思います。では、コードレビューの目的は、バグの検出ではないとすると、何でしょうか。
バグとは関係無いところになりますので、正常でも問題が有ること、たとえば以下のようなことがあげられるかと思います。
・コーディング規約に準じているか
変数などの命名のルールなど、コーディング規約が存在すると思いますが、それに準じたコーディングがされているか。
・冗長なコーディングがないか
同じ処理が何か所にも書かれていて無駄がないか。１つにまとめて、それを呼び出すようにすれば、ステップ数も削減でき、バグの発生率も抑えられるかと思います。
・パフォーマンスを悪くしていないか
パフォーマンスに影響するようなコーディングがされていないか。ＳＱＬ命令の記述内容は、妥当かどうか。
コードレビューのポイントには、いろいろと有ると思いますが、一つには、上記のようにバグではなく、正常に動作するのだが、適当ではないと思うようなところを検出することではないかと思います。
で、一番大事なのは、レビューポイントが明確になっているか、ということだと思います。複数の人がレビューするケースで、レビュー内容がまちまちでは、品質も安定しませんからね。特に、チームやサブシステム、コンポーネント、開発会社によって、レビューポイントが異なるようでは、困りますよね。
従って、レビューポイントが書き物になっていたり、レビュー項目（ケース）が記載されたレビューシートが用意されていることも大事なように思います。
ちなみに、コードレビューを受ける前に、１回実行して動くことを確認するのは、疎通テストと呼ばれる工程だと思います。コードレビュー後にごっそり書き換えられたら、せっかくコードレビューを行った意味が無くなりますからね。
コードレビューを含め、顧客やプロジェクトによっても異なることもあるかと思います。何事も一つ一つの意味、目的を理解して作業することが大事なことのように思います。
もし、コードレビューの後で発生した障害（バグ）が、コードレビューで発見できるような原因であれば、書き物になっているレビューポイントやレビュー項目（ケース）に追加することにより、同じような原因の障害（バグ）が発生することを防ぐことが可能になりますよね。
こうやって工夫していくことにより、品質も上がっていくものだと思います。
仮に、新人のような若手に教育目的でコーディングを任せているようなケースで、コードレビューの際にバグを発見したとしても、教えることはしないですね。バグを発見することも、原因を調べることも、対処方法を考えることも、すべてが勉強ですからね。失敗から学ぶことの方が身になりやすいということです。
冷たいように思われるかもしれませんが、自分で蒔いた種は、自分で刈り取るということです。
Filed under: トライアンフ | No Comments »
トラックバック URL :
