Clean code development – yellow and green

Our blog series on clean code development – the development of clean, easy-to-read, easy-to-expand and easy-to-maintain code – continues. The previous parts have introduced the basics of clean code development and have already shed light on the first degrees of software development.

The different degrees of clean code development

This time in focus: The 3rd and 4th level of clean software development – also known as green and yellow. There are a total of 5 development stages, which are color-coded. Stage 1 is marked as red and stage 2 as orange. The colors yellow, green and blue characterize the other 3 stages.

At this point, it should be noted that the grades do not express a value. People working on the blue level are not “better” than developers who are currently on the yellow level. The development levels merely serve to divide the entirety of the value system as well as the principles and practices into individual, easily digestible learning stages. The different levels of Clean Code Development are also repeatedly passed through in order to enable a continuous learning process.

Grade number 3: Yellow

Automated tests are at the heart of the principles and practices of the yellow level. Unlike the orange level, it is no longer just about surface tests but about in-depth check-ups. The smallest possible units should be tested in this level.

The following principles and practices are helpful here:

Principles

Interface Segregation Principle (ISP): A client should not depend on details of a service that are not needed. An interface should only contain things that are really necessary to make the coupling between different components clear.

Dependency Inversion Principle (DIP): High-level classes must not be dependent on low-level classes – however, both are allowed to be dependent on interfaces. Interfaces, in turn, should not be dependent on details, but details should be dependent on interfaces. In this way, coupling can be avoided.

Liskov Substitution Principle (LSP): Derived subtypes must behave in the same way as their base type, whereby subtypes may extend, but not restrict, the functionalities of the base types.

Principle of Least Astonishment: Software development is a creative process that requires a high degree of concentration. Interruptions of any kind therefore distract from the actual work and should be avoided as far as possible. This is the only way to ensure that errors do not creep into the code due to carelessness caused by unnecessary interruptions.

Information Hiding Principle: Hiding details in an interface helps to reduce dependencies. The more details are visible, the higher the coupling between a class and its users. Once a detail of a class has been used, it becomes more difficult to change this detail. This stands in the way of the software’s changeability

Practices

Automated Unit Tests: Unit tests check whether the developed components work as intended. Automation saves time and tests are actually carried out.

Mockups: In order to be able to test individual components in isolation, dependencies need to be eliminated. So-called mockups or test dummies are used for this purpose, which interact with the component to be tested because, for example, the desired object is not yet available.

Code Coverage Analysis: To find the parts of the source code that have not yet been sufficiently checked by test cases, the code coverage analysis is performed. The analysis shows which instructions, branches, paths and conditions have not yet been tested.

Participation in professional events: In addition to reading specialist literature and exchanging ideas with other developers, participation in professional events serves to further education in the field of software development and is an important part of the clean code approach.

Complex refactorings: Simple refactorings are already part of the red level. In the yellow level, complex refactorings can now also be used efficiently and risk-free in conjunction with automated tests.

Grade number 4: Green

Even more automation. This is the motto or goal of the green degree. A high level of automation helps the software developer to concentrate on implementing customer requirements. Without existing automation, development is otherwise too often hung up on minor details that cost a lot of time. Correctness checks and releases are then more of a punishment than a means to success.

The following principles and practices should therefore be used for this degree:

Principles

Open Closed Principle (OCP): Classes should be open to extensions – but closed to modifications. This minimizes the risk of destabilizing a previously error-free system with new features.

Tell, don’t ask: Instead of asking an object for data in order to interact with it, this principle is intended to tell the object what it should do. In this way, data can be bundled with the functions with which it works.

Law of Demeter (LoD): The interaction of objects can be limited to a healthy level using this method. According to the Law of Demeter, objects should only communicate with other objects from their immediate environment in order to reduce coupling. The principle does not have to be used for pure data storage classes.

Practices

Continuous Integration (CI): The integration of software components is often postponed and ultimately carried out manually in a time-consuming and error-prone manner. However, software should actually be fully operational at all times. Continuous integration therefore refers to a process that ensures that the entire code is translated and tested after changes have been submitted.

Statical Code Analysis: Briefly broken down, this practice can be described as follows: “Trust is good – control is better”. The more automatic this control is, the easier it will ultimately be.

Inversion of Control Container: As an extension of the Dependency Inversion Principle mentioned in the yellow level – in which dependencies were still resolved manually – the Inversion of Control Container takes the next logical step and resolves dependencies automatically. Two methods are available for this: Locator and Container.

Share Experience: Those who pass on their knowledge not only help themselves, but also other people. It is only through the transfer of knowledge that true reflection and penetration of a specialist topic takes place. As a rule, everyone involved benefits from this.

Error measurement: If you know how many errors occur, you can change your procedure so that the error rate decreases accordingly. The comparability of the measurement is more important than the precision.