「ソフトウェアアーキテクチャメトリクス」を読んだ

トラブルが多いなとか、修正に思っているよりも時間かかると言われたりするなと思うことが増えてきたときに社内でタイトルを見かけたので読んでみることにした。

ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス

目次は以下。

1章解き放たれた4つのキーメトリクス
2章適応度関数テストピラミッド：アーキテクチャテストとメトリクスのためのアナロジー
3章進化的アーキテクチャ：テスト容易性とデプロイ可能性でアーキテクチャを導く
4章モジュール生成熟度でアーキテクチャを改善する
5章プライベートビルドとメトリクス：DevOps 移行を乗り越えるためのツール
6章組織のスケーリング：ソフトウェアアーキテクチャの中心的役割
7章ソフトウェアアーキテクチャにおける計測の役割
8章メトリクスからエンジニアリングへの進化
9章ソフトウェアメトリクスを使用して保守性を確保する
10章ゴール・クエスチョン・メトリクスアプローチで未知数を計測する

ソフトウェアアーキテクチャメトリクスとは本書では以下と紹介されている。

ソフトウェアアーキテクチャメトリクスとは、ソフトウェアの保守性やアーキテクチャ品質を計測し、プロセスの早い段階でアーキテクチャ負債や技術的負債の意図しない蓄積を警告するのに用いるメトリクス

p.v

1章ずつ別々のソフトウェアアーキテクトが、知っておくべきソフトウェアアーキテクチャメトリクスが紹介されている。それなので、体系的にまとまっているというわけではなく、実践者からの投稿をまとめているエッセイ集みたいになっている。

話題としてはFour Keys メトリクス、アーキテクチャ適応度関数、モジュール性成熟度指数などが紹介されていた。そしてそれらを使って組織の成熟度を測る方法やメトリクスを用いてアーキテクチャの品質向上に役立たせる方法についても記載されている。
メトリクスを定義しているだけではなく、ダッシュボードを作成し保守性を保っていくなどの話がありとても面白かった。

僕のところではまずは計測するための準備をし、計測してみる。計測できないならば計測できるようにまずは変更をしていく必要があるなと思った。
現在のうちのシステムは泥団子のものが大変たくさんあると思う。よく影響範囲やレビュー範囲を狭めるために分割したいなという話をしているが、それだけではただ単に小さい泥団子になってしまうなと。たしかに困っているのは分割されてないことではなくカオスさなので、まずはメトリクスを決めて取得し、そこから改善を考えていくのが良さそうだなと思った。

読んでいると進化的アーキテクチャでの話がたくさん出てくる。昔読んではいるけどあまり覚えてないなとなってしまったので、再度読み直してみるのが良さそうだなと思った。