Heuristics for Flexibility and Maintainability
To write Code that’s easy to change, we need to follow a couple of heuristics. Changes do not create unrelated side effects. Small changes in requirements suggest small code changes. The easiest way to add new functionality to a code base is by adding new Code rather than modifying what already exists.
Code without side effects will be easy to change due to not worrying about cascading issues. We can acknowledge the code structure’s effectiveness by measuring the changes we must make in any code base when confronted with a new need. To Kent Beck, a design is “simple” if it follows these rules:
- Runs all the tests
- Expresses the intent of the programmer
- Contains no duplication
- Minimizes the number of classes and methods.
The Code must work. The Code must pass all the tests. After the Code is made to work, it should be made expressive. It should reveal the intention of the programmer. Duplication is the primary enemy of a well-designed system. After we have made the Code as descriptive and expressive as possible, we hunt for and remove any duplication within that Code. Move an extracted method to another class. That elevates its visibility.
Clean Code is simple and direct. Clean Code expresses requirements using specific guidelines. Clean Code reads like well-written prose. Clean Code can be read and enhanced by a developer other than its original author. It has unit and acceptance tests, meaningful names, and a focus on simplicity and consistency. Clean Code should be literate since, depending on the language, not all necessary information can be expressed alone. It has minimal dependencies, which are defined, and provides a clear and minimal API.
Flexibility in programming comes from postponing decisions until the last minute. We must wait for decisions to write changeable Codes until we gather more information about the problem. Any decision you make before an explicit rule is a guess. Don’t decide; preserve your ability to make a decision later.
