読書記録です。「ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス」をななめ読みして、そのメモ。
O'Reilly Japan - ソフトウェアアーキテクチャメトリクス
4つのキーメトリクス（デプロイの頻度、変更のリードタイム、変更時の障害率、サービス復旧時間）によって学習が促進され、品質、疎結合性、デプロイ可能性、テスト容易性、可観測性、保守性を持ったアーキテクチャが必要であることをチームが理解できるようになる
キーフレーズと感想 (目次順)
１章 解き放たれた４つのキーメトリクス
- 4つのキーメトリクス（デプロイの頻度、変更のリードタイム、変更時の障害率、サービス復旧時間）によって学習が促進され、品質、疎結合性、デプロイ可能性、テスト容易性、可観測性、保守性を持ったアーキテクチャが必要であることをチームが理解できるようになる
- https://bliki-ja.github.io/TeamTopologies
- 「よりテスト容易性があり、より疎結合で、より耐障害性が高く、クラウドネイティブで、実行性があり、可観測性を持つアーキテクチャ」に向かって、徐々に舵を手放しつつ、成熟しつつあるチームに委ねながら、ゆっくりと進んでいく
２章 適応度関数テストピラミッド：アーキテクチャテストとメトリクスのためのアナロジー
- https://principlesofchaos.org
- 場当たり的にしかシステムをテストしていないと、パフォーマンス、セキュリティ、修正性のような関連領域全般にわたる品質を維持するのは難しい。それを防ぐには、比較的容易に構築でき、必要に応じて開発や拡張が可能な、堅実なアーキテクチャテストの基盤から始める。システムに合ったメトリクスを適応度関数を用いて作成すれば、要求に合わせてソフトウェアシステムを変えていける。
３章 進化的アーキテクチャ：テスト容易性とデプロイ可能性でアーキテクチャを導く
- 持続可能な変化
- モジュール性
- 独立して変更できる要素にシステムを分割すること。
- 凝集性
- 同時に変更するコードをまとめておくこと。
- 関心事の分離
- 一つの問題を解決する要素単位に、コードやシステムを分割すること。
- 抽象化・情報隠蔽}
- システムに「継ぎ目」を作ることで、詳細を知ることなく機能を利用できるようにすること。
- 結合度
- システム要素間における同時に変更する必要がある度合い。
- モジュール性
- 開発者がソフトウェアアーキテクチャについて考えるときには、セキュリティ、スケーラビリティ、レジリエンスといった、システムの何かしら重要な特性について考えがちであるが、これらの特性がそれぞれどの程度重要であるかは、システムとその開発者が目的としているビジネスと、システム全体の成熟度に応じて決定される。
４章 モジュール性成熟度指数でアーキテクチャを改善する
- モジュール性成熟度指数（Modularity Maturity Index：MMI）
- 『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』 - snoozer05's blog
５章 プライベートビルドとメトリクス：ＤｅｖＯｐｓ移行を乗り越えるためのツール
- 「継続的インテグレーションは、チームのメンバーが頻繁に作業を統合するソフトウェア開発プラクティスです。このプラクティスでは通常、各人が1日に少なくとも1回以上の統合を行います。各インテグレーションは、自動ビルド（テストを含む）によって検証され、統合エラーを可能な限り迅速に検出します」
- https://martinfowler.com/bliki/ContinuousDelivery.html
- 「オーナーシップシフト」
- DevOpsという用語が、もはや文化を指す用語ではなく「モダンなシステム管理者」というような意味で使われ自動化の構築と保守を指す。そうすると、「DevOps」という言葉は、多くの場合、独自のチケットワークフローを持つよう組織化された自動化チームの名称になってしまう。開発チームは、どこでどのようにデプロイが行われるかをほとんど知らないままとなる。自動化ワークフローから切り離されている一方で、検証は開発チームへと委ねられる。QA チームも別行動となるとサイロが復活し、ローカル開発環境と本番環境との「環境の不一致」が再来してしまう。
６章 組織のスケーリング：ソフトウェアアーキテクチャの中心的役割
- メトリクスの傾向は非常に重要であり、技術的な状況を超えたシグナルを明らかにできる。
７章 ソフトウェアアーキテクチャにおける計測の役割
- システムの品質特性を計測することで、アーキテクチャ作業が効果的であるかどうかを判断できる。
- 計測によって、アーキテクチャの中でもっと注意を向けるべき場所を理解できる。
- 作業の優先順位付けや、異なる種類のアーキテクチャ作業の間で難しくても合理的な選択をするのにも役立つ。
- 品質特性を計測可能にする方法を見つけ、要求事項を具体化することを強制する（この具体性は、品質特性の要件を作成し、ステークホルダーとのコミュニケーションを向上させるのに役立つ）。
８章 メトリクスからエンジニアリングへの進化
- アーキテクチャ適応度関数
９章 ソフトウェアメトリクスを使用して保守性を確保する
- メトリクスの最も良い活かし方は、メトリクスベースのフィードバックループを運用すること
- メトリクスは有害な傾向を早期に発見し、ソフトウェアプロジェクトが巨大な泥団子にならないことを保証する
１０章 ゴール・クエスチョン・メトリクスアプローチで未知数を計測する
- ゴール・クエスチョン・メトリクスアプローチ
- GQMアプローチはソフトウェア開発における困難な問題をどのように計測し評価するかをチームで考えるのに役立つ
他 参考
『ソフトウェアアーキテクチャメトリクス』LTに参加してみた🌟
「ソフトウェアアーキテクチャメトリクス」を読んだ感想 #読書感想文 - Qiita
以上です～