Skip to content

Latest commit

 

History

History
115 lines (90 loc) · 7.38 KB

software_architecture_metrics.md

File metadata and controls

115 lines (90 loc) · 7.38 KB

links

この本を読む目的

  • 変化し続ける実アーキテクチャを、いかに観測可能・目標と比較可能にして、目標に近づける・目標から遠ざからないようにするか

1. 解き放たれた4つのキーメトリクス

  • 重要な目標アーキテクチャ:ソフトウェアデリバリー
  • とりあえずLeanとDevOpsの科学を読め
  • 4つのキーメトリクス
    • デプロイの頻度、変更のリードタイム、変更時の障害率、サービス復旧時間
  • 4つのキーメトリクスをリアルタイムで見えるようにすることで、チームメンバ間の会話が引き出され「よりテスト容易性があり、より粗結合で、より耐障害性が高く、クラウドネイティブで、実効性があり、可観測性を持つアーキテクチャ」に向かって自律的に動き出す

2.適応度関数テストピラミッド:アーキテクチャテストとメトリクスのためのアナロジー

  • 重要な目標アーキテクチャ:テスト容易性やデプロイ可能性

  • 適応度関数:「見込みのある設計ソリューションが、設定した目定期の達成にどれだけ近いかを要約するために使用する目的関数」

  • メトリクス:適応度関数の出力

  • 下記のような流れで適応度関数を定義し、アーキテクチャテストを実装していく

    • 1.最も重要な品質特性を特定し、目標を設定する
    • 2.適応度関数とメトリクスのドラフトを作る
    • 3.適応度関数の優先順位をつけて選択する
    • 4.選択した適応度関数を定義する
    • 5.メトリクスを生成する自動テストを開発する
    • 6.結果を視覚化する
    • 7.繰り返す

3.進化的アーキテクチャ:テスト容易性とデプロイ可能性でアーキテクチャを導く

  • 持続可能な変化を実現するためには、モジュール性、凝集性、関心ごとの分離、抽象化・情報隠蔽、結合度が大切
  • テストを容易にするコード特性も、上と同じ
  • つまり、テスト容易性を重視して設計することで、変更しやすくなる

4.モジュール性成熟度指数でアーキテクチャを改善する

  • MMI:モジュール性成熟度指数
  • MMIは、モジュール性・階層・パターンの一貫性についての評価から総合的に算出する数字

5.プライベートビルドとメトリクス:DevOps移行を乗り越えるためのツール

  • 重要な目標アーキテクチャ:ソフトウェア構築時のプロセス
  • アンチパターン
    • オーナーシップシフト
    • DevOpsチームにビルド、検証を委ねすぎる
  • プライベートビルドで検査の主戦場をローカル開発環境に移す
    • ここでいうローカルとは、各開発者が裁量を持つ環境のことで、別にクラウド上でも良い
  • メトリクス
    • フィードバックまでの時間
    • イテレーションあたりのデプロイされたアプリケーションにおける回避可能な統合課題の数
    • イテレーションあたりのトランクの安定性回復に費やした時間
    • プライベートビルドのコス

6.組織のスケーリング:ソフトウェアアーキテクチャの中心的役割

  • ソフト開発はソシオテクニカルシステムである
  • ソフトウェアアーキテクチャは、ミッションやKPIと結びついていなければならない
  • ソフトウェアアーキテクチャは、コンポーネントの責任の間に境界を作り、それらの相互作用を定義するために存在する
  • KPIを深く理解するために投資した時間は、ソフトウェアアーキテクチャを作成するときに報われる
  • ソフト開発には8つのムダがある

7.ソフトウェアアーキテクチャにおける計測の役割

  • 計測には、作成物に対するもの・運用に対するものと、外部計測・内部計測がある
  • 設計文書がガイドラインに準拠しているかどうかの計測は弱い計測だが、デリバリーサイクルの早い段階で計測できる利点がある
  • 計測を始める際、以下を念頭におく
    • 小さく始める
    • 重要なことを計測する
    • 計測に基づいて行動する
    • 早期に開始する
    • 計測を可視化する
    • 計測を継続的に行う
  • 逆に以下にならないように気をつける
    • 計測ではなく、仕組みにフォーカスしてしまう
    • やりやすいものを基準に計測を選択してしまう
    • ビジネスの計測よりも技術的の計測に重点を置いてしまう
    • 行動を起こさない
    • 有用性よりも正確性を優先してしまう
    • 計測し過ぎる

8.メトリクスからエンジニアリングへの進化

  • アーキテクチャ適応度関数
    • アーキテクチャの検証は場当たり的になりがちだが、一貫したアプローチが必要
  • JavaだとArchUnitというツールがある
  • 基本的には自作が必要( できる )
  • GitHub社では、変更前と変更後で振る舞いが変わらないことを実環境で検証する仕組みがある
  • 象牙の塔にこもって機能チームをイライラさせるだけの適応度関数を作ってはいけない

9.ソフトウェアメトリクスを使用して保守性を確保する

  • 重要な目標アーキテクチャ:保守性
  • メトリクスを測定し、フィードバックループを運用することで、プロダクトが品質・保守性の高い状態を維持することができる
  • ソフトウェアメトリクスによって、エントロピーを計測し、本質的に不要な依存関係の増殖を早期に見つける
  • 循環依存関係の有害性
    • コードの一部を切り離してテストできなくなる
    • コードを理解するのが難しくなる
    • 特定の機能を分離して置き換えられなくなる
  • 依存関係を断ち切ることはできる
    • 依存性逆転の原則
  • メトリクス
    • 最も大きな循環グループの要素数(小さいほうが、循環を壊しやすいので望ましい)
    • 平均コンポーネント依存値:各コンポーネントが依存するコンポーネント数の平均値
    • 相対的循環度:全コンポーネントのうち、どれぐらいが循環依存に関連しているか(100%が最悪。全部依存している)
    • 構造負債指数:いかに兼密な循環依存があるか(多いほど悪い)
    • 保守性レベル:循環グループを単一のノードにまとめ、自分より上位のコンポーネントのうち、どれだけに影響を与えるか

10.ゴール・クエスチョン・メトリクスアプローチで未知数を計測する

  • 何かを正しく計測するには、それをなぜ計測するのかを理解しなければならない
  • ゴールを特定し、ゴールを評価するための質問を列挙し、質問に対する応えを導き出すためのメトリクスを定義する