SOLID principles beyond theory

How to apply SOLID principles in real projects

Most of us have probably heard about them, read them, or even learned about them at University. They are considered the “basic building blocks” of any sane software project, the “guardian angel” of maintainability. However, SOLID principles are not something we, including myself, would like to keep memorized. At least not the exact wordings of them.

For example, the ‘L’ in the acronym refers to the ‘Liskov substitution principle’. This is the wording from the original paper:

Liskov substitution principle - Wikipedia

Even after studying the principle quite deeply, when reading the statement, I must stop at every word and ‘digest’ it to understand again the logic behind it.

Other principles wordings are more or less similar and, therefore, hard to understand at first glance.

If the SOLID principles are so deeply theoretical, is there any practical way how we could apply them in real projects, so we are able to benefit from their potential?

After several hours of consultations with my experienced colleagues at ableneo, and after I saw the SOLID principles videos of Robert Martin’s Clean Coders, I will try to describe one possibility of a practical SOLID attitude.

Clean Coders : Level up your code.

The motivation to speak about SOLID and software quality, in general, is, in my opinion, the significant risk that a project fails to the costs of changes. SOLID principles can help to avoid this scenario because SOLID principles keep the primary value (a.k.a. ‘softness’ or changeability) of software high (besides that, the secondary value of software is the current behavior of the software or its ‘features’).

In other words, if we want to work on more meaningful projects with more impact, more added value, more fun, more economic success, and more everything, we as developers must protect and iteratively improve the primary value of the software. Even when there is the infamous ‘pressure on delivery’, we still take responsibility for the quality and maintainability of the code we produce. Especially in long-term projects.

Therefore, to be SOLID compliant, an initiative from the developers’ (or Software Crafters’, if you will) side is required (solving problems using SOLID, bringing benefits with SOLID, and speaking about them).

In an ideal world, the goal is to live the principles daily. We want the team to have the principles in the back of their heads and to use them instinctively. We don’t need people to be able to cite the exact wording of the principles at midnight.

We achieve this, which may now sound obvious, by regular public speaking about good patterns and how we fixed the bad ones using SOLID. For example, on a technology workshop, an ad-hoc call, a Pair / Mob Programming session, or during a code review.

Example from the project where I work: line 43 is problematic because the general TableComponent must not know about its various subtypes because we would end up adding more ‘ifs’ every time there is a change in table types. This may cause an unsolicited impact on the consumers of the TableComponent.

I emphasize the importance of speaking about the benefits we achieved by the application of a SOLID principle and what problems we solved or avoided. It is recommended not to start with a technical description such as: “hey guys, have you heard about the Interface Segregation principle? It goes like this: no code should be forced to…, and I think we should start applying it.” We can rather mention later after the work is done, what principle was used.

In conclusion, my golden rule for SOLID principles I’m trying to stick to is:

SOLID principles should be indirectly and instinctively used by individuals or teams as a good habit that brings benefits, not as a directly enforced rule (just like Pair Programming).

And now, when we use SOLID instinctively, it would be interesting to look at the impact of SOLID principles and possibly improve it! How could we do this? Well, one way is to be “able to measure it” — if we can measure it, we can compare it — hence be able to evaluate the change afterwards. We are working on this, and in the following articles, we will discuss the impact of SOLID principles on projects and how to measure & evaluate & improve the “SOLID instincts”.

SOLID principles beyond theory was originally published in ableneo Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.