ソースコードに正解は無いけれど...
ソースコードレビューを行ってもどかしく感じるのは「ソースコードの書き方に正解が無い」ということだ。同じ仕様書をベースにコードを書き上げても、開発者によってその構成や実装方法は様々だし、何が正解かという絶対的な指標は存在しない。デザインパターンやある種のイディオムを適用出来る範囲はどうしても限られてしまうから、その他の部分については「この書き方なら問題無さそうだ」と言ったレベルの主観的な判断に頼らざるを得ないのが実状だ。
例えば、メトリクスを取って定量的な分析を行い問題箇所を指摘することは可能だけど、メトリクスという視点で評価出来るのはソースコードの持つ特性の一面でしかないし、静的解析も同様にコーディング規約に従って「望ましくない書き方」は指摘してくれるけれど「この処理はクラスAからクラスBへ移した方が機能分担の観点から望ましい」なんて言う賢い指摘はしてくれない。
もちろん、ソースコードレベルの品質よりも、そのコードが動作して実現される「ビジネス上の成功」の方が大事なのだけど、だからと言ってソースコードのレベルを下げても良いという言い訳にはならないはずだ。第一、そんなことを言い始めたら、オブジェクト指向もモデリングも無視した「グローバル変数だらけのソフト」*1でも良いことになってしまう。そんな開発では開発効率も保守性も上がらないのは歴史を振り返れば明らかなので異論は無いものの、問題なのは現在主流のオブジェクト指向においては確固たる評価基準が無い点だと思う。
UMLのクラス図や機能仕様書と同様に、資料を読むだけで品質を検証出来ないのはソースコードが持つ特性の一つであり、品質確保に当たっては、ベテラン開発者の評価や視点に頼るところが大きい。多数の開発者の賛同が得られれば、それはソースコードの出来として問題ないレベルと判断して良いはずだ。だから、開発者が互いのコードを確認する文化が無い開発組織は、品質確保の面でかなり危ういと思っている。
なお、モデル駆動開発のようにモデルという抽象概念を対象に考えるようになると、設計が「見える化」されてきて、その善し悪しが分かりやすくなるのは興味深い。たぶん、クラス間の依存関係とか、状態遷移図やシーケンス図等に現れてくる「結線の多さ」に開発者は不吉な臭いを感じ取るからだろうと思っている。*2
関連
