言わずと知れた有名な本ですよね！
設計とアーキテクトは一緒の意味。
クリーンなアーキテクチャーを作ることが早くソフトウェアを作るために必要、という話が冒頭にあります。
いや、本当にそうなんですよね。
人数がいくらいようと、微妙な設計のソフトウェアは生産性が地に落ちてしまいます。
なので、とにかく設計が大事です。
ただ、私は経営者でもあるので、市場に投入するスピードも必要だということも理解しております…。
ここは本当にジレンマなんですが、要はバランスとしか最終的に言えません。
あまりに設計がずさんなものは、いくら早くてもリリースしないほうがいいですし、かといって設計にこだわりすぎてリリースがずっとできないというのも問題なんですよね。
リリースしてから気づくビジネスニーズというのはよくあることで、そのために設計を直さないといけない、ということもよくあることです。
多くのプログラマが間違ってとらえている話があるそうです。
「システムが動作することと、簡単に変更できることとどちらが大切か？」
多くの人が、動作すること、と答えるでしょう。
しかし、簡単に変更できることの方が重要だと筆者のボブおじさんは言います。
完璧に動作するが、変更できないシステムと、変更できるシステムだったら、後者の方にバリューがあります。
まー、そりゃそうですね。
後者は動作するようにすればいいわけですからね。
私も、19年近くプログラミングをしていますが、本当に設計が大事です。
これがおろそかにされていたら、プログラマーは常にバグと戦わねばならず、プログラマーの仕事のほとんどがバグと戦う仕事になってしまいます。
なので、あるプロジェクトが後半になってきたとしても、設計に問題があるとなれば、ウチではリリースを延期することもやむを得ないと私は思います。
さて、この本については多くの人が解説を述べていると思うので、ここで詳細を書くのはやめにして、私が特に心にとめておきたいことだけ抜粋しておきます。
①安定した抽象に依存すること