【読書メモ】Fundamentals of Software Architecture ~第二章 Architectural thinking~
雲を見る時、気象学者の視点と、芸術家の視点では見ているものが異なるはず。
本書では、アーキテクトの視点でアーキテクチャを見ることを、Architectural thinking(アーキテクチャ的思考)と呼んでいます。
重要なポイントは、Architectural thinkingは、単にアーキテクチャについて考えることではないということ。
アーキテクチャ的思考には以下の4つの側面があると述べられています。
- アーキテクチャと設計の違いを理解し、アーキテクチャを機能させるためにチームとどのように協力していく方法を知る事。
- 幅広い技術的知識を持ちながらも、一定レベルの技術的な深さを維持し、他の人には見えない解決策や可能性を見出す事。
- 様々なソリューションと技術の間のトレードオフを理解し、分析し、調整する事。
- ビジネスドライバーの重要性を理解し、それがどのようにアーキテクトの懸念事項に反映されるかを理解する事。
<目次>
- Architecture Versus Design
- Technical Breadth
- Analyzing Trade-Offs
- Understanding Business Drivers
- Balancing Architecture and Hands-On Coding
- 英単語メモ
Architecture Versus Design
アーキテクトと開発者の役割の違い<Traditionalな分け方>
▼アーキテクトの範囲
- ビジネス要件を分析してアーキテクチャの特性（「能力」）を抽出・定義する
- 問題領域に適合するアーキテクチャのパターンやスタイルを選択する
- コンポーネント（システムの構成要素）を作成したりするコンポーネント（システムの構成要素）を作成したりする
▼開発者の範囲
この関係性の問題点は、アーキテクト -> 開発者 という一方方向な関係になっていること。
どうあるべきか、というのは以下の図のように示されています。
アーキテクトと開発者の垣根がないこと、そして共にイテレーションを回していくことがプロジェクト成功には重要とのこと。 つまり、どこからがアーキテクチャでどこからが設計か、という分け方ではないのだ、ということでしょう。
Technical Breadth
ここでは、アーキテクトが身に着けるべき技術的知識について書かれています。
まず、開発者とアーキテクトでは、求められる知識にどんな差があるのか。 それは、幅と深さである、と述べられてます。
書籍中では、以下のような図で説明されています。
技術的な深さは、「Stuff you know」(知っていること)を掘り下げていくこと。
技術的知識の幅とは、「Stuff you know you don't know」(知らないと知っていること)を増やしていくこと。
アーキテクチャ的な最適解を見つけるアーキテクトにとっては、
この技術的知識の幅をいかに広げていくか、が重要ということみたいです。
とはいえ技術的な深みや専門領域がなくてよい、という訳ではないのだと、
この後のセクションで触れられています。
Analyzing Trade-Offs
Architecture is the stuff you can’t Google.
Richards, Mark,Ford, Neal. Fundamentals of Software Architecture (Kindle の位置No.571-572). O'Reilly Media. Kindle 版.
この言葉の通り、アーキテクトが考えることは、トレードオフであり、
技術・ビジネス・組織の中で発生する要求や制約の中で、何を選択して何を選択しないか。
選択することによるメリットデメリット、選択しないことにより起きる条件制約。
置かれている状況の中でトレードオフを分析し、選択していくことがアーキテクトの考えで重要である、と述べられていました。
Understanding Business Drivers
アーキテクトの選択・決定はビジネス的要求とマッチしていることが重要、という話。 具体的にどう言った特性があり、どう考えればいいのかは、4〜6章の中で触れられているようです。
Balancing Architecture and Hands-On Coding
アーキテクトとしていかに、技術的深さやコーディングスキルを磨いていくか、という話。
三つの方法が紹介されています。
1. クリティカルパスや難しい箇所以外の開発に入る
この方法のいい所は、３つ
(1)アーキテクチャがプロダクトコードを書く機会を得られる
(2)開発チームがより難しい部分にフォーカスできる
(3)開発チームが感じている、プロセスや開発環境面での苦痛に気付ける
2. PoCの開発を担う
アーキテクトがPoCで開発を担うことで、
ドキュメント・構成管理・アーキテクチャなど、後の開発チームのガイドになるような土台を作れることがメリットの一つ。
アーキテクトにとっては、高品質で構造化された開発の腕を落とすことを防げるメリットがあるとのこと。
3. 技術的負債やバグ解決に関わる
コーディングスキルも磨きながら、コードベースやアーキテクチャの問題に気づくことができたり、
自動化やプロセス改善のきっかけにもなる。
また、コードレビューをすることで間接的にコーディングに関わることができ、
メンタリングやコーチングの機会も作ることができる。
第二章はここまで。
次回から、第三章に入ります。
英単語メモ
■quiver (verb)
def: to shake slightly; to make a slight movement
SYNONYM: tremble
■atrophy (noun)
def: (medical) the condition of losing fat, muscle, strength, etc. in a part of the body because it does not have enough blood
