「良いデザイン」とは?

作者 Mike Bria , 翻訳者 編集部 投稿日 2009年1月31日

セクション

プロセス/プラクティス,

設計/アーキテクチャ,

デベロップメント

トピック

Ruby ,

Java ,

動的言語 ,

.NET ,

言語 ,

Object Oriented Design ,

プログラミング ,

Agile ,

Legacy Code ,

設計 ,

Productivity ,

設計ガイドライン ,

バズワード ,

Refactoring

共有 |

ソフトウェアプロジェクトが成功する上で(および、実のところソフトウェア職に携わる上でも)、要となるのは良いデザインであるということは、今さら言うまでもない。「良いデザイン」が何を意味するのかを定義することは、一連の終わりのない討論、論文、話し合い、議論などで、長い間大々的に取り上げられてきた。これも新しいことではない。J.B.Rainsberger氏およびScott Bellware氏が真の定義がなされるまでフォローすると役立つアドバイスを提供している。

近ごろ、非常に尊敬されているAgilistであり、TDDのソートリーダーであるJ.B. Rainsberger氏(リンク)が「良いデザインの完全に構造的な定義を開発しようという、数多くの試みを何年間も目にしてきた」ことをコメントしている。氏の主な観察と個人的な意見(リンク)は以下のとおりである。

良いデザインには完全で、構造的な定義が不足していることに、嘆いている人がいる。わたしは違う。これについて特に心配する必要はない理由を、やっと明確に述べる。

「デザインの良さを正確にテストする」ことは有益なこと(その理由に関する例あり)であることに賛成している免責条項で続けるが、まだ本当の方法が確立さ れていないことを氏が懸念していない理由へと話は及ぶ。氏は自身の経験を引き合いに出し、結局「良いデザイン」になる可能性を最適化する支援をする必要があることについて、自身が感じていることを述べている。

過去10年にわたり、デザインに関するとても有益なことを学んだ。

• プログラマがデザインテストを記述するとき、 独自の欠陥をより迅速に発見する傾向にある。それにより、デザイン実現の総コストを削減できる。
• プログラマがコードを複製するとき、欠陥の割合は増加し、複製を減らすとき、欠陥の割合は減少する。
• プログラマが馴染みのないコードを初めて変更し始めるとき、コードの曖昧な名前を明確にすることから始める傾向にある。変数名、メソッド名 、クラス名である。このやり方は、コードをより安全に、かつより安価に変更する上で役立つ。

上記のことは自分自身での作業、他の人との共同作業および職場にいる他のプログラマを通して学んだ。こうした3通りの方法でさえも、ソフトウェアデザインの価値を大幅に改善できたことを述べることは有意義なことだと感じている。

J.B.氏は良いデザインを特定するためにしばしば使用していることについての考えで、締めくくった。「Miller Test(リンク)を使って何とかやっていく。それを見れば分かる」。

面白いことに、J.B.氏が言っていることで重要なテーマの1つは、デザインが良く見えるためには、それにまだ慣れていない人にとって「良く見える」べきであるという考えと関係している。名前を明確にすると、それを良く理解できる。それを見れば分かる。メッセージでJ.B.氏が意味していることを拡大解釈し ないよう、しかし良いデザインは必要最小限であり、「簡単に分かる」ということを示唆するためにこれを取り上げるものがいるかもしれない。近ごろ、Scott Bellware氏がその考えを書いた(リンク)。氏の言葉では、以下のとおりである。

「良いデザイン」の本質は、人の心によって吸収されることである。簡単に分かるのであれば、デザインは「良い」。
...
良いデザインは、知識に関することである。あらゆる種類の専門用語をまとめ上げたが、自分で簡単に理解できるソフトウェアの小さめのビットであり、お互いがうまく適合してより大きくなり、それでも簡単に理解することができることだという結論に至った。

Bellware氏は、必ずしもよく使われる方法ではないが、「テスト可能性」という用語が良いデザインの概念とどのように関連しているかを、深く掘り下 げている。コードの「テスト可能性」は「テストすることができるかどうか」についてではなく、むしろ「(現在は)簡単にテストされる」かどうか、また「テスト」が学習に関するすべてであるということである。

忘れないでもらいたいのは、テストとは観察することに関連し、観察は学習することに関係がある。
...
それが何をして、適切に実行しているかどうかを知るために、オブジェクトの設定が困難な場合、おそらくお粗末に設計されたオブジェクトになるだろう。このことが示唆するのは、テストコードを使用し、正しいデザインであることを証明することができる、ということである。そしてこれが、テスト可能性が意味するも のである。
...
たとえどれだけオブジェクト指向デザインが得意になっても、デザインが良いことを証明する唯一の手段は、(例/テスト)コードである。それが最高レベルのオブジェクトの設定しやすさを達成したことを正確に証明する。

そこでJ.B.氏が指摘しているように、「良いデザイン」を明確に定義することは、これらの金のニンジンの1つに過ぎないかもしれない。どれだけ前進しても、つねにわれわれの一歩先にある。また氏が強調しているように、またBellware氏が暗示しているかのように、自由に使えるツールが手元にあり、わ れわれを生産的にし、満足させる方向へ導くので、プログラマとして日々の業務に集中することができる。どう思うか?

原文はこちらです：http://www.infoq.com/news/2009/01/dont-need-def-for-good-design