Dont Repeat Yourself
Last updated
Was this helpful?
Last updated
Was this helpful?
Was this helpful?
Repeating yourself, means wasting time, time that could be used to do other stuff
DRY is about wasting time
Focus on not repeating the business logic, this is should be one place
Areas of wasting time
Following an inefficient process
This can occur in the release cycle, the way new features are designed, sign-offs, or meetings
Use feedback, retros, to find out the waste and improve processes
automate these processes
Hearing we have alwasy done it, is a sign of inefficiency
Lack of automation
ie
deploying manually
Not invented here, also known as reinventing the wheel
arising from writing code before considering the reuse of existing code
people who enjoy implementing things that are easily available (inhouse or in open-source world)
Copy/paste programming - this is a common misconception of DRY addressed by the authors of it
Leads to errors
Leads to multiple places where changes need to occur
“I won’t need it again so let’s just hack it quickly” solutions
Never good if not tested
Not doing so means changing in one place, means having to remember to change in other places
Copy and Paste Programming
the more code you write, the more expensive it becomes to support and maintain the application
Both composition and inheritance are your friends in battling repetitive code
the use of design patterns and shared libraries.
web services to combat duplication on higher levels of abstraction.
Instead of building the same functionality into each application you develop, it is often a good idea to create a service and reuse it across the company.
Libraries
but can lead to coupling
Better to do it after it is apparent
Not extract when no duplication occurs in the hopes of reusue
Three occurrences and then dry
If it is known that the future requirements will be similar than dry
When it is regarding source of knowledge, not just patterns
Benefits outweigh the negatives, especially the time investment
It follows the idea of ETC (easier to change), it makes it:
easier to read
faster to extend or change
the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or…?
Best to time box the drying up of code, and see if it improves the codebase (ie ETC), and revert if not
DTOs or database schemas, repetition can be more readable and clear.
Imposed duplication.
Developers feel they have no choice
the environment seems to require duplication.
Inadvertent duplication.
Developers don’t realize that they are duplicating information.
Impatient duplication.
Developers get lazy and duplicate because it seems easier.
Interdeveloper duplication.
Multiple people on a team (or on different teams) duplicate a piece of information
A little duplication is often better than a little dependency.
Prematurely optimize when the requirements aren't finalized (spoiler: they never are).
Hence, the abstraction may need to change to cater for different cases for different consumer needs
https://overreacted.io/goodbye-clean-code/
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
Duplication is a convenient but not the best source for discovering abstractions
wrong abstraction at a lower level creates an exponentially worse dependency hell at higher levels.
There is always a trade off
sometimes better to copy and paste, and minimal changes, instead of having lots of logic
Time to refactor might be too long to remove duplication, and changing other code will require retesting
Removing Duplication Requires Abstractions and Abstractions Breed Complexity
Such generalized abstractions are notoriously hard to test and understand because they must handle many more use-cases than the original (potentially duplicated) code.
Said another way, abstractions support more behaviors than might actually be needed for the system to function properly.
Too much abstraction leads code that is hard to understand, maintain, or extend
This was first promoted in Pragmatic Programmer (Thomas)
In the second edition, they realised that it was not the correct message, as people took it too far
people believe that no copy and pasting was allowed
When a duplication is abstracted, and changes are needed for only on consumer of this abstraction, this can lead to clauses (if statements) proliferating the code base
instead duplicate the code
Lead to tight coupling
prefer some duplication instead
DRY can make it harder to debug
Should think very carefully to do this in test code otherwise can be hard to follow intent or debug
For small amount of duplication is not worth it
DRY can be seen as premature optimisation
https://www.infoq.com/news/2012/05/DRY-code-duplication-coupling/
https://oncodedesign.com/dry-vs-coupling/
https://www.industriallogic.com/blog/spot-and-coincidental-duplication/
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
https://www.entropywins.wtf/blog/2017/09/06/the-fallacy-of-dry/
https://rotemtam.com/2020/05/18/the-dry-principle-is-bad-advice/
https://gordonc.bearblog.dev/dry-most-over-rated-programming-principle/
https://salmonmode.github.io/2020/08/14/the-harmful-obsession-with-dry.html
https://www.gordoncassie.com/dry-most-over-rated-programming-principle/
https://www.gordoncassie.com/more-dry-talk-responding-to/
https://lbrito.ca/blog/2017/03/dont-obsess-over-code-dry.html
https://swizec.com/blog/dry-the-common-source-of-bad-abstractions/
Implementing DRY can lead to creating many methods, and the use of the popular refactoring Extract Method.
Sometimes it is better to fold the mehtods in (Inline Method)
writing functions that are nothing but 50 functions calls that themselves are just a few lines of code. That's as bad as the people who write 1,000 line functions
This can cause issues:
Lots of little methods makes code get hard to maintain
costs to breaking code up:
more cognitive load when a reader must jump around a file and remember what different functions do
https://www.reddit.com/r/ExperiencedDevs/comments/u7xynw/many_small_methods_make_code_hard_to_maintain/
long blocks of code (within reason) are made much easier to consume when they are broken up and commented well. I approach it but looking at the logic flow, then separate lines and blocks of code that are discrete logical steps in that flow, comment each, and only THEN ask myself what would make it better as another functio
Forget if the code looks similar. Is it describing the same business concept? If yes, DRY. If no, separate.
https://swizec.com/blog/dry-vs-soc-a-difficult-choice/
https://swizec.com/blog/dry-is-a-footgun-remember-to-yagni/
testing
building
configuring development machines
provisioning servers
documenting APIs
Try to automate your builds and deployments from day one, as they will only get more complicated as you go along
but make sure it can do exactly what you need, and if not it can be configured, do spikes
Duplicated code tends to also obscure the structure and intent of your code, making it harder to understand and modify
If an abstraction exists, then future change will feel the need to use this abstraction ( and thus change it) which leads to pollution of ideas and complexity
DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways
Dont dry coincidental duplication only essential duplication
essential duplication are parts that should change together
Logic is split apart and harder to follow
too many functions means more lines of code that makes it harder to see more of the code on your screen at once
more functions means more argument and return value passing which increases the chance for bugs
separating two very related pieces of functionality (get next free id and update next free id) increases the chance for bugs when someone updates one piece of the functionality and doesn't realize they need to update other related functionality in a different function.
issue of temporal coupling, calls need to be together if they are dependent in order
pulling more functions out makes it more likely that someone will reuse that function for something else which builds up complex dependencies making it harder to change some of the code because you have to understand much more of the codebase to safely change the code.