Over the holiday break I read Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill. I was drawn by the title – after watching some CSI, who doesn’t want to think like a forensics expert? I’m glad to say I learned several things from reading this book.
The overall premise is to use heuristics to identify problem code modules including “hotspots” that are likely to cause future problems, and to intelligently deal with these modules before they cause any more damage. These heuristics are built into a tool built by the author, called Code Maat. The problems include code of high complexity, high rate of change, or unexpected coupling to other code modules. Each of these problems is likely to cause new defects or to decrease the speed at which the overall application can be improved. The appendix suggests several ways to refactor these problem modules.
The first chapters introduce several heuristics to help you gauge code and software complexity. The most interesting assertion from the author is that despite their inherently simplistic (and thus you might say flawed) nature, they are fast and good enough! The heuristics are great for combing through a mountain of possibilities and providing you a small subset of places worth reviewing. Several of these places will be false positives, but there are very few false negatives with these approaches.
One interesting code-level heuristic is to use the shape of the code as a way to measure code complexity. Indeed, by taking a blurred snapshot of several code examples it was easy to see which code snippet was more complex than others. Other useful code-level heuristics were simply rate of change (number of commits affecting a module) and size (in lines) of code module. Further, by taking any of these heuristics and plotting them over time, you can figure out whether the quality of your codebase is increasing or decreasing!
The author reiterates several times these forensic measures are to identify refactoring candidates. The next time you hear a developer say “we need to rip and replace” or worse “we need to rewrite from scratch”, try running the analyses from this book to see if a more targeted effort could work.
The middle chapters take the code-level heuristics and map them to a system or architecture level. By grouping code into packages/subsystems, you can determine which of these higher-level constructs need quality improvements. These chapters also introduce the concept of temporal coupling – different files/modules that change at the same time – which is a sign of low quality architecture or architecture decay. Each of the architecture-level metrics can also be plotted over time.
The final chapters remind you when to use these heuristics and when not to rely on them. Several of the heuristics measure and detect code churn. However, code churn is a symptom not an actual disease! Code changes for a reason and you can’t tell from numbers alone if it was a good or bad reason.
Overall, this is a useful book for developers and architects, and Code Maat is a useful tool for measuring code quality. Well worth a read and worth your time to evaluate your own code base against these techniques!
