「プログラマが知るべき〜」が流行っているようですが、そのシリーズで以前に出ていた「ソフトウェアアーキテクトが知るべき97のこと」のほうを読みました。テーマは多岐に渡るのですが、3つほどピックアップ。
問題解決
ユーザが必要だという機能や特徴に、実は何を求めているのかをたずねれば、アーキテクトは本当の問題を考えることができますし、おそらくクライアントがいう解決策よりも安くてより良い方法を考え出せるでしょう。本当に大切なものに力点を置けば、優先順位もシンプルになります。 （p.12 アイナー・ランドル）
普通の人は、実際に手にするまで自分がほしいものが何かわからないものです。 （p.71 デーブ・クイック）
結局、もっとも安くで済むのは、複数のソリューションを試してみる方法なのです。 （p.59 エリック・ドーネンバーグ）
問題とは何か、その解決策は何がよいか、というのは、ワインバーグの「ライトついてますか？」の主要なテーマで、ときどき読み返しています。
誰かの立場から見た問題と解決策は、単純なロジックツリーで表されるほど単純な関係ではありません。解決策の知識がある場合とない場合とでは、問題自体の捉え方が異なるので、実物を見たときにコレジャナイって場合も当然あります。だからこそ、モックや、頻繁なリリースが有効なのでしょう。少しずつ最適解に近づけていけばよいわけです。
パフォーマンス
なぜ、パフォーマンステストがそんなに大切なのでしょうか。最大の理由は、どのような変更を加えたときにパフォーマンスが急降下したかがわかるということです。（p.26 レベッカ・パーソンズ）
この発想はありませんでした。言われてみれば当たり前の話です。
普段かかわる仕事において、パフォーマンスの細かい測定にはあまり価値を見出していません。でも、10倍とか、1/10 とかは気になります。開発の初期から、パフォーマンスを測定していればよさげです。
トレードオフ
「十分よい」というのはどこのことなのでしょうか？ それは、不備が残っていても、システムの機能、メンテナンス性、パフォーマンスにこれといった影響を与えないことです。 （ p.140 グレッグ・ナイバーグ）
[...] いかに魅力的に感じたとしても、すでにわかっている要件やユーザーが希望している特性以上に大規模なシステムを設計するのは避けましょう。 （p.194 ビル・デオーラ）
ここで言う不備は、アルゴリズムが最速ではないとか、余計な処理が残っているとか、そういう話です。その前提で、不備はイコール不十分ということではない、ということです。その時点での、最小セットであればよい、と。どうせ変更はあるし、あらゆる変更に対処することはできません。
一方で、こういう話も。
設計の判断として2つの選択肢のどちらを選んでもよさそうな感じがするときには、アーキテクトは1歩下がって考えなければなりません。選択肢AとBのどちらを選ぶかではなく、A、Bのどちらを選んでも、それほど重大な意味を持たないようにするために、どう設計するかを考えるのです。 （p.48 ケブリン・ヘニー）
どっちにしょう？ って思ったら、その決定にロバストな解決策を考えてみるということです。もちらん、常にそんなアプローチがとれるわけじゃないですけどね。基本的な姿勢として、です。
というわけで、いろんな人のプラクティスや考え方に触れられて、役に立ちそうな本でした。
