DRY? SOLID? Duh... Please Make It Easy For Me to Read
If you’re a programmer, developer, or software engineer (or you can add other titles related to software development), I am sure that you have ever heard at least one of the lingos which I use in the title. As a programmer, I used to be so excited to follow these rules. Nowadays I am reaching some kind of mental fatigue whenever I hear people use these principles. Here’s why.
A Mentally Tiring Example
If you are an engineer who handles client-side apps (websites or mobile apps), you’re probably familiar with forms. Let’s say your app has multiple forms which are similar, and since you’re tired of maintaining multiple forms, you create a function that generates a form.
You don’t need to maintain multiple forms on each page. If you ever need to change how the form looks, add or remove fields, you only need to visit this function and change the function behavior. This follows the DRY principle, which is an acronym for Don’t Repeat Yourself.
But, wait until you receive new requirements which require you to differentiate the form generated by this function. For this example, let’s say we want to differentiate so when users change their address, they can see their previous changes.
In this example, we add oldAddress as a new variable that our <UsersBioForm /> track. Several days later, with requirements added and changed each time, your <UsersBioForm /> may turn out into a new nightmare code, filled with conditionals. Let’s say we want to differentiate the registration form and edit profile form by adding a checkbox.
Our simple biodata form has turned into some kind of “super” form, which I believe would be difficult to follow if this code is handled by a new programmer in the future.
Managing Complexity is The Main Purpose of All Code Principles
When you work in software development, especially if you handle legacy code, you will most likely find these kinds of code scattered around your codebase. The motivation for writing these kinds of code are varying. Maybe the author is just lazy, or maybe the author feels this is the smartest thing to do at the moment, or maybe someone is just showing off. Whatever the motivation is, codes like this stray from the main purpose of all code structuring principles, which is to manage complexity.
Managing complexity is super important when you manage a codebase, because most of the time, your code is read more often than it is written. You probably create features in days, weeks, or even months, but your colleague and most likely you yourself will read that code for as long as an app is used. I believe you want your application to be useful for people for a very long time, so you will read your code for a very long time. You wouldn’t want to work with code while pulling your hair and cursing all day due to reading complex code. This is exactly why people strive for code readability.
Even if we are aiming for code readability on purpose, sometimes our code will still end up confusing. When you build features, maybe you don’t really get what the feature is, so you end up hacking, doing trial and error, and finally come up with this kind of structure. Maybe you just finished reading a book about programming that blows your mind, and want to try new patterns ASAP. After you implement things, your colleague starts complaining or intentionally avoids the code that you write. This is exactly why software development is hard, there is no bulletproof way for structuring readable code.
Every coding principle and structuring technique like DRY, SOLID, VIPER, and many other acronyms actually tries to address code complexity in its own ways. They are good principles at their core. The usual problem that makes these principles easily misused by developers is that sometimes developers follow examples explaining these principles without further critical thinking. They follow these principles as if it’s a hard rule, and adopt the way of thinking based on the example shown, rather than matching it with context. This is a dangerous way of thought.
When you write code, your code should always reflect what you think about the problem. If you think about something written in multiple functions, even if these functions have the same statements doesn’t mean you always need to create another base class as an abstraction and inherit from it. Just because a language feature is there, doesn’t mean you have to use all its features.
TLDR: Please Make It Easy For Me To Skim Your Code
Understand the motivation behind each principle, and be critical about the principles’ application. Make sure you apply any coding principle at the proper times. Remember that our job is to manage complexity, which means we have to make sure our code looks as easy as possible, so easy even a kid can handle.
