Imagine having to deal with a production issue that is breaking a critical component of your business. As a developer, you do your inspection of the system and collect all the data necessary to help in figuring out what is wrong. Once the analysis is complete you realize what is causing the problem and you believe adding a 1 line change will fix the problem. As you type that 1 line change, which is surrounded by a forest of nested if-else conditionals, you ask yourself, how am I going to test this change?
To test the fix you take the scenario that was breaking the app and try to simulate it in the dev environment. After you run your manual test and nothing breaks you think you’re good to go and get your app ready and start the production build. Once the build is done and the artifact is ready you deploy to prod and do the necessary restarts and then your log file explodes with exceptions!
What happened? You tested the fix and simulated the production issue. It was also a 1-line fix so how did it cause all these exceptions?
In this simulated situation, I did leave out some detail about the current state of the application. If you focus back on the forest of nested if-else conditionals you see that was a hint at what the rest of the app looks like. The code in this fictitious app was not written well and as a result, a 1-line change rippled through the code base like bees on honey.
This type of situation, although fictitious, probably happens in many companies. The code is written quickly and only manually tested. Changes are made by adding conditionals to existing logic in order to handle the new scenario. Small bugs keep getting pushed from release to release because there is no time to work on them and no one wants to touch the existing monstrosity that their application has become until it becomes a critical production issue.
How could an application reach this state? It starts with the developers. Do they apply any discipline? If no, then the scenario I mentioned is the result.
Writing clean code is a discipline. It takes time to learn. I’m still not there myself but I’m learning from the book “Clean Coders” by Robert C. Martin (Uncle Bob) and his video series “Clean Coders”. As a clean coder, you build applications that are testable and adaptable to change. Your changes are driven by tests using the Test Driven Development (TDD) process. From the variable name to the class name everything should be easy to read and understand.
Why spend the time to learn the discipline of clean code? Doesn’t it take time to learn and apply this discipline? As Uncle Bob likes to say, “If you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.” In order to make it easy to read you need to apply the clean coding principles throughout your development. Learning this discipline will not only help you in becoming a better programmer and avoiding late-night production issues but it will also make you a more professional Software Developer.
