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

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

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

ブログを巡回して読んでいる気分。ぐっと来るエントリもあったが、
やはり系統だった知識があった上で(あるいは経験があった上で)読むものかなという印象です。
そういう意味では読む順序を間違えた気がしました。

  • 設計の判断
    • 設計の判断としてどちらを選んでも良さそうな感じがするときは、一歩下がって考える。
      • A.Bのどちらを選んでも、それほど重大な意味を持たないようにするために、どう設計するかを考える。
      • 二者択一に踏み込む前に。
      • 最終的に設計の判断によって左右されるのは避けられないとしても、その影響を小さくするためには、どのような分割やカプセル化をすればよいかを考えましょう。
  • ソフトウェアアーキテクチャの倫理的な意味
    • あなたが(設計開発時に)楽をするために、ごくわずかであっても、他人の生活を不便にすることは倫理的ではありません。その判断はあなたの都合をユーザに押しつけることになります。
  • データが全て
    • 一歩下がって考えてみると、コンピュータとは、データの塊にアクセスし、それを操作するためのしゃれた道具にすぎません。
    • 数百万個の命令はいかにも複雑ですが、その下にあるのは、ごく少数の基本データ構造であり、それなら私たちの頭も簡単についていけます。
  • アーキテクトはまずデベロッパーであれ。
    • 法律家だったことの無い判事、外科医だったことのない外科部長なんてものを聞いたことはありますか？
  • レガシーシステム
    • 全てのソフトウェアシステムがレガシーシステムと形容されるべきものです。
    • あなたのシステムが耐久性を持ち、顧客の期待を満足させ、ビジネス上の価値を提供しているということなのです。
    • レガシーと呼ばれたことのないシステムは、おそらく稼働に移される前に封印されたのです。それはアーキテクチャの成功とはとても言えないでしょう。
  • 解決策が一つしか思い付かないなら、何か問題がある。
    • 問題に対する手持ちの解決策が一つしか無い場合、トレードオフについてはもう交渉の余地が無いということです。
    • 本当に選択肢が一つしかない場合はまれです。おそらくアーキテクトがそのビジネスドメインでは経験不足なのでしょう。
    • 思い付かない場合は助けを求めた方が良いでしょう。
  • 怒れるアーキテクトとしてビジネスと対立するな。
    • ビジネスは私達の存在価値です。私達は彼らにサービスを提供するために生きているのであって、その逆では無い。
    • 耳に入ってきたビジネスの進め方の説明に対して、それは良くないと思う場合がたびたびあるでしょう。改善のヒントを言ってもかまいませんし是非言うべきです。
    • 会社の仕事のまずさを面白く嫌味な感じで話して人目を引こうとする不機嫌な天才を演じてはなりません。周囲の人は、あなたの言う通りだと思ったりはしないでしょう。彼らは以前にもそういう人間を見ており本当にうんざりしています。
    • 意見の不一致を受け入れて仕事を進めることを覚えましょう。
  • 勤勉さ
    • 有能なアーキテクトの多くは、知識としては知っているものの、習慣として実践できている訳では無いことを思い出すために、毎日、毎週のチェックリストを作り、それに従うようにしています。
    • 失敗したプロジェクトを振り返ると、失敗したのは能力がないからではなく、勤勉さと危機意識が欠けていたからだということが分かります。
  1. バリュープロポジションを明確にする。
    • アーキテクチャが必要とされる理由を経営者の視点からまとめる。既存のその他の選択肢と比較。
    • 技術の観点でなく、ビジネスの生産性や効率を向上させる能力として。
  2. 数量化のための基準を確立する。
  3. 伝統的なビジネスの尺度とのリンクを作る。
    • 金額、企業財務的な数字
  4. 止まるべき場所を知る。
    • 一つ一つのマイルストーンをビジネス上の価値に直接結びつけ、ビジョンが見えるロードマップを準備する。
  5. 適切なタイミングを探す。
    • だめなときはだめ。売り込みのタイミングも重要。
  • 未来永劫安泰なソリューションは無い。
    • 今の時点でよいテクノロジーを選ぶのでも十分難しいのです。
    • 未来においても良いものを選ぼうとしても無駄です。
    • 技術市場が今提供してくれるものを見ましょう。
    • 今のニーズにもっともあうものを選びましょう。
    • それ以外のものは、未来の選択肢として誤っているだけでなく、今の選択としても間違っています。
  • 要求
    • システム要求は、ビジネス要求から派生します。
      • 単純にシステム自体が理由となっている場合を除く。
      • 例えば単なるシステム都合のリプレースであっても、TCOの削減を行いたいというビジネス要求が背後にあるかもしれません。
    • 要求をきちんと整理しましょう。
  • 要求分析
    • 要求分析を厳密に行っても、曖昧性の排除や抜けを無くすことは無理。
    • ではどうするか。
    • クライアントが関わりたい利用者を想定し、その目的と振舞を仮定し、検証を繰り返す。