人は導いてくれるものを欲する。成功するためにはそれにしたがっていさえ入れば良いというような、「真実の法則」の探求は、ソフトウェアにおいて新しいものでもないし、また、ソフトウェアに限定されるものでもない。
- ソフトウェアの方法論から得られるものは何か、その方法論の限界はなにかを知っておくことが重要
- 良いソフトウェアを作り出す絶対確実な方法というものはない
- 問題が基本的なパターンの集合になるまで限定できれば、教えるということが可能な手順を定義できる
- ソフトウェアパッケージや再利用可能なライブラリとして吸収される
- しかし対象問題領域が広がれば単純なアプローチはうまくいかなくなる
- 特定の手法を誇張して評価しているような文献もすべて拒絶するというのではなく、何らかのアドバイスが含まれているかもしれないので、多少割り引いて読む必要がある
オブジェクト指向を利用する
- 方法論として有名なものにダイクストラの「Goto 文は有害」という記事と構造化プログラミングがあるが、すべての方法論がその水準に達しているものではない
- ソフトウェア構築に関する規則を作ることは比較的簡単だが、よく考えられていない有害でさえあるルールが作られることがある
- 方法論の役割を分析した指針を知っておくことでそういった有害なルールを避けることもできる
方法論に関するルールは対象に関するある一つの理論に基づくものでなければならない
- ダイクストラの例も個人的な好みや意見からGoto命令を攻撃したのではなく、一連の理論に基づいて禁止したほうが良いという主張。
- 反論するには、理論の欠点を見つけて、その理論に代わるものを提示しなければならない
- 理論はソフトウェア方法論の演繹を担うが、理論のみに基づくルールには危険がある
ソフトウェア方法論のルールは広範囲にわたる実践的経験による裏付けがなければならない
- 実践的経験を経て再利用可能なライブラリを作っていることが専門家と呼ばれる資格がある
[再利用の経験]
オブジェクト指向の分野において専門家の地位を主張するためには、多様な状況の多様なプロジェクトでうまく再利用されたクラスライブラリの開発において中心的な役割を果たしていなければならない。
NOTE: 類型とは、共通の性質・特徴を持つ物同士をまとめてくくった一つの型。また、その型に属するもの。 類型論とは、個々の事象からいくつかの類似点を抽出し、典型的な類型をもって代表・記述することにより、それらの事象群の本質や構造を考察しようとする学問的方法論。
規則には、
- 助言的なもの(特定のスタイルを勧める)
- 絶対的なもの(ある特定のやり方を強制する)
がある。 また、
- 肯定的な形式で書かれたもの(するべきことを示す)
- 否定的な形式で書かれたもの(してはいけないことを示す)
がある。これらの組み合わせから規則は、
* 絶対的な肯定: 「常にaをせよ」
* 絶対的な否定: 「絶対にbを採用してはならない」
* 助言的な肯定: 「可能な限りcを採用しなさい」
* 助言的な否定: 「可能な限りdを避けなさい」
の4つに分類できる。
- あいまいさのない指示になるためソフトウェア開発者にとってもっとも役に立つ規則である
- ただ、方法論に関する文献において最も少ない
- 正当な理由もあるが助言者自身が、用心してあえて危険をおかさない。つまり、顧客の行動に責任を取らないようにするために曖昧な態度をとっているためである
方法論に関する規則を考えるとき、絶対的な肯定に含まれる規則を優先し、そのような規則の1つ1つについて、その規則をツールか言語構造として自動的に強制することが可能かどうかを検討せよ
ダイクストラのGoto廃止論が絶対的な否定にあたる。
絶対的な否定はなぜその人がそのメカニズムを悪い習慣として拒否したのかを示す厳密な説明による裏打ちが必要なだけでなく、そのメカニズムの代わりに他のメカニズムを使う方法を示す厳密な説明が伴わなければならない。
- 「意味のある変数名を使え」
- 決まり文句であって原則ではない
- この規則を原則とするためには、変数名を決めるための厳密な基準を定義しなければならない
- それらの基準に同意しない人も出てくるので決まり文句のほうが気楽
- 「可能な限り〜」「絶対に必要で無い限り〜」という言い回しは最も不誠実
- そのような助言は無駄であり、説明するツールには安全性と確実性に問題があり、完全に信頼すべきではないという印象を読者に与えるので負の効果がある。
助言的な規則(肯定であれ否定であれ)を作るときは決まり文句ではなく、原則を使うこと
- 規則が常にそうとは限らないと言いたい場合、どのような場合が例外かを具体的に示すべきでそうでなければその規則自体が無効になる
- 開発者が微妙なケースに遭遇するたびに、その規則は当てはまらないと判断する権利が与えられているため
広く適用可能な指針で、例外の可能性がある指針を方法論の規則として提示する場合、その例外も規則の一部として記述しなければならない
- 「Aという状況においては常にXをせよ」という絶対的な肯定や「Aという状況においては絶対的なYをしてはならない」という絶対的な否定の中に「ただし、B、C、およびDのケースをのぞいて」という修飾語を追加することが避けられない場合がある
- 確かに絶対的がだが、規則の記述は厳密であるのに、例外の規定があいまいだから受け入れられない
- 煮え切らないアドバイスはだいたい役に立たない
- 総括的なことばかり述べているので、読者がそのときに直面しているケースに適用されるかどうかの確信が持てないからだ。
汎用的な設計方法(正しいクラスの見つけ方や最善の継承方法)といったものには、命令的である必要はないが、適用されるかどうか迷うことなく判断出来る程度に厳密である
- C++の type castの例を見ると、助言的な否定全般の問題がよく分かる
- そのツールや言語に限界がある
- 「絶対に必要でない限り、このメカニズムはなるべく使わないように」という言い回しに逃げることが多いような気がしたら、問題は教える対象にある
- ツールを改良するか、もっと良いツールを作るべきである
多くの助言的否定が必要になったら
* 元のデザインの欠陥を反映するものではないかどうか、元々のツールまたは言語を検討せよ
*
- 難しいことについて話すときに、たとえによる説明として比喩を用いる
- 科学的な文献(ソフトウェアの方法論についても)において比喩は強力だが危険でもある
- 多くの問題を直感的に理解するために比喩は使われる(研究、教育等)
- ただ、取り違えることがあるので冷静になって比喩の使われ方を考えることが重要である
- スポンジの例のようにその比喩を唱える人の経験等から比喩にハマりすぎているということを把握して、現実Aと喩えのBを取り違えないようにする
- 素晴らしい製品を作るには、最も優秀な人たちも含めて、設計者は自らの経験の価値絶対に過大評価するべきではない
- ソフトウェア設計において、新鮮なとらえ方と創造的な洞察力に代わるものはない
- プライドを捨てて、それを思いついたのが自分であるかどうかにかかわらず良い考えをとっておく方法を知っておくこと
- 自分自身に対して最も厳しいという規則はソフトウェア設計において特に重要である
- 知的怠慢に陥り、安易で誤った決断をし、後で深く後悔する危険が常にそこにあるから