Avoiding knowledge duplication is daily bread and butter of every programmer. In this #QuickAnswer I'll shed some light on the subject.

#programming #tech #softwaredevelopment #developer #sde

Clean Code (R. Martin) - US: https://amzn.to/3jVUEDU | UK: https://amzn.to/2Iij4Jz
Best Practices for Programmers - US: https://amzn.to/2SPRSEg | UK: https://amzn.to/2Fr2h6e

What is DRY in programming and why it matters?

DRY stands for Do Not Repeat yourself. And it is one of the primary principles of good, clean code used by every professional programmer daily. If you don’t respect it - you won’t get very far.
Very naive explanation of this rule says that you shouldn’t just copy and paste the code around, and that is true, but it’s about much more than that. Keeping your code DRY is about duplication of knowledge and intent.
When we write our programs we codify the rules that govern the business side of the program, and this process is very costly. Time of programmers is expensive, and throughout the lifetime of a product - a single change gets the attention of very many people. There is an author, a reviewer, another programmer who finds a bug in the code, and fixes it, and then there is someone who builds on top of the code and extends it.
Therefore it is very imperative to avoid writing a code that when change is needed - has to be modified in many places in order to support new requirements. Today we acknowledge change as an inherent part of building a product, so much that we formed entire methodologies around supporting constant change like agile.
So whenever you need to check if your code is really dry, ask yourself: if the product has new requirements: how many places and formats do you need to change? Few bits of the code? Documentation? Database? Network layer? APIs? Answering yes too many times and your product isn’t DRY.
Of course there is a tradeoff related to writing the code in DRY manner: you spend more time on initial stages, designing, cleaning and distilling interfaces, partitioning the code and refactoring things that no longer fit the new purpose. It may seem like it takes forever to produce such clean code, but because of that - the cost of maintaining this code in the future will be orders of magnitude less. Perhaps this is the cost you will be paying very soon.
One thing that we need to be vary is overly extensive strictness when it comes to code duplication. Example given in The Pragmatic Programmer book is perfect to illustrate that: two validation functions that check for different things, but actually share the same body.
Should we merge this under one function and just call it “validate_something”? Of course no, this isn’t the duplication of knowledge, it’s a coincidence. As soon as one of these things will need to be changed - we’ll have to break the function into two. Another issue is finding generic validators in the repository that we can’t immediately assign to validated value.
Knowledge duplication really can be the source of all evil. Sooner or later the both versions will start to diverge, and keeping them in line always seems like wishful thinking. It doesn’t matter if these are two bits of code, comments or intent expressed in the database. It will break, believe me.
Avoiding duplication will be your bread and butter, the further you go into the land of software development, and like everything in it - it’s another point to debate and pick from a myriad of solutions. Don’t worry - the expertise to solve these issues will come with practice.
Subscribe, and I’ll see you in the next one, cheers!