In defense of Coding Patterns, Principles, and Best Practices
Again the same component is giving errors. Users keep reporting bugs in it. Your mailbox is piled with lots of user complaints. It seems you have solved the same bug more than once.
All developers agree that the best solution would be to rewrite that component. But there is no time. You have to ship another feature.
Patch after patch, that component turned into a big ball of mud. And nobody wants to touch it.
I bet you have lived that situation too.
The bad news is there is no magic wand to make muddy code shine in just an instant. We have disciplines, principles, and best practices.
On Refactoring
What if, instead of having long methods in a 5000-line file, we start to write short methods with descriptive names?
That’s Refactoring. Improving the code without changing its observable behavior. It seems like nonsense, but we make our code easy to understand for the next person picking the code. Often, that person is our future self.
Small refactors like renaming variables and extracting duplicate code to short and reusable methods improve our codebase step by step.
On Design Patterns
What if we start to embrace vocabulary and solutions for common code problems?
Those are Design Patterns. A concept from the 90s showing frequent solutions to recurrent problems in Object-Oriented Design.
Builder, Decorator, Template, Factory… Design Patterns are part of the technical jargon or vocabulary of programming. It’s easier to think of “factory methods” than “methods that create a child class in a hierarchy from an identifier.”
Design Patterns are also a refactoring tool. They help us to remove duplicate code and communicate the intention behind our code. For example, it’s easier to use with Builders and Factories than to create complex objects in different places in our code.
On Clean Code
What if, instead of comments, we start to write meaningful names?
That’s Clean Code. Writing code that is easy to understand and change. Adding comments to an obscure method doesn’t make it easier to understand.
Comments have a problem: compilers don’t check them. Therefore, we forget to update them after we change the code.
I bet you have found comments like i++; // Increment i Nothing we can infer from the code in the first place. This type of comment causes more harm than good.
On Unit Testing
What if we have an automatic way to check if the code works after every code change?
That’s Unit Testing. Writing an automated piece of code that invokes another part of a system and checks its behavior.
Unit Tests allow us to change our code with confidence that we don’t break other parts of our codebase along the way. Unit tests allow change.
With enough unit tests, after pressing a button, we can know if we break anything even before we ship our code to our end users.
Parting Thoughts
These ideas aren’t new. The Clean Code movement condenses many of them. Robert Martin (a.k.a. Uncle Bob) made this movement popular with his books. One of those has the same name: “The Clean Code.”
We write healthier codebases from variable names to methods to comments to the overall software architecture, sticking to our principles and disciplines.
Of course, we can write code without following any of these principles. But, we get to a big ball of mud from small daily decisions we make at the line level. Often, there is no time to make things the right way in the first place. But, there is plenty of time to rewrite components later.
Stay tuned to Klever for Solutions for more content about careers, interviews, and programming in general. Follow Klever for Solutions on LinkedIn too.
