Instagram @SophieGamand
WET Principle and Libraries
WET principle— Write Everything Twice
We are already aware of and actively utilizing the DRY principle, but after spending around 2.5 years creating and maintaining internal libraries, I feel the need to propose the WET philosophy as a complement (not as an alternative) to DRY.
Although the team is already “kind of” adopting WET for development, this notion has not yet been adequately explained, announced, or consciously applied.
Important to note: The WET principle, as I’m currently introducing it, only applies to reusable components, such as larger sections of code with distinct, independent business logic or potentially reusable UI components.
Motivation
We have a number of components in our core library that are not mature enough. Although we consider them to be “reusable,” their internal methods and parameters (APIs), naming conventions, and internal product-specific aspects practically prohibit reusability. When added to a new product, such components feel like square pegs in round holes (product here: a separate, complete, standalone application created with a specific purpose for a specific domain).
This issue results from early optimization and early extraction of the application’s contained components with the intention of reuse.
According to the retrospective analysis, the team is experiencing DRY problems with the immature extraction of the big functional components that contain independent and product-specific logic at the time of extraction.
The majority of the time, DRYing of the smaller utilities and class-level methods goes smoothly.
Solution: WET (Write Everything Twice)
You can ask yourself “Haven’t I written this before?” two times, but never three. [1]
Before you consider extracting a class into a reusable component for a component library, the idea is to ensure that this class with the same logic has been independently written for at least 2 different products.
In this approach, the necessity for a potentially destructive reworking will be greatly diminished and our reusable components will be more developed, more stable, and have generalized parameters, names, and internals.
Conclusion
After all of that, it’s crucial to understand the complexity. Which is better, DRY or WET? Well, depends on the situation. Conditions matter, and it’s not a good idea to adhere rigidly to software development rules.
Future roadmap
When WET principle has been standardized and perfected, all reusable components need to follow Open-Closed principle.
Reusable component should only be updated, maintained, and developed within a context of itself, not within a context of a product it’s being used in. All product-specific behavioral or logical adjustments should be done by extension where reusable component is an abstract base product-specific wrapper inherits it’s functionality from.
Given that most of the development is done with vanilla JavaScript which doesn’t have classic OOP structures and instruments built in, we will need to evaluate and possibly integrate external interpreters/transpilers such as TypeScript which will help Open-Closed by clearly communicating/documenting component APIs with types and interfaces.
Resources
[1] https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33
[2] https://overreacted.io/the-wet-codebase/
