Shifting Code Towards Simple Design
Most Agile team adoptions fail when they focus on coping with complexity rather than solving for simplicity.
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.
Decrease the number of structural elements, such as classes, functions, variables, etc. The goal of Simple Design is to keep the design weight of the code as small as practicable.
Methods with repeating prefixes or suffixes may indicate the presence of a tortured object that is trying to be separated. Objects that only serve to forward messages to other objects should be evaluated for their necessity. Make smaller objects. Make smaller classes, make smaller methods, and let them know as little about each other as possible. It can be tempting for some programmers to avoid creating new objects and adding complexity to the codebase. Yet, doing so can add more code to places with similar functionality. Following good design patterns is essential, as they can improve the code, but using a lousy way can worsen the problem. Keep helper classes small and avoid adding them to large ActiveRecord objects. Messages allow us to add behavior by replacing role-acting objects through boundaries or seams.
There is a trade-off to consider when dealing with complexity in code. Good design patterns can improve the code, but destructive patterns can worsen problems. It’s best to avoid adding small helper classes to large models and use messages to create seams that allow substituting other objects. It is more cost-effective to tolerate duplication rather than struggle with the wrong abstraction.
[¹]: Kent Beck (1996): (Smalltalk Best Practice Patterns)
