読書メモ: 「ソフトウェアアーキテクチャの基礎」 第2章
2章 アーキテクチャ思考
アーキテクトらしく考えることには主に４つの側面がある。
- アーキテクチャと設計
- アーキテクチャを機能させるために、開発チームとどう協働するかわかる
- 技術の幅
- ある程度の技術的な深さを維持しながらも、他の人には見えないソリューションや可能性を見出せる
- トレードオフを分析する
- ソリューションと技術のとさまざまなソリューションと技術の間にあるトレードオフを理解し、分析し、調整できる
- ビジネスドライバーを理解する
- ビジネスを伸ばすために乗り越えなければならない要素の重要性を理解し、それがどのようにアーキテクチャの関心ごとに反映されるかを理解している
1. アーキテクチャと設計
アーキテクチャをうまく機能させるには、アーキテクトと開発者が強い双方向の関係を築く必要がある。アーキテクチャと設計に境界は存在せず、どちらもソフトウェアプロジェクトを構成するものであり、両者が常に同期していなければならない。
2. 技術的な幅
技術的な深さを持たなくてはならない開発者と異なり、アーキテクトには技術的な幅が求められる。「既知」「既知の未知」「未知の未知」のうち、「既知」の領域は維持しなければならない。一方で、「既知の未知」の領域を増やしていくことが、アーキテクトらしく考えるために重要である。
アンチパターン：氷漬け原始人アンチパターン
3. トレードオフを分析する
アーキテクトらしく考えるということは、技術的なものかどうかに関わらず、あらゆるソリューションのトレードオフを検討し、最善のソリューションを決定すること。アーキテクチャの決定には、常にトレードオフがある。
アーキテクチャとは、Googleで答えを見つけられないものだ
アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ
具体例として、オークションシステムを考える。
Pub/Subメッセージングモデルでトピックを使う方式とP2Pメッセージングモデルでキューを使う方式を比較する。
トピックを使う方式の利点は、Publisherが新しい情報を追加で配信したい場合に、トピックに新しい情報を追加するだけでよいこと。キュー方式の場合は、すべてのキューに対して新しい情報を追加しなければならない。また、PublisherはSubscriberがどんな情報を取得するか意識しなくて良く、分離されている。キュー方式では、配信する側が常に受け手側が何の情報を求めているかを把握しなくてはならない。
一方、トピック方式は誰でもトピックにアクセスできてしまうという問題がある。キュー方式の方がセキュリティが高く、盗聴が困難である。また、トピック方式は一斉に配信する性質上、余分なデータが増えてしまう。受け手側の特定の一つが取得したい情報が追加された場合、すべての受け手が影響を受けてしまう。他の受け手が不要な情報が追加されるため、データの量が増えることになる。キュー方式では、他の受け手が影響を受けることはない。また、トピック方式はメッセージ数をうまく監視することができない。
上記のように、どちらの方式で実装すべきかは場合によって異なり、トレードオフを分析した上で、モデルを決定することが必要である。
4. ビジネスドライバーを理解する
アーキテクトらしく考えるとは、システムの成功に必要なビジネスドライバーを理解し、それらの要件をアーキテクチャ特性へ変換すること。
そのためには、ビジネスドメインの知識やステークホルダーとの協力関係なども重要となる。
アーキテクティングとコーディングのバランスを取る
アーキテクティングとコーディングのバランスをとるには、ボトルネックの罠（アーキテクトがプロジェクトのクリティカルパスになるコード、例えばフレームワークの基礎となる部分の所有権を握ってしまい、チームのボトルネックになる）を避ける必要がある。
有能なアーキテクトは、クリティカルパスになるコードは他のメンバーに任せ、小さなイテレーションで実現できる機能の開発を行う。これには以下の3つのメリットがある。
- チームのボトルネックにならずに、製品のコードを書く経験を積める
- クリティカルパスとなる部分がチームに分散されることで、開発チームにオーナーシップを持ってもらうとともに、システムの難しい部分への理解を深めてもらえる
- アーキテクトが開発チームと一緒にビジネス関連のコードを書くため、プロセスや手順、開発環境に関してチームが直面している課題をより理解できるようになる
一方で、アーキテクトが開発チームと一緒にコードを書けない場合もある。その場合は、以下のような基本的な方法がある。
1. 概念実証（PoC）を頻繁に行う
概念実証をする際には、できる限りプロダクションレベルの品質のコードを書くべき。アーキテクトの使い捨てのコードが他の人にとってサンプル実装になってしまうのを防ぐため。また、アーキテクト自身が構造化された質の高いコードを書く練習ができるため。
2. 技術的負債やアーキテクチャに関わるストーリーを引き受ける
開発チームが重要で機能的なユーザーストーリーに取り組めるようにするため。また、技術的負債などは通常優先度が低く、アーキテクトが時間内に完成できなくてもいてレーションの成功に影響を与えない。
3. イテレーション内でバグ修正に取り組む
開発チームを助けながらコーディングを続けることができるし、アーキテクチャのどこに問題や弱点があるかを特定できる。
4. 開発チームの日常業務をツールやアナライザで自動化する
コーディングを続けながら、開発チームをより効率的にすることができる。
5. まめにコードレビューをする
書きはしないものの最低限コードに関与しつつ、アーキテクチャへの準拠を確認したり、チーム内でのメンタリングやコーチングの機会を得られる。
Discussion