SOLID principles have long been considered to be the basic rules of how to build IT systems that are easier to change. For all its virtues, however, SOLID does complicate the architecture of the software, and this increases the risk that the source code becomes harder to read and understand. At CodeImprover we focus on making the code easy to read and maintain. Pairing SOLID principles with the ease of CodeImprover makes for a powerful combination.
Agility is about the ability to change. In the field of software, agility means having a dynamic developmental process as well as the ability to develop code that is suitable for being changed. This requires code that is easily readable and understandable.
One of the frontrunners in the agile movement is Robert C. Martin, who has written some ground-breaking works and has come up with the concept SOLID which is an acronym for the five basic principles of writing code that is suitable for being changed.
To give you an idea of the complexity
Of writing modern agile software, the five SOLID principles are summarized briefly below:
SOLID stands for: Single-responsibility principle, Open–closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle.
- Single-responsibility principle
Classes and methods must be designed to solve one task and one task only. When this single task is to be changed, it should only be changed in one place in the code. This provides clarity and minimizes the risk of mistakes. One considerable challenge associated with following this principle is to define the scope of the one task to be performed.
- Open–closed principle
Basically, this principle means that systems should be designed in such a way that the behavior of the system can be changed, not by making changes in the existing code, but only by adding new code. The implementation of this principle produces a greater degree of flexibility but requires advanced coding techniques.
- Liskov substitution principle
This principle is technically advanced and is typically associated with classes and interfaces. According to this principle, all “class children” and “interface” implementations can also be used in all of the places where the calling code is expected to meet the “class parent” or the” interface” itself. The principle is an integral feature of object-oriented C# programming.
- Interface segregation principle
High-level code should not depend on code that it does not use. For example, a lower-level method that solves two tasks must be called, even though the code that calls only needs to perform one of the two tasks. In practice, the calling code depends on some code that it does not use. Like paying the expenses of an entire block even if you only use one apartment.
- Dependency inversion principle
Classic programming builds code from the bottom up. The low-level modules are coded first. Above them, the more advanced methods are built, which call the basic methods and so on. Dependency Interjection consists of techniques that delay the decision on exactly what basic layers are used. The decision is delayed from (the classic way) development time until execution time. Think of a crane truck. Lifting while being on solid ground, only the standard support legs are called. The same crane lifting while being on a soft surface must call for more comprehensive support. The decision is made on lifting (execution) time.
Dependency Interjection depends greatly on the L in SOLID and is the foundation of the development of plugins and is itself the foundation for the O in SOLID.
For those who are not software developers, the descriptions above can be hard to follow, and that makes it hard to know if the developer has translated the principles into source code of good or poor quality. That is, whether they have produced neat and tidy source code or whether they have left a pile of entangled ‘spaghetti’ which may well function, but which is impossible to navigate.
CodeImprover – an effective tool for evaluating code quality
There is no sure method of determining whether the quality of a source code is good or bad, but by conducting an analysis of the code on the basis of a number of parameters and measurements, you can get an indication as to whether there are problems with the code quality. If the analysis does not show anything bad, then there is good reason to believe that the code is of good quality.
CodeImprover offers a free GitHub app that automatically produces code quality measurements every time code is pushed to GitHub and every time a pull request is made on GitHub.
When the CodeImprover app is installed in your GitHub code base, the developer receives ongoing feedback on the code quality and gets specific insight into how the code could be improved. Architects and lead developers who are responsible for merging code receive even more specific measurements of the quality of code in pull requests. In this way, you can avoid merging code that lowers the quality.
Read more about code quality and CodeImprover’s free GitHub app here.
1 Comment