Over the past decade, there’s been some fascinating research on software evolution. Like most ideas and studies from academia, these findings have not crossed over into the industry. This book bridges that gap by translating academic research into examples for the practicing programmer.
You may be wondering how the strategies we cover in this book will relate to other software development practices. Let’s sort that out so that you know how your new skills will complement your existing ones.
Tests: The techniques you are about to learn let you identify the parts of your code most likely to contain defects. But they won’t find the errors themselves. You still need to be testing the code. If you invest in automated tests, this book will give you tools to monitor the quality and evolution of those tests.
Static analysis: Static analysis is a powerful technique for finding errors and dangerous coding constructs. Static analysis focuses on the impact your code has on the machine. In this book, we’ll focus on how we humans look at the meaning of our code. Your code has to serve both audiences—machines and humans—so the techniques in this book complement static analysis rather than replace it.
Complexity metrics: Complexity metrics have been around since the 1970s, but they’re pretty bad at, well, spotting complexity. Metrics are language-specific, which means we cannot analyze a polyglot codebase. Another limitation of metrics is that they erase social information about how the code was developed. Instead of erasing that information, we’ll learn to derive value from it. We’ll complement metrics with more data.
Code reviews: A manual process that is expensive to replicate, code reviews still have their place in software development. Done right, they’re useful for both bug-hunting and knowledge-sharing. The techniques you’ll learn in this book will help you prioritize the code you need to review.
As you see, the techniques you’ll learn complement existing practices, rather than replacing them. I often use these techniques to identify parts of the code in need of manual inspection and review—or, as you’ll see soon, to communicate with testers and other developers about the codebase.
Software Development is More Than a Technical Problem | |
|---|---|
|
|
In a surprisingly short time, we’ve moved from lighting fires in our caves to reasoning about multicores and CPU caches in cubicles. Yet we handle modern technology with the same biological tools as our prehistoric ancestors used for basic survival. That’s why taming complexity in software has to start with how we think. Programming needs to be aligned with the way our brain works. In this book, we’ll take several opportunities to move beyond pure technical material. You’ll learn why beauty is a fundamental quality of all good code, how individuals can bias group decisions, and how coding to music affects your problem-solving abilities. |