🧊

ソフトウェアアーキテクチャの基礎 読んだ

O'Reilly Japan - ソフトウェアアーキテクチャの基礎

分厚かった。

TL;DRとしては、

  • アーキテクトかくあるべしについて書かれた本
  • 実践的というよりかは、汎用的な話が広範囲で書かれてる感じ
  • 基礎って書いてるけど、いわゆる駆け出しエンジニア向けではない

って感じ。

一エンジニアがコード書きながら「ここのコードどうまとめよかっな〜」とか「あのフレームワークかな〜」っていうレベルというより、もっと上位のレイヤーで「サービス全体のアーキテクチャが〜」とか「構成として冗長性が〜」みたいな話。そもそもコードを書く開発者と、この本の対象であるアーキテクトは別の位置づけだったりする。

3部構成

  • はじめに
  • 第1部: 基礎
    • アーキテクトとは、その役割はどうあるべきか
    • アーキテクチャとは
    • どういう事柄に注意を払うべきか
  • 第2部: アーキテクチャスタイル
    • イベントベースとかマイクロサービスとか、具体的な設計方法について
    • （たぶんこの本のメイン）
  • 第3部: テクニックとソフトスキル
    • 第1部を実践するための方法について
    • エンジニアとどう接するべきかとか

という構成になってて、個人的には序章とか第1部が一番良かったかなという感じ。
実際にアーキテクトとして働いてるわけではないので、ざっくりとしたガイドラインやら前フリにあたる部分のほうが、読み物として丁度いいというか。

以下、特に気になった章だけまとめ。

1章 イントロダクション

2章: アーキテクチャ思考

  • アーキテクチャを決めるのがアーキテクト
  • その決定を元に設計を行いコードを書くのが開発者
  • この責任の異なる2者のコラボレーションが重要だという話
  • アーキテクトは技術的な幅が優先される
    • 一般的には、深さよりも幅
    • 開発者は、幅よりも深さが要求されがち
  • ただし一定の深さも必要
    • チームに溶け込んで、自らもコードを書くべき
  • 未知の未知を、未知の既知にどう変えていくか

9章: 基礎

23章: 交渉とリーダーシップのスキル

  • アーキテクトの決定に対する異議をどうコントロールするか
  • いわゆる交渉術
    • コストの話は最後の手段
    • 人によって声のかけ方を変える
  • プログラマティックでありつつ、ビジョナリーでもあるべき
  • チームに溶け込みリーダーシップを発揮する

まとめ

ソフトウェアアーキテクチャはトレードオフがすべてだ

これに尽きる。額にいれて飾りたい。

ちょっとした設計をするときとかでも、正解を求めすぎる気持ちはわからないでもない。けど結局そこに正解はなく、トレードオフがあるだけなので、淡々と取捨選択して残ったやつを拾い上げれば良いんやなと。ただ取捨選択できるだけの手札は揃えておく必要があって、選球眼も養っておかないといけない。

そんなこんなあれこれ調べてると、Microsoftが出してるAzureのドキュメントサイトが圧倒的知見の塊で、いろいろよかった。

Azure アプリケーション アーキテクチャの基礎 - Azure Architecture Center | Microsoft Docs