Clean Code Development: The Grades
Clean code development is divided into different grades, which you as a developer climb one by one and repeat in an eternal cycle
Software solutions should normally exist over a longer period of time and be able to be further developed at short notice with reasonable effort. However, time does not stand still. Framework conditions are changing, be it the IT infrastructure, the operating system or the actual requirements for which the software was developed, or the technical innovations and innovations. Software solutions must be able to react to these changes — and do so sustainably. Because the older a software is, the more complex and therefore more expensive changes to the source code become. And that is exponential growth. As can be seen from the name, changeability describes the ability to react flexibly and sustainably to external change. However, this ability cannot be implemented retrospectively in a software solution, but must be incorporated into the development process right from the start.
Conclusion: There is no software maintenance and no proactive maintenance! The code structure must enable and encourage changes and the costs of a feature must not increase (exponentially)!
Software must be functionally correct, just as a spreadsheet must calculate correctly, for example. And the non-functional requirements must also be met. The program must be careful with resources such as memory, processor time, disk space, etc., and the response times must be within a defined range. Only when all requirements have been met is the created software correct. The question is what is actually being done to ensure accuracy. In our opinion, it is not enough to run software after it has been created through a testing department whose task is to find errors. We believe that correctness must be considered during development. All developers must address the issue of correctness and in order for them to be able to do that at all, they must be aware of what the requirements are. Developers are tasked with implementing a feature without being told precisely what the acceptance criteria for the feature are. Here, it is the developer's job to ask questions if requirements are unclear and to define them firmly. Because the developed software is only correct when all requirements have been met.
Conclusion: Sure, but correctness must be taken into account during development and the requirements must be clearly defined for this.
In the end, the development time and price of the software also play a role. And this is higher when the software is not produced efficiently. This starts with manual work steps that are not automated and ends with high error rates that require repeated improvements. Ultimately, production efficiency means that the software can be developed over years or even decades, instead of having to start all over again at some point. At the same time, high production efficiency reduces the risk of errors. Production efficiency as a value is also important in order to establish a moderate relationship between the other values. Anyone who puts an infinite amount of effort into correctness is also doing something wrong in the end.
Conclusion: Aim for maximum automation!
Development is not possible without reflection. Only those who reflect on how they solved a problem can determine whether the chosen path was easy or difficult. Learning is based on reflection. In a young science such as computer science, it is important to constantly take new findings into account. This requires reflection at all levels. Starting with reflection through implementation in pair programming or code review, reflecting on the team on a daily basis, reflecting on each iteration, to reflecting the entire industry on what it is doing. Without reflection, there is no development.
Conclusion: Clean Code Developer learning is based on reflection, which covers all levels, as well as in pair programming and code review.
Principles are fundamental laws for structuring software. Code should always be consistent with a maximum number of principles. Where a principle is not respected, there is therefore not necessarily an immediate negative effect, but in the short to medium term, violations are not without pain. You can always see from the code whether a principle has been complied with.
Practices are techniques and methods that are used all the time. They describe what Clean Code Developers implement in practice. The motto of the practices: “Always do it this way. Every day, anytime. “These are solid instructions that sometimes require the use of tools. You can't always tell from the code whether a practice is being followed.
Clean code development is divided into different grades, which you as a developer climb one by one and repeat in an eternal cycle
To become a Clean Code Developer, you need to internalize a number of virtues: Appreciate variation, only do the bare minimum, isolate aspects etc.