Table of Contents for

Your Code as a Crime Scene

Differentiate Between True Problems and False Positives

We’ve covered a lot of ground in this chapter. You analyzed a large system, identified its hotspots, and learned techniques for investigating the visualizations.

You learned how a hotspot lets you focus on narrow areas of the code in need of attention. So you don’t have to manually inspect hundreds of modules, the analysis gave you a prioritized list of problem modules. You can use that to guide your future work. If you’re in a position to redesign the hotspots, then do it! Otherwise, you need to take defensive measures, such as writing additional tests or regularly inspecting code.

We also discussed how hotspots are distributed and how we can use this information to identify the stability of each subsystem or feature area. The key idea is that you want to evolve your modules into stability as soon as possible. (To read more on the subject, check out Michael Feathers’s excellent blog on The Active Set of Classes,^[18] which takes a slightly different view.)

You’re now at a point where you can identify weak spots in a large system. To make efficient use of your new skills, you need strategies to sort out real problems from false positives. The good news is that you’re just a chapter away from such techniques.