Design It! ―プログラマーのためのアーキテクティング入門

日本語版序文

ソフトウェア開発のアジャイル化が進み、ソフトウェアは生き物としてますます頻繁な変更にさらされるようになった。

アジャイル開発のアーキテクチャに対する基本スタンスは、最初に先読みをしすぎた設計（BDUF = Big Design Up Front）をしないということだ。設計に大きな先行投資をせず、動くソフトウェアを維持しながら進化させていく。アーキテクチャはこの繰り返しによって立ち現れてくるもの、実験と実装とユーザーフィードバックの結果として「収穫」されるものである。中心となるユーザー価値から作りはじめ、イテレーションを繰り返しながら全体設計が現れてくる、というのだ。これは、これまでの大きな先行設計がかえってシステムを複雑にし、結局作らなくても良い汎用構造や複雑なメカニズムを作ってしまうというリスクを下げている。さらに、アーキテクトと呼ばれる神様が実装をせずに机上で架空の“かっこいい”構造を作り出してしまうことも避ける。アーキテクトとプログラマーという構造ではなく、アーキテクチャを民主化したのだ。ソフトウェアの機能を実装して動くことを確認しつつ、追加や変更を順次受け入れながら、リファクタリングによって内部の重複部分を取り除いていき、コードベースの成長にしたがって必要だった抽象構造が現れてくる……はずだ。

しかし、本当にそうだろうか？　アジャイルとアーキテクチャ論は何度も議論になることがあった。特にリファクタリングの繰り返しによってのみ、アーキテクチャは本当に現れるのだろうか。それは現在意図している機能だけから作られるものだろうか。リファクタリングで扱いきれないような大きな変更はどう扱うのだろう。アーキテクチャは現在作ろうとしているソフトウェアの機能や非機能だけでなく、過去の経験や知見からもヒントが得られるのではないか。アーキテクチャは選択する、ものでもあるはずだ。BDUFは良くないとしても、NDUF（No ...