今のプロジェクトはJavaで、保守フェイズの新規機能追加なので既存コードをよく読む。
お世辞にも、綺麗なコードとは呼べないし、
しかし、このプロジェクトの初期段階で書かれた開発者向けガイドを読んでびっくりした。
そこには、初期段階でアーキテクトが色々考えてルール決めをしたと思われる形跡が垣間見えた。
例えば、疎結合や、高凝集性、情報エキスパートといった考え方を説明していて
柔軟なオブジェクトを設計することを推奨していたり、
テストコードを作りやすいように、フレームワークAPIに依存しない仕組みを提供したりしている。
当然テストコードも推奨している。
しかし、その成れの果てはというと。。。
・クラスは出来るだけ少なくするというルールが出来てて、1クラス10000ステップもザラ。
・テストコードは一切存在しない。junitのjarの参照すら消されている。
・〜Commonや〜Managerと命名されたクラスが大量にある。名前づけはほとんど意味を成していない。
・StrutsのFormがDAOまで依存。
アーキテクトの想いやルールは、ただの足かせにしかなっていなかったようだ。
もともとあったアーキテクトの想いやルールだけではソースコードを綺麗にすることはできない、
フレームワークの強制だけでもだめみたいだ。
僕は、その思想に基づくサンプルコードこそがルールになるべきものだと思う。
コードを示すにはコードだ。
それはサンプルコードと呼ぶものではなく、規範コードとでも呼びたい。
サンプルコードと呼ぶと特定の実装方法を説明するための説明コードになることが多いからだ。
規範コードは、そのプロジェクトの一般的な機能をある程度含んでいて、
十分にリファクタリングされていて
アーキテクトの思想が反映されたものが良い。
*1:6年も前のプロジェクトだから仕方ない。