ThoughtWorksアンソロジー（その１）

僕はマーチンファウラーの考え方がとても好きで、その著作（リファクタリングとかUMLモデリングのエッセンスとか）もわかりやすくて好きだ。そんなマーチンファウラーがチーフサイエンティストを勤めるコンサル会社「ThoughtWorks」の社員が書いたエッセイを集めた本「ThoughtWorksアンソロジー」が発売され、それを今読んでるところ。まだ半分くらい。
で、その中のひとつに「オブジェクト指向エクササイズ」という章があって、シンプルな9つのルールに従うことによって、ソフトウェアの設計が改善され、オブジェクト指向なプログラミングが書けるようになる…というもの。その9つってのが以下のとおり。

1. 1つのメソッドにつき、インデントは1段階までにすること。
2. else文は使用しないこと。
3. すべてのプリミティブ型と文字列型をラップすること。
4. 1行につきドットは1つまでにすること。
5. 名前を省略しないこと。
6. すべてのエンティティを小さくすること。
7. 1つのクラスにつきインスタンス変数は2つまでにすること。
8. ファーストクラスコレクションを使用すること。
9. Getter、Setter、プロパティを使用しないこと。

このルールに従った1000行程度のプログラミングを無理やり書くことにより、今までと違った考え方が生まれる…というお話。それぞれのルールは一般的によく言われる「良い設計」を極端に突き詰めたもの。別にこのルールに沿ったシステムを構築しろと書かれているのではなく、あくまでも「エクササイズ」だそうだ。なるほどね。
しかし本章の最後には、実際にこのルールに従った100,000行を超えるシステムを構築したってんだから驚きです。うちのプロジェクトに適用…するのは無理だろうね。やっぱりエクササイズとして考えるほうが現実的。レビューはシンプルになるかもね。
まぁそれはそれで置いておいて。こういった「良いルール」とか「オブジェクト指向」や「デザインパターン」ってのは、実際の業務に使おうとすると結構難しいということがわかる。個人的にガツガツ利用するのは構わないんだけど、結局それを誰が理解できるのか…という壁にぶつかる。それぞれの開発者にはベースとしてそれらの概念を学ぶ必要が出てくるが、実際にそれらの概念を理解している開発者は少ないし、様々な開発会社やスキルの人が集まって開発をするわけだから、それを強要するのも困難。とてもキレイでエレガントなシステムが出来たけど、それを理解し保守・拡張できるのは一部の高度なスキル保有者のみ…となっても意味が無いわけで（もちろんエレガントに実装すれば「誰にでも理解できるコード」にはなりえるけど、ではそのエレガントさを保ったまま保守できる人がいるかどうかはまた別の話）。結果的に「誰でも理解できる、ごく普通の方法」を選ばざるを得ない。それが例えオブジェクト指向的にはエレガントでないと知っていてもね。
開発をしているとそういうジレンマが少なからず出てくる。知っている知識や技術を100%フル活用できていないっていう。そういうことを気にせず、お互いがとても高いレベルの技術力を保有していて、自由に連携をしながらシステムの開発が出来たら、また別の世界が広がるだろうなぁ。

ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション