I have been developing and design software for more than five years, so I want to share basic concepts on how to write robust and good maintainable code.
Let's start with the most valuable programming principles that I use every day in my work.
The KISS Programming Principle. Keep it short and simple or Make Things Easy. I think this is the main principle for every developer. And I will show you how to implement it. KISS is a mostly design principle that declares the system's simplicity as a primary goal or value.
So, when you are writing a program, you should follow such recommendation:
- Don't overload your code with abstractions. It leads to poor readability. Try to make sure that the program has well-defined layers. And you can replace some layers with minimal changes to the code.
- Do not include into your project redundant functionality, which is not needed at the moment.
- Don't write a lot of logic into each method. Decompose the execution logic so that each method performs a minimal task. Decomposing something complex into simple components is one of the main principles of KISS.
- Accuracy or attention to detail is not always needed. If your program may lose some queries or round data more roughly according to the specification, you do not need to add logic to avoid such situations. The complexity of your solution will increase exponentially, leading to new, even harder-to-catch errors. Better instead, write more unit tests on the code you already have)
- Try to write code as simple as possible. Avoid complicated language structures. Use predominantly immutable objects.
KISS principle closely resonates with another one of my favorites - DRY.
It stands for Don't Repeat Yourself. I call it often - Do not copy-paste! So, what is that mean?
Try to remove all duplication code or logic in your program. If the code is not duplicated, it is enough to make corrections in just one place to change the logic - so you avoid some tricky errors, and it is easier to test one function rather than a set of dozens of similar ones.
With logic blocks, it is more difficult because of the large chunks of code. You have to analyze it carefully and find those modules that do almost the same job. And replace it with one, but more versatile.
But this approach will pay off quickly. You get a smaller codebase. Each method/class/module performs a strictly designated task. The program is easier to test and debug.
These are the two main principles that I use in my work every day.
This article would not be complete if I did not mention the SOLID principles. Most of which, in my opinion, follow from KISS and DRY.
The Single Responsibility Principle or SRP. The principle declares that every object must have one responsibility, and this responsibility must be fully encapsulated in a class. And must be aimed exclusively at providing this responsibility.
Following the principle usually consists of decomposing complex classes, which do many things into simple ones whose responsibilities for one thing.
Designing classes in such a manner simplifies further modifications and maintenance since it is easier to understand a single block of functionality than complex and a big chunk of code. Also, you can modify it without worry about other functionality in the code.
Following this principle also give benefits in terms of code reuse. Complex objects with complex dependencies are usually challenging to reuse, especially if only part of their functionality is needed. On the other hand, small classes with well-defined functionality are easier to reuse because they are not redundant and rarely entail a significant amount of dependencies.
So it is very similar to the KISS principle. We try to break down the components of the program into minimal logical pieces.
The following helpful principle is The Dependency Inversion Principle or DIP.
The principle declares that top-level modules should not depend on lower-level modules but should depend on lower-level abstractions.
Following the principle, high-level components to be implemented without embedding dependencies on specific low-level classes. It leads to flexible code because it makes it easy to replace dependencies.
For example, your program uses messengers to send notifications. You can initially add a specific Messenger in your high-level abstraction layers. But what happens if it needs to be changed urgently because of its new data policies? That would require changing the logic of the base classes, which is not good - new bugs could get in there, too.
The Interface Segregation Principle or ISP.
This principle stands for the following: clients must not depend on methods they do not use. If the client does not use some interface method, then changes to that method should not require changes to the client code.
Following the ISP principle is to create sufficiently specific interfaces and require only the necessary minimum method implementations.
It gives us more opportunities to make point-by-point changes to our code.
These are the basic principles that I try to use every day in my programs. I intentionally left out two of the SOLID principles because, in my opinion, they are no longer relevant at the moment.
I hope you liked this article and that you will start to apply these principles in your code. They will allow you to write better and more maintainable code. Have a nice coding!