ソフトウェア アーキテクチャ基礎 輪読会資料 第2章 アーキテクチャ思考
?
1 like?7,644 views
ソフトウェアアーキテクチャの基礎 （オライリー?ジャパン、Mark Richards/Neal Ford著 島田 浩二訳) の社内輪読会の発表資料
ソフトウェア アーキテクチャ基礎 輪読会資料 第2章 アーキテクチャ思考
- 7. 2.2 技術的な幅 知識には2段階ある ● わかっていること ● わかっていないとわかっていること （その下に、「わかっていないとわかっていないこと」の深い海が続いて 3段階となる）
- 8. 2.2 技術的な幅 ● 「わかっていること」をより深めて維持していくのが 開発者のスキル ● 「わかっていないとわかっていること」を広めていき その上で何かしらの専門性について深さも維持していくのがアー キテクトのスキル
- 9. 2.2 技術的な幅 開発者からアーキテクトにクラスチェンジするときにこの思考の転換に 失敗するとどうなるか ● どっちつかずになって死ぬ ● 古い専門知識とか偏った経験知に引っ張られてチームに理不尽を 押し付けてしまう（“氷漬け原始人アンチパターン”） では、「広さ」の追求がどうして必要なの？ というのが次の節とその次 の節
- 10. 2.3 トレードオフを分析する ● 第1章でやったあれ ○ ソフトウェアアーキテクチャはトレードオフがすべてだ ○ アーキテクトが、トレードオフではない何かを見出したと考えているなら、まだ トレードオフを特定していないだけである可能性が高い どんな方式にもメリットとデメリットがあるはずよねということ
- 11. 2.3 トレードオフを分析する 例に挙げられているオークション入札システムでは 入札イベントをいろんなサブシステムに食わせる。 そのときキューイングをどう設計するか？ ● トピック（pub/sub）に入れて各サブシステムがsubする？ ● 各サブシステムがキューを持ってイベントは各キューに入れる？
- 12. 2.3 トレードオフを分析する トピック（pub/sub）でやるメリットは ● 利用側サブシステムの追加が容易 ● 疎結合性 これなら当然、 トピック方式が良いに決まってますよね！？
- 13. 2.3 トレードオフを分析する 待って、デメリット、あるんじゃないの？ ● 投げっぱなしなので、悪意あるサブスクライバがsubしていてもまっ たくわからない ● イベントのデータ構造が固定されるので、追加情報がほしいみた いな要件には対応不可能 ● サブスクライバ側の処理遅滞が見えないから、詰まり対応がイベ ント生成側では原理的に不可能
- 15. 2.4 ビジネスドライバーを理解する ビジネスドライバー = ビジネス的な開発動機、何が大事か それを、アーキテクトがシステム開発の言葉に翻訳する。 スケーラビリティ、パフォーマンス、可用性? つまりアーキテクチャ特性 それが「場合」だ！ 事業ドメイン知識を持つ必要があるのも政治を理解する必要があるの も、まさにこの判断をするためである。
- 19. 2.5 アーキテクティングとコーディングのバランスを取る ほかには、開発者感覚を持ち続ける方法として4つ挙げておくと ● 概念実証（Proof-of-Concepts: PoC）コードを書く。それも書き捨てではなくプロダクト品 質のコードを。（その心は：サンプルコードが結局本番に投入されがち＋みんなのお手本 になりがち） ● 技術的負債の解消やアーキテクチャ改善のための裏方のコーディングを担当する。（そ の心は：終わらなくてもイテレーション失敗に直接つながらない） ● バグ修正を担当する。（その心は：開発上の問題点の把握にもなる） ● 自動化とかの環境整備をやる ● コードレビューをする 5つあるじゃん！！！
- 20. 第2章のまとめ アーキテクトは、 ● システムを構成する上での各方式のメリット?デメリットを把握して ● ビジネス上の動機から優先順位判断に落とし込めないといけない ● だから、深い専門性は持ちつつも専門外にもできるだけ幅広く「あれやこれがあ る。詳細は知らんけど」という知識を持っておく必要がある ● 専門性の維持のためにも開発者としての仕事も続けないといけない。でないと氷 漬け原人になる。 ● 開発だけに専念できない立場なりのコーディングへの関わり方がある