featured image Clean Code Development Part 2: Why and how we implement it

November 02, 2018 / by Jenny Dornberger / In Quality

Clean Code Development Part 2: Why and how we implement it

In the first part of this blog article we explained why we think it is worth practicing clean code development. In addition, it became clear that “software craftsmen” in particular have an interest in writing clean lines of code, and that these types of developers can work particularly well in agile teams. In this follow-up article, we will summarize the positive outcome factors again before answering the nitty-gritty question of “how” you actually implement this code philosophy.

Why we decided to focus on clean code development

Implementing clean code development principles on our software development team has made sense for us for several reasons. For example, we plan to continuously expand our product, Cloudogu EcoSystem, as well as some of the open source projects that we are involved in ( SCM Manager and Smeagol) by continually adding new features over the next few years. Clean code development helps to maintain flexibility over the long term. From the very beginning of the process, cleanly developed software is better able to be continuously adapted to meet new requirements while maintaining its core functionality. The increased complexity that comes with releasing such an iterative product brings with it challenges that can be more effectively tackled with readable code. We have learned from our own experience. There is a big difference between a situation where a single developer with a good idea and a small product that he knows “like the back of his hand” needs to make adjustments to this product and another situation where a complex platform with an ever burgeoning range of features that is intended for a growing number of users must be maintained by an ever expanding development team.

Implementation through checklists and ensuring compliance with principles?

We consider it useful and important to regularly reflect on the best practices of Robert C. Martin’s book in everyday life. We consult the book as an accepted reference work. Nevertheless, we believe that using checklists and ensuring strict compliance with principles do more to sap motivation, because not all rules can be stubbornly applied to every IT project and every situation. If the practices are restrictively enforced and forced on developers by managers, the clean code idea will fail. For example, there are generalizations in the book that should be treated with caution. For example, the book stigmatizes comments in some places as being indicative of code smell. This attitude might suit developers who are lazy about writing comments. However, there are complex issues and contexts that cannot easily be expressed in self-explanatory code. In this case, comments are quite necessary and useful. In a valuable blog post on this topic, the author advises beginners not to focus on the “what”, but rather to pay attention to the “why” when commenting. Comments should be used to explain why the developer chose to write the lines of code in particular way and not in some other way.

How we implement clean code

We here on the Cloudogu team have integrated the ideas and tips proposed by Robert C. Martin by adopting many small measures into our development process. We include the print version of the bestseller (either the original American version or the German translation) in our welcome package for new employees. New team members happily accept the implicit suggestion to read it and to digest it (and to reread it, if necessary) during the induction phase. This way they are able to make good use of their time until they are usefully integrated into the sprint planning.


René Pfeuffer shared the following with us: “As a new member of the team, I am reading a lot more code than I am writing during this initial training phase. Cloudogu’s clean code approach has guided programmers to produce lines of code that I have been able to easily understand right from the start. This approach has really helped me to get used to the new product, which is quite complex, and to become an active contributor myself.” In practicing agile on a daily basis, we have also embedded peer reviews firmly into our development processes. At the end of each story, each line of newly written code is checked for readability by “a second pair of eyes,” and potentially “dirty” code is discussed with the author and refactored. Since the result of the review depends on the experience of the reviewer, the clean code principles provide a solid foundation that anyone can acquire relatively quickly. This way, everyday coding within the team is continuously improved.

Unit testing is a matter of course under the clean code approach. Existing unit tests are valuable in development because they allow newly written code to run in isolation and pass through many execution paths. The particular benefit of existing tests shines through in code maintenance: These automatic regression tests ensure that existing functionality is not compromised after product expansions or refactorings. The team here at Cloudogu has also come to recognize the long-term benefits of this approach, which is why we do not question the value of unit testing. Each developer can decide for himself whether these tests are test-driven or written after implementation. Experience has shown that writing test cases before development provides better technical coverage. In addition to unit testing, we run static code analyses that verify best practices in code and identify common error patterns. The static code analysis metrics, together with the results of the unit tests and code coverage, are incorporated into a central platform. There, these metrics are verified against a quality goal (for example, code coverage should be >= 80%). We only consider the process to be completed if these conditions are satisfied. At Cloudogu, we chose SonarQube, because it is open source, which is one of our philosophical beliefs, and it uniformly supports and displays our different technological environments (Java, JavaScript, Go, etc.). In addition, we regularly conduct ad-hoc trainings on the topic of clean code at our knowledge base meetings to discuss specific lines of code with members of the team and to agree on a joint plan of action. Last but not least, our agile development process is of course further optimized after every sprint.

Our conclusion

We believe that clean code development provides an implementation approach that can be deployed directly within the code. When combined with agile methods and a security concept, it is the right way to produce high-quality software. Even team discussions about what exactly do we mean by “clean” software in a particular situation are valuable for achieving understanding. When implementing the approach, it helps to have many intrinsically motivated software craftsmen on your development team who not only support the project, but can truly advance it through their commitment. According to our understanding, however, the leaders who are responsible for implementing principles should know when to accede to best practices taken from a standard reference work and to embed them in a targeted way in their day-to-day (agile) processes.


Jenny Dornberger
Jenny Dornberger

- Marketing Manager -

She tries to explain the world of software development for customers and applicants - and she certainly doesn’t shy away from the technical topics either!