Many software engineers swear by the DRY principle, or "Don't Repeat Yourself." This concept encourages the extraction of duplicate code into functions or classes, promoting readability and maintainability. However, like many good practices, it can be taken too far. Overzealous elimination of duplications can cause code to become so DRY that it’s actually brittle.
Much like dry skin that cracks and becomes fragile, overly DRY software can lead to unforeseen issues and complexities. The problem arises from our natural human tendency to eagerly identify patterns and eliminate redundancies - possibly prematurely.
As humans, we are wired to recognize patterns. This trait is invaluable in many aspects of life, such as spotting the leopard hiding in the bushes, or engineering good software. However, this eagerness to see patterns can sometimes lead us astray, for instance, when a child sees monsters in the dark. In the context of coding, it can result in premature abstraction, where developers eliminate duplicates before fully understanding the implications.
An alternative approach is the WET principle: "Write Everything Twice." This might seem counterintuitive at first, but it has its merits. By allowing some level of code duplication, developers can gain a better understanding of the use cases and the actual requirements. This approach provides the flexibility to adapt and refactor the code when a more comprehensive pattern emerges, rather than forcing a premature abstraction.
The key is finding the right balance between DRY and WET. It's essential to recognize when duplication is harmful and when it is a natural part of the development process. Here are a few tips to strike that balance:
Understand the codebase: Don’t just dive into a codebase you’re not familiar with, extracting functions and classes on sight. Before eliminating duplicates, ensure that you have sufficient understanding of the problem domain and the current use cases.
Duplicate, then extract: First write the duplicate code, and make sure that it’s covered in a test. Then zoom out and figure out if the two instances of the duplicated code are semantically identical (meaning, they serve the same purpose) or just syntactically identical (meaning, they just happen to be similar). If they serve the same purpose, we can probably assume that any change to one occurrence will need to be applied to the second one, thus we can safely extract it. Syntactically identical code may look the same right now, but that might be a mere coincidence - thus we should refrain from extracting it.
Refactor gradually: Instead of aggressively abstracting code, refactor in stages. This allows you to test and validate each change, ensuring stability. Refactors that are too eager often end in partial or complete reverts, when we figure out that we’ve gone too far – but too late. Gradual refactoring is the basis for facilitating Emergent Design - an important and powerful approach to building flexible software.
In conclusion, while DRY is a valuable principle in software development, it's crucial to avoid the pitfalls of becoming too DRY. Embracing a balanced approach, sometimes writing everything twice, can lead to more robust and maintainable software. Remember, the goal is to create software that is both readable and flexible, avoiding the fragility that comes with over-abstraction.
Commentaires