Clean Code Development – Blue and white

In the final part of our blog series, we complete the learning cycle on clean code development, i.e. the development of clean, easy-to-read, easy-to-upgrade and easy-to-maintain code. The previous blog posts covered the basics of clean code development and showed what the different degrees of clean software development emphasize.

The different degrees of clean code development

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

In addition to these 5 levels, there is another level that rounds off development within the framework of clean code development: The white level. This level is primarily for reflection and symbolizes the beginning and end of clean code development.

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 5: Blue

The blue degree also focuses on aspects of software development beyond code and tools. Developers should not only build good structures on a small scale, but also plan them on a large scale from the outset. This refers to the software architecture, which is supported by the following principles and practices:

Principles

Design and implementation don’t overlap: A common problem in software development is implementations that no longer reflect the previous planning. Ideally, such inconsistencies should be minimized by separating the responsibilities between design or architecture and implementation.

Implementation Reflects Design: The implementation should not exist independently of the design or architecture. Components that were defined in the architecture, for example, should therefore be physically separated in the code.

You Ain’t Gonna Need It (YAGNI): Is a certain functionality really necessary? Requirements for features are often still too vague or turn out to be unnecessary in the further course of development. If in doubt, premature or unnecessary effort should be avoided.

Practices

Design before implementation: A solution must be designed before implementation. Otherwise, there is no consistent thinking about the solution.

Continuous Delivery (CD): The setup and deployment development phases must also be automated. This is the only way to ensure that installable software is produced. Automation minimizes the chance of developers forgetting an important step that needs to be carried out “on foot”.

Iterative development: Development in iterations and short feedback cycles are two key success factors in software development. They reduce the risk of undesirable developments and increase the quality of the software.

Incremental development: A vertical slice through the various aspects of a software system is called an increment. An increment is therefore a piece of executable software and can be made available to a product owner on a test machine in order to obtain feedback.

Component Orientation: Component-oriented development promotes productivity through parallel implementation, improves the clarity of the application and makes it easier to test the individual components.

Test First: This practice says that interfaces as well as a corresponding desired behavior are described by tests. This approach simultaneously produces the specification documentation in the form of executable code that can be checked automatically.

Grade number 6: White

As described at the beginning, the white level is the beginning and end of clean code development. The white level combines all the principles and practices of the colored levels. Developers who have reached this level are constantly working on all facets of the value system.

Theoretically, people have reached the end of the development process at the white level. However, as it can be assumed that the many principles and practices will not be remembered permanently, the general recommendation is to start the clean code development cycle again from the beginning after around 3 weeks. Starting with the red level, developers can concentrate on a specific section of the value system again and refine what they have already learned. Ideally, this is a continuous learning process.