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.
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.