stack overflowコミュニティ(リンク)のメンバの１人が、「設計は最近ではリファクタリングの一部なのだろうか？」という質問をした(リンク)。この疑問は、創発的な設計へのアジャイルのアプローチについて多く見られる誤解を浮き彫りにしている。よくあるアジャイルのマントラは、「テストをする。コードを書く。リファクタリングする。繰り返し！」である。このアプローチは設計に取って代わるものではない。単にプロジェクトの期間にわたって作業を広げるのである。
Phil H.氏はこのような質問をした。
この新しい方法は、最初のイテレーションの範囲の目標を達成するために必要なものに没頭して書き、洗練された解決策を得るまで必要に応じてリファクタリングをするようになるように思われます。みなさんのコードベースはインクリメンタルに大きくなり、大きな計画/階層的な設計段階を経ることはありません。それが、私には、ソフトウェアの設計がリファクタリングに組み込まれてきていることを示唆しているのです（それは価値があるのですが）。なぜなら、洗練されたコードは、機能のインクリメンタルな追加ではなく、そこからもたらされるからです。
私は間違っているでしょうか？
Big Design Up Front(リンク) （事前の大規模な設計）は設計ではない。設計を完遂するための一つの方法である。アジャイルを実践している人たちは、異なるアプローチを好む傾向があり、その方法ではサポートされている実際の機能に応じて現在の設計が明らかになる。設計はシステムのニーズに反応して状況に適応し、それ自身が絶え間なく進化するとともに顧客の要求にあわせて変化する。
アジャイルの、テスト駆動の、機能の追加やシステム設計の進化のアプローチは、次のように示すことが出来る。
- 新しい機能のためのテストを作成する。
- テストを実行し、失敗するのを確認する。まだその機能のコードは書かれていないから失敗するのである。
- 必要な機能の実装に過不足のないコードを書く。
- テストを実行し、通ることを確認する。
- 新たに追加されたコードを含め、システムが洗練されるまでコードをリファクタリングする。
このアプローチの本質は、いつか（もしかすると）必要になるかもしれない機能のサポートに苦しむことなく、必要だとわかっている機能をサポートする設計を行うことである。
Fabian Steeg氏はKent Beck氏に言及し、こう述べた。
ゴールは機能するきれいなコードです。[...] まず、私達はこの課題の「機能する」の部分に対処し、それから「きれいなコード」の部分を解決するでしょう。これはアーキテクチャ駆動開発とは正反対のもので、そこでは、みなさんは「きれいなコード」を初めに解決し、それから「機能する」の部分を解決するにつれて分かったことを慌てて設計に統合しようとするのです。
これは文字通りに取り過ぎて誤解する可能性がある。ある参加者は次の例を挙げた。
私が中流よりもむしろ早期のプロセスで多くの設計の決定をする理由は、これによって一番安上がりになることがよくあるからです。例えば、もし私達がプラットフォーム依存の技術を使って早くからアプリケーションを書き始めていたら、それを取り消すという決定は非常に高くつくかもしれません。もし私達がコーディングを始める前にサポートしたいプラットフォームについてよく考える時間を取れば、格安です。
この人物は、「創発的な設計」とはアジャイルの開発者が事前に何も考えていないことを意味する、と誤解するという罠にはまっている。現在の設計には、我々が現時点で知っている全ての情報が含まれていなければならない。もし我々が複数のプラットフォームをサポートする必要が出てくることがわかっていれば、我々はそれを設計に含める。しかし、もし１つのプラットフォームのサポートだけが必要であるという確信があれば、我々は設計を制限するのを避けるだろう。なぜなら、「いつか移植したくなるかもしれない」からである。
以下のようなアジャイルの指針がいくつかある。
これらが指針であり、無分別あるいは独断的に従うことを意図したルールではないことは、注目に値する。これらは経験のある開発者の決定を助けるためにあるのであり、どれに決定するべきかを開発者に教えるためのものではない。
みなさんの設計へのアプローチはどのようなものだろうか？いたずらに制約することなく、どのようにしてみなさんのコードやコーダーに役に立つアーキテクチャを作成しているだろうか？コメントを残して意見を共有して欲しい。
原文はこちらです：http://www.infoq.com/news/2009/02/Refactoring-Is-Not-Design