EMBlog

仕事でプログラミングをしていてよく思う。どういう構造にしてコードを書けば開発期間を短縮できるか？
再利用が容易、メンテナンスが容易、全体の構造がわかりやすいなどが挙げられるが、最も重要なのはアーキテクチャだ。

最初にアーキテクチャ、フレームワークづくりに失敗するともう最悪。土台が狂ったままその上にいくら構築してもだめ。つじつまを合わせるためうんざりするコードになってしまう。まずもって、処理内容がわかりにくい。そしてバグが出やすく、修正が困難。しかも機能追加して規模が大きくなるほどに土台を修正しづらくなる。土台の上に構築された部分への影響があまりにも大きいからだ。したがって放置されがち。するとさらに状況は悪化する。

…というわけで、美しく健全なシステムを構築するには状況に合ったアーキテクチャを設計することが大事なのだ。そういうことができる人材（アーキテクト）はいつでも重宝されるだろうし。デザインパターンはを知っておくことは、優れたアーキテクチャを設計するためのひとつの材料になる。斜め読みでもいいからこの本に書かれていることは頭に入れておこう。引き出しはたくさんあったほうがよい。後で困ったとき、ああ確かこれはあの本のどこどこに書いてあった、と思い出せればOKだ。

デザインパターンはもはや知っていて当然の知識なので知らないと逆に恥ずかしい。原書は1995年に発刊されている。なんと10年前のものだが、日米のamazonでは今でもよく売れているようだ。amazon.comのレビューのほうが数が多く、参考になる。