| Preface |
|
vii | |
|
1 Four Key Metrics Unleashed |
|
|
1 | (20) |
|
Definition and Instrumentation |
|
|
2 | (1) |
|
Refactoring Your Mental Model |
|
|
3 | (1) |
|
Pipelines as Your First Port of Call |
|
|
4 | (2) |
|
Locating Your Instrumentation Points |
|
|
6 | (4) |
|
|
|
10 | (2) |
|
Display and Understanding |
|
|
12 | (1) |
|
|
|
13 | (1) |
|
|
|
13 | (4) |
|
|
|
17 | (1) |
|
Discussions and Understanding |
|
|
18 | (1) |
|
Ownership and Improvement |
|
|
18 | (1) |
|
|
|
19 | (2) |
|
2 The Fitness Function Testing Pyramid: An Analogy for Architectural Tests and Metrics |
|
|
21 | (22) |
|
Fitness Functions and Metrics |
|
|
21 | (2) |
|
Fitness Functions: Test Coverage |
|
|
23 | (1) |
|
Fitness Functions: Integration Tests with Network Latency |
|
|
24 | (1) |
|
Introduction to Fitness Function Categories |
|
|
25 | (1) |
|
Mandatory Fitness Function Categories |
|
|
25 | (3) |
|
Optional Fitness Function Categories |
|
|
28 | (2) |
|
Fitness Function Categories: Catalog Overview |
|
|
30 | (1) |
|
|
|
30 | (2) |
|
The Fitness Function Testing Pyramid |
|
|
32 | (1) |
|
|
|
33 | (1) |
|
|
|
34 | (1) |
|
|
|
34 | (1) |
|
Examples and Their Full Categorization |
|
|
35 | (2) |
|
Fully Categorizing Top-Layer Examples |
|
|
37 | (2) |
|
Developing Your Fitness Functions and Metrics |
|
|
39 | (2) |
|
|
|
41 | (2) |
|
3 Evolutionary Architecture: Guiding Architecture with Testability and Deployability |
|
|
43 | (6) |
|
The Importance of Learning and Discovery |
|
|
44 | (1) |
|
The Tools of Sustainable Change |
|
|
44 | (1) |
|
Testability: Creating High-Quality Systems |
|
|
45 | (2) |
|
Deployability: Scaling Development of Our Systems |
|
|
47 | (1) |
|
|
|
47 | (2) |
|
4 Improve Your Architecture with the Modularity Maturity Index |
|
|
49 | (16) |
|
|
|
49 | (1) |
|
Origination of Technical Debt |
|
|
50 | (2) |
|
|
|
52 | (1) |
|
|
|
53 | (1) |
|
|
|
54 | (2) |
|
|
|
56 | (1) |
|
|
|
57 | (4) |
|
Architecture Review to Determine the MMI |
|
|
61 | (2) |
|
|
|
63 | (2) |
|
5 Private Builds and Metrics: Tools for Surviving DevOps Transitions |
|
|
65 | (16) |
|
|
|
66 | (1) |
|
|
|
66 | (1) |
|
|
|
67 | (1) |
|
|
|
68 | (1) |
|
Empowering the Local Environment Again |
|
|
69 | (1) |
|
|
|
70 | (2) |
|
Case Study: The Unstable Trunk |
|
|
72 | (1) |
|
|
|
72 | (1) |
|
|
|
73 | (1) |
|
|
|
73 | (1) |
|
|
|
73 | (1) |
|
Case Study: The Blocked Consultant |
|
|
74 | (1) |
|
|
|
75 | (1) |
|
|
|
76 | (1) |
|
Evitable Integration Issues in the Deployed Application per Iteration |
|
|
76 | (1) |
|
Time Spent Restoring Trunk Stability per Iteration |
|
|
77 | (1) |
|
The Cost of Private Builds |
|
|
78 | (1) |
|
|
|
78 | (1) |
|
High Time to Feedback, High Evitable Integration Issues, Low Time to Trunk Stability |
|
|
78 | (1) |
|
Low Time to Feedback, High Evitable Integration Issues, Low Time to Trunk Stability |
|
|
79 | (1) |
|
High Time to Feedback, Low Evitable Integration Issues, Low Time to Trunk Stability |
|
|
79 | (1) |
|
Low Evitable Integration Issues and High Time to Trunk Stability |
|
|
79 | (1) |
|
|
|
80 | (1) |
|
6 Scaling an Organization: The Central Role of Software Architecture |
|
|
81 | (24) |
|
Your Fin Freedom Breaks the Monolith |
|
|
83 | (2) |
|
Implementing a Distributed Big Ball of Mud |
|
|
85 | (2) |
|
|
|
87 | (1) |
|
From Best Effort to Intentional Effort |
|
|
88 | (3) |
|
Increasing Software Architecture Intentionality, Guided by Metrics |
|
|
91 | (8) |
|
Managing Expectations with Communication |
|
|
99 | (3) |
|
Learning and Evolving the Architecture |
|
|
102 | (2) |
|
|
|
104 | (1) |
|
|
|
104 | (1) |
|
7 The Role of Measurement in Software Architecture |
|
|
105 | (20) |
|
Adding Measurement to Software Architecture |
|
|
106 | (2) |
|
|
|
108 | (1) |
|
Runtime Measurement of Applications and Infrastructure |
|
|
108 | (1) |
|
|
|
109 | (1) |
|
|
|
109 | (1) |
|
|
|
109 | (1) |
|
|
|
110 | (1) |
|
Measuring System Qualities |
|
|
110 | (1) |
|
|
|
111 | (2) |
|
|
|
113 | (1) |
|
|
|
114 | (2) |
|
|
|
116 | (2) |
|
|
|
118 | (1) |
|
|
|
119 | (2) |
|
|
|
121 | (2) |
|
|
|
123 | (2) |
|
8 Progressing from Metrics to Engineering |
|
|
125 | (18) |
|
The Path to Fitness Functions |
|
|
125 | (2) |
|
From Metrics to Engineering |
|
|
127 | (3) |
|
Automation Operationalizes Metrics |
|
|
130 | (2) |
|
|
|
132 | (4) |
|
Case Study: Zero-Day Security Check |
|
|
136 | (2) |
|
Case Study: Fidelity Fitness Functions |
|
|
138 | (3) |
|
|
|
141 | (2) |
|
9 Using Software Metrics to Ensure Maintainability |
|
|
143 | (28) |
|
The Case for Using Metrics |
|
|
143 | (1) |
|
|
|
144 | (2) |
|
The Toxicity of Cyclic Dependencies |
|
|
146 | (1) |
|
|
|
147 | (1) |
|
Why Are Metrics Not More Widely Used? |
|
|
148 | (1) |
|
|
|
149 | (1) |
|
|
|
150 | (1) |
|
Metrics to Measure Coupling and Structural Erosion |
|
|
150 | (10) |
|
Metrics to Measure Size and Complexity |
|
|
160 | (2) |
|
|
|
162 | (1) |
|
|
|
163 | (2) |
|
Architectural Fitness Functions |
|
|
165 | (2) |
|
How to Track Metrics over Time |
|
|
167 | (1) |
|
A Few Golden Rules for Better Software |
|
|
168 | (1) |
|
|
|
169 | (2) |
|
10 Measure the Unknown with the Goal-Question-Metric Approach |
|
|
171 | (15) |
|
The Goal-Question-Metric Approach |
|
|
172 | (1) |
|
|
|
172 | (2) |
|
Prioritize Metrics and Devise a Data Collection Strategy |
|
|
174 | (3) |
|
Case Study: The Team That Learned to See the Future |
|
|
177 | (1) |
|
|
|
177 | (2) |
|
Incident #1 Too Many Requests to the Foo Service |
|
|
179 | (2) |
|
Incident #2 Seeing the Future |
|
|
181 | (1) |
|
|
|
182 | (1) |
|
|
|
182 | (1) |
|
|
|
182 | (2) |
|
|
|
184 | (1) |
|
Facilitation Guidelines and Hints |
|
|
185 | |
| Conclusion |
|
186 | (3) |
| Index |
|
189 | |
