Simple techniques for minimizing legacy code
Legacy code... developers know it when they see it, even though it eludes a single definition. "Code that's hard to work with," "code lacking automated test coverage," "someone else's code," etc.
It's a vital part of products everywhere, but it's trouble. It makes product maintenance harder, more specialized, and slower. Programming around legacy code is scary ("What did I break? What should I retest?"). It invalidates estimates for new development. It makes team self-organization (and hiring!) harder.
Legacy code is not a new phenomenon. But it's a bigger problem when you use Agile methods!
Agile teams respond to changing requirements. Their members are empowered to work anywhere in the code. They may also be expected (pressured?) to have consistently fast delivery.
In many teams, these conditions result in a reduction in design, holistic thinking, intrinsic quality, and code maintenance. Those teams still produce legacy code, only faster. They move fast today, risking the ability to move as fast tomorrow.
领英推荐
Pre-Agile, teams tried to minimize legacy code in four ways: limiting changes to requirements, designing extensively before coding, specializing in parts of the code, and making code more generic/abstract than needed for the problem at hand. These approaches were rarely effective long-term. Nowadays, they're often barriers to agility.
In an Agile environment, minimizing the creation of legacy code takes other strategies and tactics that must become second nature. One of the strategies is to *evolve* software in *small, safe steps*. While that's a cross-functional responsibility, here are simple-to-implement examples of what it looks like for developers:
These techniques would greatly reduce legacy code without your having to "go hardcore" with TDD and mobbing (which are great, but let's face it, not welcome or realistic everywhere).