Improve Your Code’s Structure and Adaptability
Refactoring introduces flexibility. It is the process of changing the internal structure of a program without modifying its external behavior. Its purpose is not to expect design but to rearrange the code to make it easier to change in the future.
Refactoring does not aim to achieve the highest density of design patterns. It is about balancing simplicity, readability, and changeability. Why make it difficult to change if you need to change your code?
Refactor because you need to make an actual change, whether for bug fixes or new features. Refactoring is about gaining insight into a problem and improving the code’s structure to make it easier to change. Don’t feel obligated to refactor because you are embarrassed about your code’s aesthetics.
Developers must follow specific heuristics to write code that’s easy to change. Changes should not create unrelated side effects. Small changes in requirements suggest small code changes. Adding new code is more straightforward than modifying what already exists. The existing code is reusable.
Code without side effects is easier to change without worrying about cascading issues. Measuring the changes we must make in a codebase when faced with a new need can determine the code structure’s effectiveness. To Kent Beck, a design is “simple” if it follows these rules: Runs all the tests. Minimizes the number of classes and methods. Expresses the intent of the programmer. Contains no duplication.
Duplication is the primary enemy of a well-designed system. The code must work and pass all the tests. After the code works, it should be expressive to reveal the programmer’s intention. After making the code descriptive and expressive, remove any duplication within that code. Moving an extracted method to another class elevates its visibility.
Clean code is simple and direct and expresses requirements using specific guidelines. It has unit and acceptance tests, meaningful names, and a focus on simplicity and consistency. Clean code should be literate, and its dependencies should be minimal, providing a clear and minimal API.
Flexibility in programming comes from postponing decisions until the last minute. That’s the promise of Object-Oriented Design. Preserve your ability to decide later by waiting for more information about the problem. Any decision you make before an explicit rule is a guess.
