「Software Architecture Metrics」を読んだ
Software Architecture Metrics #29
章ごとに著者が異なる、メトリクスについてエッセイ集見たいな感じの書籍。
CI/CD、テスト、技術的負債、アーキテクチャ、DevOps、メトリクスの測定そのもの、保守性とかテーマごとに色々感じだった。
(アカデミックなものも混じっている感じ)
Building Evolutionary Architecturesで出てきた適応度関数(Fitness functions)が、この書籍では想像以上に出てきた。
まさにこの図のように、いろんなところでFitness functionsが出てきた。
Chapter 2. The Fitness Function Testing Pyramid: An Analogy for Architectural Tests and Metricsの、適応度関数とテストピラミッドの話が面白かった。
- 適応度関数は、部分的なもの? 全体的なもの?
- これは両方あって、それぞれ検証できるものが異なる
- 適応度関数は、一時的ですか? それとも永続的ですか？
- 有効性が設定によって制限されてるものは一時的、そうじゃないものは永続的(未期限)
- 適応度関数は、静的なもの? 動的なもの?
- コードカバレッジとかは静的
- アクティブユーザー数に関係して動くような応答時間目標とかも扱う
- これは動的。複雑ではあるけど、役たつケースあるので、ケースバイケース
この辺の適応度関数の具体的な話とかあんまり覚えてなかったので、面白かった。
進化的アーキテクチャは翻訳の方読んでなかったのでもう一度読み返そうかな。
Chapter 7. The Role of Measurement in Software Architectureは測定についての章。
そもそもなんで測定するかというと、継続的なアーキテクチャなどの難しい点が、時間を費やしたけど十分な作業ができたかが分からないことにある。
この解決方法として測定が使われる。
アーキテクチャのお作法をまねるよりも、測定をちゃんとしたほうが現在地がわかるよという話が良かった。
あと、測定の落とし穴という話が良かった。
- 測定ではなくメカニズムにフォーカスしてしまう
- 測定しやすいものだけ測定してしまう
- ビジネス観点より技術にフォーカスしてしまう
- 行動を起こさない
- 有用性よりも精度を優先してしまう
- 測定しすぎてしまう
Chapter 9. Using Software Metrics to Ensure Maintainabilityは、コードレベルの複雑性の測定の話。
- LoC
- Cyclomatic Complexity
- Indent Depth
- 変更頻度(Author)
- Code Churn
- Number of Author
- Component Rank
- LCOM4
とか色々なメトリクスの話が出てた。
その中でも循環依存の毒性とか循環参照(Circular dependency)は結構文字数あった気がする。
循環依存によって侵食されて全体が泥だんごになるような事例とかがあったのかなとか考えてた。
まあ、実際に改善する時のボトルネックになりやすい(いろんなツールが壊れたりとか並列実行を難しくしたりとか)ので、取り除くのがいいとは感覚的には分かってたけど、実際に複雑性を強くすることがわかって良かった。