Analyzing and Understanding Designs

設計自体を分析したり理解するためには、どうすればいいのか？

ここで議論したいのは、ある問題領域に取り組んでいるときに、その問題に対してどのような設計がいいのかということでなく、ソフトウェアにおける設計という活動・行為やその設計から導かれるソフトウェアの構造そのものを分析したり理解したりするにはどうすればいいのかということ。

問題領域を無視して設計を分析・理解することは無理と思われるかもしれないけど、（GoF の）デザインパターンなんかは、問題領域そのものには（それほど）依存せずに一般的な設計の問題とそれに対する解を文章化している。

同じように、リファクタリングカタログなんかも、プログラムの設計を改善するという視点から、設計における問題点とその改善方法を文章化している。

恐らく、これらデザインパターンとリファクタリングは、設計を分析して体系的に文章化するという意味では、代表的なアプローチだと思う。

リファクタリングはともかくデザインパターンをわざわざ書いて設計を分析しようという人はそれほど多くない。「パターンハッチング」なんかに書いているように、デザインパターンを書くという行為はなかなか大変だと思う。

では他にアプローチはないのか。

UML のクラス図なんかは、クラス間の構造的な関係などを視覚的に表現することで、現在行っている設計がどのようなものかを理解する助けにはなくかもしれない。

JavaDoc などの API ドキュメントなんかも、助けになるかもしれない。

設計を教える本（たとえば「アジャイルソフトウェア開発の奥義」）なんかは、自身の設計スキルを向上させるのに役立つかもしれない。

すごくナイーブなアプローチとしては、設計上の問題にぶちあたったときに、その設計上の問題を 考えるの ではなく、体系的に分析して文章化する方法がある。ある設計Ａの時の利点と欠点、設計Ｂの時の利点と欠点、などなど。

ただしこのアプローチは、まともに取り組もうと思うとすごく大変でめんどくさいと思う。なぜなら「Modern C++ Design」にも書いているように、設計という行為は、一手先を読むような行為ではなく、数手先を読むような行為だと思うから。

一手先を読む（つまり現在の要求だけを考慮する）場合は、設計Ａが設計Ｂよりよいかもしれない。しかし、数手先を読む場合（つまり、将来の要求を想像する）には、設計Ｂから出発する パス を選択するほうがよいかもしれない。

もちろん、将来起こらないかもしれない要求を考慮してのアップフロントな設計は、無意味に複雑な構造に至る可能性がある。

ソフトウェア設計の複雑性にどうやって取り組んでいけばいいのか。

もちろん、色々な取り組みがある。デザインパターンであったり、言語設計者が考える新しいパラダイムやモジュール化の方法であったりがある。

しかし、それらの取り組みは体系的なのだろうか。

設計自体を理解したり分析したりすること自体のためのツールやアプローチ、あるいは方法論はそれほどないのかはないか。

先ほど例であげたように、デザインパターンやリファクタリング的に設計を文章化する方法や、ナイーブにその時々の設計を分析していく方法などしかないように見える。