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

12章アーキテクチャに通知表をつける

学校の通知表は、生徒、保護者、そして教師にとって重要なフィードバックループだ。学年の終わりまで待って進級できるかどうかを知る代わりに、四半期ごとの通知表を見ることで、成績が順調かを確認できる。そして、手遅れになる前に改善できる箇所がどこかも確認できる。学校の通知表のように、アーキテクチャの評価にも時間を使うべきだ。そうすることで、デリバリーを順調に進めることができる。

評価をプログラミング時間を奪うものだと考えるのを止めよう。代わりに、プログラミング時間をさらに強力なものにする方法だと考える。評価にかける時間はわずか1時間だっていいし、既存の開発プロセスの中に気付かれないよう評価を組み込むことさえ可能だ。

この章では、アーキテクチャに通知表を付ける方法を学んでいく。評価から得たフィードバックは、チームの教育、設計判断への肯定的な意思の作成、デリバリーリスクの軽減、アーキテクチャの改善といったことに利用できるはずだ。

12.1　評価し、そこから学ぶ

アーキテクチャ評価は、アーキテクチャが目的を満たしている程度について学ぶプロセスだ。ソフトウェアアーキテクチャを設計する際の一般的な誤りは、設計段階の最後にアーキテクチャを一度だけチェックすべきだという考えだ。アーキテクチャを誤れば、すべてが失敗し、実装だって始められない。この考え方はどうしたって絶対に間違っている。

アーキテクチャには、完全に良いも完全に悪いもない。アーキテクチャ全体を一度に見ることができないように、アーキテクチャ全体を一度に評価することだってできない。別の部分をリスクで埋めつつも、一つのコンポーネントをうまく設計したり、アーキテクチャの領域の一つをよく理解することは可能だ。実装を開始するために、すべてを完成させる必要は全然ない。 ...