書評:ソフトウェアアーキテクトが知るべき97のこと

http://d.hatena.ne.jp/qaz76/20100903/1283524501
で挙げた本の格言を12に絞ってみた。

　ソフトウェア・アーキテクトは、自分がリーダーであることを忘れがちです。
しかし、健全な職場で能力を発揮するためにはリーダーとして同僚から人目置かれるようにならなければなりません。

これには深い意味がある。
「伝える能力」と「発言力が必要」とも言えよう。

　エラーが起きない(起こさない)という前提に立つと、エラーを吸収、コントロールすることができなくなります。
エラーが起きることを受け入れたら、特定のエラーに対するシステムの対応を設計できます。

「楽観的・狭量になるな」ということだ。

物理法則を無視した建築家は、すぐに公開することになるでしょう。

もっとも、感銘を受けた格言。
当書中で似たような格言はあるが、これにつきるのではないか?
「だって動かないじゃん」
この一言をB-treeの上に置いておくべきだ。

アーキテクトって、ベンチマーク厨じゃないの？ｗ

どんなステキな設計思想もROIがすべてだ。

　単に汎用的であることを目標として設計された多くのものは、よく考えられていても、何の役にも立ちません。

「なにこれ使える」
これが重要。
"一般的"であることを目指した、"疎結合"がどれだけの複雑性を生み出したものか！
公共系のシステムで多いｗ

　優れたアーキテクトは、自分の専門分野に関しては少なくとも1つの(以上の)エキスパートでなければなりません。
アーキテクトは、手を動かさなければならないのです。

言わずもがな。
「試したの?」と自問自答してみよう。

　しかし、現実の世界は、ずっと前から同じ問題に取り組んできているのです。
遅れた手紙、破られた約束、行き違いになったメッセージ、間違った口座への支払いなど、例を挙げればきりがありません。

面白い。

　スターバックスは2フェーズコミットなどしません。
現実の世界へようこそ！

実に面白い。

　動くスケルトンからスタートし、動く状態を保ちながら、それを少しづつ育てていくのがコツです。

リファクタリングのコツでもあり、古い開発手法のアンチテーゼでもあります。

　実際には、すべてソフトウェアシステムがレガシーと形容されるべきものです。

というより、ゼロ・ベースの案件などもはや無い。

　問題解決のためにどのテクノロジーを使うかを選ぶのは、ソフトウェア・アーキテクトの仕事の中で大きな部分を占めます。

対処療法的提案をしていない？

　人々は、目標に向かって仕事をするために道具を使います。道具は目標のための手段にすぎません。

DHHも言っている。
「ソフトウェアというのはあくまでも小さなものを作って，それらの組み合わせでやるべきだと。」
http://gihyo.jp/dev/serial/01/alpha-geek/0006