Let's review some principles that yield some good design ideas. The point is to quickly relate to good software practices with acronyms that are easy to remember, which work as a sort of mnemonic rule. If we keep these words in mind, we will be able to associate them with good practices more easily, and finding the right idea behind a particular line of code that we are looking at will go faster.
These are by no means formal or academic definitions; they are more like empirical ideas that emerged after years of working in the software industry. Some of them do appear in books, as they were coined by important authors (see the references to investigate them in more detail below), and others have their roots in blog posts, papers, or conference talks.
DRY/OAOO
The ideas behind Don't Repeat Yourself (DRY) and Once and Only Once (OAOO) are closely related, so let's look at these two concepts together.
Things in the code (knowledge), should be defined only once and in a single place. When we have to make a change to the code, there should be only one location to modify. Failure to do set thing up this way is a sign of a poorly designed system.
Code duplication is a problem that directly impacts maintainability. It is very undesirable to have code duplication because it has many negative consequences:
It's error prone: When logic is repeated multiple times throughout the code and it needs to change, we have to depend on efficiently correcting all the instances with this logic without forgetting or missing any of them, because it will cause a bug if we miss an instance.
It's expensive: Making a change in multiple places takes much more time (development and testing effort) than if it is only defined once. This will slow the team down.
It's unreliable: Also, when multiple places need to be changed for a single change in the context, we have to rely on the person who wrote the code to remember all the instances where the modification has to be made. There is no single source of truth.
Duplication is often caused by ignoring (or forgetting) that code represents knowledge. By giving meaning to certain parts of the code, we are identifying and labeling that knowledge.
Let's see what this means with an example. Imagine that, in a study center, students are ranked by the following criteria: 11 points per exam passed, minus 5 points per exam failed, and minus 2 per year in the institution. The example below is not actual code, but just a representation of how this information might be scattered in a real code base:
Get hands-on with 1400+ tech skills courses.