How to use Clean Code Development effectively in 2020
Table of Content
This article was originally published on September 9th 2018 by Jenny Dornberger and has been updated regularly.
Which rules should a “good programmer” follow today in order to build high-quality software? When I, the content manager of an IT company, think about the core activity that developers perform – writing source code – naturally the first thing that comes to mind is clean code development.
13 years after the publication of Robert C. Martin’s standard reference, I interviewed our developers to evaluate what clean code development (CCD) can do and what hurdles are encountered when integrating this approach into the everyday life in software development.
One thing is clear: Every software developer has a different educational background, prior experiences, and divergent interests. As a result, developers take different approaches and develop different ways of working over the course of their careers.
Depending on their personality, some developers prefer to follow the code advice of others and hope that they will be able to get by on that (the Jesse Pinkman type). Others take a pragmatic, do-it-yourself approach à la MacGyver: they work by means of quick bug fixes and eschew the perfectionist demand of always delivering good quality code. However, many developers strive to live up to the ideal image of the “Rain Man,” who – as t3n described in its jocular survey – breathes code and can easily overcomes any of the problems that developers typically encounter in their everyday lives by deploying faultless lines of elegant and effortless code. It is these Rain Men in particular who try hardest to introduce more quality into software development as clean coders.
In the end each developer is responsible for making a long-term commitment to clean code principles and practices, so he must be prepared to constantly review his own performance and revise his approach. Therefore, it is invaluable to possess an intrinsic motivation to continuously improve oneself and remain receptive to innovations.
Even in 2008 the concept of “agile software craftsmanship” was already so important that Uncle Bob used the term in the subtitle of his book Clean Code. Software craftsmen who work according to a certain quality standard today tend to utilize various architectural approaches (DDD, SOA, microservices…) and methodical procedures (TDD, CD or pair programming …).
According to conventional wisdom, there is no way around clean code development when working on specific code production tasks.
Our developers told me that at first it took them some time to adjust to the process of rechecking each line of code to ensure that only one level of abstraction was chosen per method, descriptive names were used, instructions and queries were separated, repetitions were avoided, the code was optimally formatted, classes were kept small, etc.
Logically, it makes sense to write code that it is understandable and not too complex from the very start. It should be written to allow interchangeability and explain itself through names that convey meaning. But in our project, too, it was initially felt that this focus resulted in lower productivity. Nevertheless, we believe that this initial investment has paid off in the long term. The focus on clean coding goes hand-in-hand with clear instructions, allowing less room for guesswork and mistakes. It leads to a very structured software development process.
Additionally, customers and users benefit from high-quality and testable code. That is because it is sustainable: clean software can be more easily adjusted and expanded in the future, thus reducing the amount of effort that is expended in the long term. Instead of a disposable product and the expensive process of launching software from scratch, developers can rely on a set of usable functions over the long term that ensure investment security. If developers incorporate the guidelines from the Clean Code book right away they can reduce refactoring and thus unplanned workloads. The code is less likely to contain errors if developers follow the recommendations to continuously test it.
While the permanent productivity gains that you can achieve through clean code development are difficult to measure and prove, we follow Uncle Bob’s argument that the “life-cycle costs of chaos” can lead to zero team productivity over the long run if you do not care about clean code.
Clean code can provide a foundation for applying standards to code, and it can be used to stimulate discussions about how to create a common quality base that can be continually improved. Especially in the everyday life of a collaborative, agile, and growing team like ours, we have found it important to optimize the code for colleagues, who are new to the team or those who may have taken a new and complicated task from the sprint backlog that usually requires additional training.
However, readability is also essential for the original developer himself, because when code is written for long-term projects, it can seem new and unfamiliar when revisited again after a long period of time.
Optimized machine-readable code should only be the focus when it is really necessary, because “premature optimization is the root of all evil” (Donald Knuth, 1968). The fact that the performance of an application that was developed in accordance with clean code development principles suffers due to being broken down into smaller pieces in the code design stage is not a good enough argument for us to renounce the approach.
Today, modern compilers have taken over most of the work to make code optimally machine-readable. The iterative approach and the need to continuously review the written code is deeply rooted in the clean code approach. Both fit very well with agile process models (such as Scrum), which our team lives by.
Implementing clean code development principles on our software development team makes sense for us for several reasons. For example, we plan to continuously expand our open source products, like the Cloudogu EcoSystem or the SCM-Manager by adding new features over the next few years. Further open source projects that we support, like the Smeagol Git Wiki will be improved as well.
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.
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.
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.
It has been made clear that both the individual attitude to your daily work as well as team commitment and discipline, adaptability, and a willingness to learn on the part of all involved team members are key to capitalizing on the long-term benefits that clean code development can bring.
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.