Clean code - clean code is essential
Developers sometimes claim that clean code development takes too long. They say you are much more efficient if you do without too much code quality. "Keep it simple" they say. Clean code is too often seen as a kind of religion. Agile would be ok, but clean code would take things too far. The scope of the principles and practices alone is so large that no normal developer would be able to get through it. KISS, keep it simple stupid! We just write our code as normal and that's it. We've always done it that way!
At the latest when maintaining existing source code, they then realize that the code is not readable. The code is not understandable, tests are not automated, and so software development progresses ever more slowly. After just a few months, a lot of the application has to be changed with refactoring measures. In the end, the clean code developer ideas are sometimes even blamed. If we had simply worked as we always have, the code would have been fine. Just like before.
Clean Code Development
At the turn of 2008/2009, my colleague Ralf Westphal and I have been working on the contents of the Clean Code Developer Initiative published. Our aim was to make a contribution to the professionalization of software development. Our observation at the time was that many things were not running smoothly. A lot has changed and improved since then. But the issue is not over yet. Too many teams still write too few or no automated tests. There are stillย Don't Repeat Yourself (DRY) violations due to massive code duplication. The clean code principles are as important as ever.
Clean Code by Robert Cecil Martin
Our initiative was triggered by the book Clean Codeย by Bob C. Martin. Ralf and I happened to read it at the same time and got into an intensive exchange about it. This gave rise to the idea of creating a collection of building blocks that could help. The book was the trigger for us. The collection of principles and practices is much more comprehensive than what is in the Clean Code book.
Principles and practices
We have divided our collection of 45 building blocks into Principles and Practices. Principles or their violation can be recognized in the code. A violation of the principle Don't Repeat Yourself (DRY) is noticeable, for example, through duplications in the code. The same lines can be found exactly or slightly modified in several places.
Practices, on the other hand, describe tools or work steps on the way to the code. For example, the pathfinder rule states that you should always leave the code a little better than you found it. Or the test-first practice recommends writing a test before adding to the implementation.
Values
Despite the importance of the principles and practices, the question arose, Why you should adhere to them. And we realized that sometimes there can be conflicting forces and you have to choose one principle or the other. So we came up with the Value system. It consists of four values:
- Correctness - The requirements must be implemented correctly.
- Changeability - The code must be easy to change and add to over many years.
- Production efficiency - We have to be efficient in software development.
- Continuous improvement - Developers, teams and entire companies should be constantly evolving.
Every principle and every practice contributes to at least one of these four values. Sometimes more, sometimes less. On our CCD Postcards we have marked this with symbols.
Automated testing
One of the most pressing problems for software developers is testing. You might think that all classes and methods are tested automatically these days. This may be the case in many projects. However, I still come across too many projects in which test coverage is far too low. As a result, everything takes forever. This is because the tests have to be carried out manually for every change or addition. This is of course completely inefficient in terms of maintainability. It leads to resentment among developers, deliveries are delayed, customers are dissatisfied, etc.
So let me put it bluntly: Get your sh*t together!
Gone are the days when you could somehow muddle through without tests. Even if it is not an easy task, it is imperative (!!!) that automated tests are added. Start with Integration testsbecause they are more or less independent of the internal structure.
Legacy Code
What to do with existing code? Is clean code also relevant here? Presumably, old legacy code will not be as easy to read as modern code. The structuring of software has evolved. New patterns and architectures have emerged. Above all, however, legacy code is typically very extensive and has grown at a rapid pace. You don't just turn it into a pretty meadow of flowers.
The solutions are described in many places. Ultimately, the only thing that helps Refactorize in small steps and apply the principles of clean code.
Software Craftsmanship
Is software development really a craft? Going on a journey and learning from the best... There's nothing wrong with that, but it's not concrete enough.
I don't think it's a good idea to compare software programming with the manufacture of a house, car or other industry. Software is so fundamentally different. When building a house, you can't build a basement underneath it. But you can with software. I have noticed that attempts to draw parallels tend to lead us astray.
For me, software craftsmanship is also the wrong association. It's about doing your job as a software developer professionally. But what does that mean in concrete terms? For me, the answer is: adhering to principles and practices! We launched the Clean Code Developer Initiative to enable professionalization with concrete building blocks.
Introduction of the clean code principles
How do you proceed in a team? How do you convince all colleagues? How do you convince the management, the PO, the Scrum Master?
It's not always easy to get everyone in the team on board. Here are some ideas on how to encourage software development teams to consider the clean code principles:
- Coding Dojo - Organize a joint coding exercise. This can be done in ensemble programming (formerly called mob programming). One person takes the keyboard, everyone else thinks along. The role can be changed regularly. Alternatively, several pairs can work in parallel and the solutions are compared at the end. Goal: everyone in the team joins in the discussion.
- Open Space - You can also organize an open space. There is no fixed agenda, but all participants come together themselves to exchange ideas. However, the prerequisite is that you can bring together a larger group of developers. It should be around 30 people.
- External speaker - Invite a speaker to give you a keynote speech followed by a discussion. It is often impulses from outside that get things moving.
- Attend a training course - The team can take part in Clean Code training together. This develops a shared understanding of the importance of clean code principles.
Conclusion
Patterns and SOLID may help a little in some places. But much more is needed to produce code that is adaptable and correct. The principles and practices of clean code development are extensive, with a total of 45 building blocks. We have divided them into levels for good reason. But it doesn't help, every software developer has to go through it. Have fun!
English 
German