No Project Small Library Principle
ある日、業務コードを眺めてていたら、ふとXMLをダウンロードさせるWEBプログラムのソースに出くわした。
それだけだったら何も目新しいことはないだろう、十分に使い古されたフォーマットであるし、何も目にとまることなど無いはずであった。しかし、何かがおかしい。
そのコードは、JDK標準クラスのみで書かれていたのだ。このライブラリやらフレームワークやらが溢れた時代に、まさか素のJDKだけ書かれた大規模なプログラムに出会うのは、私としてはとても珍しいことであった。
DOMを駆使して、最後はインデント処理まで施して出力しているのである。ライブラリが無かった時代ならそうであろうが、よりによって今どきそれ？と最初は思ったのであった。
しかも今回のプロジェクトではJava8を使っているし、古い環境だったというわけではない。開発者も昔からの古参Javaプログラマというわけではなく、それなりに若い世代である。
さて、彼らはどうしてこんなコードを書いたのか。
そのあと私は、だいぶ迷った挙句、そのソースの多様性を認めることにした。それはまさに、以下の原則に辿り着いたからである。
プロジェクト向けの小さなライブラリを書いてはいけない。 いつの日か、そのライブラリは運用チームでは 手に負えなくなり、メンテナンスされなくなる。 最後には放棄されるだろう。
どういうことか。
ここで言っているライブラリとは、世に出回っている汎用的なもの*1ではなく、各プロジェクト向けに存在する、そのプロジェクト向けの小さなライブラリのことである。
自作したそのプロジェクト独自のライブラリを極力使わないことで、より一般的な記述のみへと落とし込むことができる。プログラマの中には、こういった小さなプロジェクトライブラリを作ることを生業としている種の人物もいるであろうが、残念ながら長い目で見るとプロジェクトのためになっているとは言えない。
そのプロジェクト固有のビジネスロジックを含んだライブラリは、いつか管理しきれなくなるものだ。いつまでも書いた人物がプロジェクトに残ることは稀である。ビジネスロジックはライブラリに埋め込むのではなく、機能ごとの処理層に埋め込むべきである。
小さなライブラリを書く代わりに、我々に必要なのはマニュアルであり、チュートリアルであり、QAだ。Javaの基礎知識を持ったメンバーが新たにプロジェクトに参画した際、素早くコードを追加し、メンテナンスし、テストできるようにさせるには、これらのドキュメントが必要だ。
この原則に従う限りに於いては、長期的にメンテナンスしやすいコードを書くことが期待できるのではないだろうか。
最後に、一応書いておくが、全てのライブラリを書いたり、利用したりするなと言っているわけでは無い。十分に知られた*2ライブラリであれば、緻密に汎用化されているし、またドキュメントも充実しているだろう。その最たる例はJDKではないだろうか。
