2010年に出版された『Just Enough Software Architecture』
(georgefairbanks.com)- George Fairbanksの Just Enough Software Architecture は、言語文法やUMLの知識だけでは優れたオブジェクト指向システムやアーキテクチャを設計するのは難しいという問題意識から出発している
- 核心は リスク駆動アーキテクティング で、リスクが小さいときは過剰な設計を避け、成功を脅かすリスクにはより厳密な手法を適用する
- アーキテクチャを一部の専門家だけの専有物ではなく、すべての開発者が理解すべき能力 として扱い、制約や小さな変更がシステム特性に与える影響を説明する
- 開発プロセスや組織運営よりも エンジニアリング手法 に集中し、モデリングとアーキテクチャ分析によって中〜大規模の問題における設計トレードオフを扱えるようにする
- 構成はリスク駆動ソフトウェアアーキテクチャとアーキテクチャモデリングの2部で、ドメインモデル・設計モデル・コードモデル、カプセル化、コンポーネントとコネクタといった抽象化を扱う
言語・UMLの知識だけでは足りない設計力
- 著者は、ソフトウェア開発を始めたときに自分に必要だった本を作るという問題意識から出発している
- 当時はプログラミング言語やオブジェクト指向プログラミングの本はあったが、設計 を扱う本は少なかった
- C++の言語機能を知っているだけでは優れたオブジェクト指向システムを設計できず、UMLを知っているだけでは優れたシステムアーキテクチャを設計することもできない
リスクに応じて調整するアーキテクティング
- 本書の核心は risk-driven architecting である
- リスクが小さいときには細かな設計は必要なく、成功を脅かすリスクがあるときには粗い設計では不十分である
- 多くのAgile支持者は一部の先行設計が役立つ可能性を認めており、本書は「十分なだけのアーキテクチャ」をどう実践するかを扱う
- 「one size fits all」型のプロセスを避け、直面しているリスクに応じてアーキテクチャと設計の労力を調整するよう導く
- ほとんどの手法は quick-and-dirty なレベルから非常に厳密なレベルまで強度を調整できる
アーキテクチャをすべての開発者の言葉にする
- 本書はアーキテクチャを 民主化 することを目標としている
- 組織にソフトウェアアーキテクトがいる場合もあれば、読者自身がアーキテクトである場合もある
- 多くのアーキテクトは、すべての開発者にアーキテクチャを理解してほしいと考えている
- 開発者が制約の理由や小さな変更がシステム特性に与える影響を理解していなければ、設計判断が揺らぐ可能性がある
- アーキテクチャはアーキテクトだけのテーマではなく、すべてのソフトウェア開発者に関係するテーマである
手続き的知識と宣言的知識
- 本書は 宣言的知識 を育てることに焦点を当てている
- テニスボールを打てる能力と、なぜ打てるのかを理解していることは別であり、これは手続き的知識と宣言的知識の違いに当たる
- すでにシステムを設計・構築する専門家であれば、本書のさまざまな手法をすでに使ってきた可能性がある
- 本書は、これまで行ってきたことをよりよく認識させ、概念に名前を与えてくれる
- こうした宣言的知識は、初心者の開発者をメンタリングする能力を高めるのに役立つ
プロセスよりエンジニアリングに集中
- ソフトウェアシステムを設計・構築する人は、スケジュール、リソースの確約、ステークホルダー要求など、さまざまな問題を同時に扱わなければならない
- 多くのソフトウェアアーキテクチャ本は、開発プロセスや組織構造をすでに扱っている
- 本書はそれとは異なり、ソフトウェア開発の 技術的側面 と、システムを動作させるためのエンジニアリングに集中している
- モデルを作り、アーキテクチャを分析することで、原則に基づいた設計トレードオフを行えるようにする
- 中〜大規模の問題を推論するために使われる手法を説明し、専門的な手法をさらに詳しく学べる場所も示している
複数の抽象化レベルを行き来する実践的設計
- 本書はアーキテクチャを実践的な設計活動として扱う
- ソフトウェアアーキテクチャはソフトウェア設計の一種であり、設計判断はアーキテクチャに影響を与え、アーキテクチャも設計に影響を与える
- 優れた開発者は障害物を詳細に掘り下げて理解したうえで、その障害物の性質を全体アーキテクチャと結び付ける
- こうした drill-down/pop-up 的な振る舞いを反映し、アーキテクチャからデータ構造設計まで、複数の抽象化レベルのモデルを扱う
構成と提供形式
- 本書は2部構成である
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- 一部のサンプル章は1つのPDFとしてダウンロードできる
- 電子書籍は Google Play で販売されており、DRMなしのePub、Mobi、PDFの3形式が含まれ、価格は $9.99 である
- ハードカバーは Amazon で提供されている
- Google Books と Amazon Search Inside は全文検索可能な版を提供している
扱う範囲と扱わない範囲
- 本書はソフトウェア構築に関わる ソフトウェアアーキテクチャ に集中している
- ソフトウェアがエンジニアリング要件を満たすようにする手法を説明している
- エンジニアリング手法自体が概してプロセスに依存しないため、本書も大部分はプロセスに縛られない
- 次のような管理活動に関する助言は扱わない
- アーキテクトの政治的責任
- 特定の種類の会議をいつ開くべきか
- ステークホルダーから要件を収集する方法
Part I: リスク駆動ソフトウェアアーキテクチャ
- ソフトウェアアーキテクチャを正確に定義するのは難しいが、いくつかの性質は明確である
- ソフトウェア開発者は、他の工学分野のエンジニアのように 抽象化とモデル を使って大きく複雑な問題を解く
- ソフトウェアアーキテクチャはシステムの骨格のように機能し、品質特性に影響を与え、機能とは直交し、制約を通じてシステム特性に影響を与える
- アーキテクチャは次のような状況で特に重要である
- 解空間が小さいとき
- 失敗リスクが高いとき
- 難しい品質特性要求に直面するとき
- 設計方式は architecture-indifferent design、architecture-focused design、architecture hoisting の中から選択できる
- リスク駆動モデルの中核手順は単純である
- リスクを識別し、優先順位を付ける
- 手法の集合を選んで適用する
- リスク低減を評価する
- 第4章では Home Media Player システムの例を使って、リスク駆動モデルの適用を示す
- チームコミュニケーション
- COTSコンポーネント統合
- メタデータの一貫性保証
- Part Iは、モデルとソフトウェアアーキテクチャの活用に関する助言で締めくくられる
- 問題解決にモデルを使う
- 制約を慎重に追加する
- リスクに集中する
- アーキテクチャ能力をチーム全体に分散させる
Part II: アーキテクチャモデリング
- Part IIは、ソフトウェアアーキテクチャの 概念モデル を形成するのを助けることに焦点を当てている
- 基本となるモデル構造は3つある
- ドメインモデル: 現実世界の事物に対応する
- 設計モデル: 構築中のソフトウェアの設計を表す
- コードモデル: ソースコードに対応する
- 選択した詳細を示す追加モデルである ビュー(view) を作ることができ、これらのビューは viewtype としてまとめられる
- カプセル化境界を作ることは、ソフトウェアアーキテクチャにおける重要な技術である
- コンポーネントやモジュールの利用者は、内部動作を無視して別の難しい問題に集中できる
- カプセル化されたコンポーネントやモジュールの作成者は、利用者を動揺させることなく実装を変更する自由を得る
- この自由はカプセル化が有効に機能するときにのみ可能であるため、本書はそれを保証する手法を扱う
- 複数の出典に由来するソフトウェアアーキテクチャ手法を統合している
- 品質特性を強調する手法
- 機能を強調する手法
- 効果的なモデルを作るための実践的方法
- モデルをデバッグする方法
- Part IIは、モデルを効果的に使うための助言とともに、その技術で直面しうる 落とし穴 も扱う
- 最後の目標は、抽象化と関係について豊かな概念モデルを備え、コーチが試合を見るようにソフトウェアシステムを見られるようになることである
1件のコメント
Hacker Newsの意見
プロジェクト管理上のリスクが「主要開発者がバスにひかれる」で、ソフトウェア工学上のリスクが「サーバーがユーザー1000人までスケールしないかもしれない」なら、両者は区別すべきだという話があるが、私の経験ではそこまできれいに分離されることは少ない。
コード品質と構造、テストとドキュメント、標準的でよく知られたツールの利用は、どちらにも役立つ。
だから同僚や上司に「バスにひかれたら？」という仮定を何度も持ち出してきたし、それは再現可能で理解しやすいソフトウェアを作るための圧力装置になった。
けがや死の否定的なニュアンスを避けるなら、「宝くじに当たったら？」を使うのがよい。
「バスにひかれる」の要点は、性格に関係なく準備する時間がまったくないことにあり、だからこそ情報を今日共有しなければならないという圧力が生まれる。
残念ながら、同じ含意を持つポジティブな表現はまだ見つけられていない。
どちらも1週間ほど後に復帰したので、別の標準的な災害例が必要になった。
要点を伝えるときは「次の人」という表現をよりよく使う。
さらに悪い状況はバーンアウトで、人数はそのままだが、精神的にはすでに離れている状態になる。
恒久的な退職ではなく、その程度にも耐えられない会社をたくさん見てきた。
あるいは「バス係数を上げる」のように、単一障害点をなくすという動機に焦点を当てる表現もあり得る。
根本原因分析をするなら、「Larryがバスにひかれたから／宝くじに当たったから」で止まってはいけないし、それは本当の問題ではない。
アーキテクチャのためのアーキテクチャは、不必要に複雑さを増やすので最悪だ。
よいアーキテクチャの究極の目的はコスト削減だ。
アーキテクチャのせいでコードの開発や保守により時間がかかるなら、そのアーキテクチャは失敗している。
常にバランスを取る問題だ。
したがって唯一の正解となるアーキテクチャはなく、選択は状況によって変わり、時には再評価が必要になる。
柔軟性は、変化する状況の中でもアーキテクチャをある程度調整し、効率を保てるようにするため、特に有用だ。
コスト削減はその一つであり得る。
「リスク駆動モデルは、開発者が最も差し迫ったリスクを減らすために、最小限のアーキテクチャ技法を適用するよう促すものだ。『自分のリスクは何か？ それを減らす最善の技法は何か？ リスクは緩和され、今コーディングを開始または再開できるのか？』と粘り強く問い続けるプロセスである。リスク駆動モデルは3段階に要約できる：1. リスクを特定し優先順位を付ける 2. 技法の束を選んで適用する 3. リスク低減を評価する」
影響の小さい技法に時間を無駄にしたくもないし、プロジェクトを脅かすリスクを無視したくもない。
成功するシステムを作るには、時間を最も効果的に使う道を選ぶ必要があり、それはリスクが動機になるときにだけアーキテクチャや設計技法を適用してリスクに対処する、ということを意味する。
例えば「アーキテクチャ」には、サーバーが先に動かず、クライアントのリクエストに応答するだけのクライアント・サーバースタイルを使うことも含まれる。
この方式は問題に合うこともあれば、合わないこともある。
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
高給取りのテクニカルアーキテクトたちが大したことはせず、締め切りのような不合理な制約の中でソフトウェアエンジニアが解決しなければならないひどいパターンを押しつけることになる。
よいアーキテクチャは、より多くの人がプロダクトに参加できるようにしてくれる。
2010年に出版されたのなら、その後どれだけ生き残っているのか気になる
“Design It” は、ステークホルダーや顧客とやり取りする必要がある技術者向けに、良いワークショップやアクティビティがあって気に入っている
コンサルティングの役割なのでより関係が深いし、頻繁に変わる特定の技術アーキテクチャスタイルに過度に依存しない点も良い
流行ではなく、実際の原則を基準に言っている
著者はマインドセットについてのエッセイに多くの時間を割き、具体的な技術は軽く扱うが、さらに読むための資料は提示している
チームが具体的なアクティビティを通じてアーキテクチャのアイデアを扱えるようにし、最終的に何が重要なのかを浮かび上がらせてくれる
私の本はそうした大きなアイデアに正面から取り組もうとしたが、テーマがあまりに抽象的なので教育的には難しいことが明らかになった
2010年以降、どのアイデアが生き残ったのか？ あるOSはマイクロカーネルで、あるOSはモノリシックである
あるデータベースはリレーショナルで、あるものはドキュメント中心である
あるアプリケーションはクライアントサーバーで、あるものはピアツーピアである
こうした区別はおそらく永続的であり、100年後に戻ってきても Windows、Oracle、Salesforce のような例は消えていたとしても、そうした設計を持つシステムは見られるはずだ
そして変更容易性やレイテンシのような品質についても、なお語っているはずだ
ソフトウェアアーキテクチャの分野とは、こうした永続的な抽象化を識別する仕事である
[2] に簡潔な説明がある
“概要: ソフトウェアアーキテクチャは、これから作る予定の、あるいはすでに作ったソフトウェアについて推論する助けとなる抽象化の集合である。私たちの分野には昔から小さな抽象化は存在していたが、品質属性、情報隠蔽、コンポーネントとコネクタ、複数のビュー、アーキテクチャスタイルのような、より大きな抽象化が蓄積されるまでには数十年を要した。システムを設計するとき、私たちはこうした抽象化をつなぎ合わせて意図性の連鎖を保ち、設計したシステムに望むことをさせる。20年前、この雑誌で Martin Fowler が影響力のある記事 ‘Who Needs an Architect?’ を発表した。今こそ開発者はソフトウェアアーキテクチャを見直し、ソフトウェアについて推論できるようにする抽象化の集合として捉えるべき時だ”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
John Ousterhout の A Philosophy of Software Design は役に立った
理解しやすい堅実な助言が多く、例も多い
この本自体は知らないが、著者が書いた Intellectual Control 関連の記事は知っていて、非常に洞察に富んでいる
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
以前の会社で Simon Brown の Software Architecture for Developers という本が回覧されていた: https://leanpub.com/b/software-architecture
まだ読むリストに入ったままで、その会社からは移ったが、強く勧められた
その会社は C4 モデルでもアーキテクチャを文書化していた
ここで読んだことがある人がいるのか気になる
彼のアーキテクチャ講演 [1] とワークショップは特に効果的で、C4 アーキテクチャモデリング言語 [2] も実際に勢いを得ている
私の YouTube 動画もあるが [3]、それほど効果的ではない
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
この方法論には「リスク依存」という名前のほうがずっと良かった気がする
プログラマーはなぜそんなに「[X]駆動」という表現が好きなのだろうか？
この軸があの歯車を駆動し、その歯車が車輪を駆動する、という具合だ
「この複雑な思考機械の中で最も強力なメカニズムは何か」を短く言った表現である
数年前、会社でこの本を使って読書会をしたが、非常に反復的だと感じた
些細ではないオープンソースプロジェクトを始める人にとって、この本が良い資料なのか気になる
あるいは1人創業者にとって得る価値があるのか、ソロ開発者に役立つ本や他の資料を勧めてほしい
ソフトウェアアーキテクチャは一般の建築と似ているが、ソフトウェアにはまだ Isaac Newton のような人物がいないため、土木工学が存在しない状態のように思える。
これまでで最も近い人物は Claude Shannon だと思う。
測定単位すらないからだ。
私たちはまだソフトウェア工学において「崩れないことを願う」段階にいる。
これは自己申告の生産性に深く影響する。
たとえば、窓を上げたまま時速30マイルで、一時停止標識の多い小さな郊外の道を運転するより、自転車のほうが速く感じられるかもしれない。
しかし普通は、運転者のほうが20ブロック先にはるかに早く到着する。
測定単位がなければ、誰もが自転車のほうが速いと言い争っているだろう。
ソフトウェア工学はいま、そういう状態にある。
ソフトウェアを作ることは、橋や高層ビルを建てることとはまったく同じではなく、むしろそれらを設計することに近い。
大規模な建築プロジェクトでは、まず設計し、その後に建てるが、この設計は膨大な作業だ。
あらゆることを考え、シミュレーションを回し、ステークホルダーと協議し、要件と制約を把握し、材料費や重量などを考慮しなければならない。
大型建設プロジェクトでは、実際に設計を作るだけで数か月、あるいは数年が消えることもあり、成果物は建設のほぼすべての側面を網羅する非常に詳細な設計図になる。
実のところ、これはソフトウェア作りとかなり似ている。
こうした設計プロジェクトには高い不確実性とリスクがある。
それでも、多くの人員やコンクリート、鉄鋼のような高価なリソースを使い始める前に、すべてが間違っていたと分かるほうがよい。
しかし、建築家がそれを緩和するために設計のための設計を作ると言うのを聞いたことがあるだろうか。そんなものはない。
せいぜい、どこかの時点でスケッチやナプキンの絵があったかもしれない、という程度だ。
SpaceX は工学にアジャイルの要素を一部取り入れたが、これはソフトウェア開発から学んだものだ。
ソフトウェアでは、完成した設計図が実行可能である。
設計図を作る過程は手作業だが、その設計図からソフトウェアを作る過程は通常、コンパイラや他のツールによって自動化されていて非常に安価なので、開発者は常にそれを行っている。
もちろん、昔から常にそうだったわけではない。
実行可能な設計図を作る過程には当然多くのリスクがあり、各所にナプキンやホワイトボードでの設計が存在し得る。
しかし、まず完全な設計を行い、その後に完全な実装を行うという概念、つまりウォーターフォール方式は、ソフトウェアでもうまく機能したことはない。
いくつかの例外を除けば、通常、設計図のための設計図はない。
Royce のウォーターフォールに関する元論文を読むと、実際にはウォーターフォールという言葉はまったく出てこず、反復が良い考えかもしれないとおぼろげに示唆している。
少なくとも一度以上はやってみろ、という感じだ。
彼は最初の設計が間違っている可能性が高いことを完全に理解していた。
アジャイルは、反復を多く行うと明らかになる、設計図のための設計を作るという価値の低いステップを最適化して取り除いたものだ。
ただし特定の領域の外では、私たちが概して無視しているだけだ。
たとえばこの要約と目次をざっと見ると、性能指標への言及はほとんどないか、まったくないように見える。
コンピュータが実際に何をしているのかを考慮しないなら、アーキテクチャに何の意味があるのか。
開発生産性やユーザーインターフェイスの面でも、ソフトウェアを開発し、変更し、拡張し、さらに重要なことに利用するために必要なメンタルスタックを説明する数学的モデルがなぜないのだろうか。
人間であれ機械であれ、計算資源は開発者やユーザーとしてソフトウェアと相互作用するうえで現実的かつ測定可能な影響を及ぼすのに、なぜめったに考慮されないのだろうか。
たとえば Westminster Palace には確かに土木工学的な要素があるが、華やかな質感、象徴的な時計塔、内部配置といった決定的な特徴の多くは、機能的・美学的な選択に左右される。
ソフトウェアの多くの部分も同じだ。