Note: Raw translation - work in progress
The Red Grade
The 1st (Red) Degree of the Clean Code Developer Initiative
The red level starts the journey of the Clean Code Developer. From here you are going to introduce a first part of the Clean Code Developer modules into your daily work. You will practice them over and over. The red level is designed so that any developer here can start with minimal effort. There should be no need to change anything in the project setup. Therefore, you can start the journey "quietly" all by yourself if you want to.
Principles
Don't Repeat Yourself (DRY)
Why?
Any duplication of code or even intermediate steps triggers mistakes and inconsistencies.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| + + | + + | + | + |
| Single Developer |
The DRY principle means
Don't Repeat Yourself. It is valid since the early days of software development - otherwise there would be no sub-programs or data normalization. Nevertheless, it is probably one of the principles ignored mostly. Nothing is easier than to reuse code by copying and pasting. When things need to move quickly this happens even to coders that know better.
When practicing the red level, you need to observe this principle at all times. You are aware when you repeat code or other artifacts. You can identify such duplications, whether they stem from yourselves or others. You will clean duplicated code through refactoring - if there are no other principles or limitations standing against this.
Keep it Simple, Stupid (KISS)
Why?
If you do more than the simplest, you make the solution unnecessarily complicated and let your customers wait.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| + + | + + | + |
| Single Developer |
Or to say it in Albert Einstein's words: "Everything should be made as simple as possible but not simpler.". For keeping code evolveable it is a mandatory requirement that the code is understandable. Simple, clear and easily understandable solutions should always be preferred. It should ring some alarm bells if your if you are not able to understand code anymore that you wrote yourself just a few weeks ago. It is even more important to make your code understandable to other developers. Regular reviews and pair programming can help a lot here. They will verify if the simplest solution possible was actually used.
Technical details often create the temptation to seek a complex solution. The known and obvious is sometimes too "boring" - and suddenly unneccesary complexity slips in. If the simple solution works well, it should be given priority. The same applies to data structures. If an IEnumerable is sufficient, don't use an ICollection, or even an IList.
Beware of Optimizations!
Why?
Optimizations are always expensive. Use caution before you decide to go that route - very often the time is better spent on things that are actually beneficial for the customer.
| Evolvabilty | Correctness | Production Efficiency | Reflection |
|---|
| ++ | | ++ | |
| Single Developer |
MA Jackson
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
W.A. Wulf:
More computing sins are committed in the name of efficiency
(without necessarily achieving it)
than for any other single reason - including blind stupidity.
Focus on writing comprehensible code. Optimized code is often anything but readable. Being reduced to the absolute minimum in the shortest form, such code may well meet the functional and non functional requirements of the customer - but soon nobody will be able to tell because of the lack of clarity.
This is counterproductive for the long-term maintainability of the software.
Donald Knuth wrote in 1974: "
We should forget about small efficiencies, say about 97% of the time. Premature optimization is the root of all evil'(Knuth, Donald
Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974 p.268)....
Following the Boy Scout rule does not mean that you should strive for more and more code optimizations. It relates rather to the contrary: Improve clarifty and evolvability.
Think twice before you try to extract just one more bit of performance via optimization - even if it feels compeeling. It could be that you have to sacrifce clarity for that, and at the same time it might be that the optimization is not even necessary, i.e. it will not have a measureable impact.
If the performance problems are not local to certain areas and are therefore special cases,then it is most likely a fundamental structural problem that you are dealing with. In that case, the next major refactoring should take care of them probably anyway. Or the next-generation hardware is going to iron out the performance kink. Does the customer even care? Optimizations need to solve real the customer issues. Don't change code without knowing the business benefits. In the end, you're going to be paid for the real business valure.
To opt against performance optimizations when in doubt has a more fundamental basis: YAGNI -
You is not gonna need it. This rule is in its full expression, however, only part of the
blue grade.
PS: If - considering to all warnings and concerns - a performance optimization is unavoidable, you should alway start with a detailed analysis using a profiler. Only by the use of a profiler you will be able to identify bottlenecks as well as beeing able to show their removal after the optimization.
Favor Composition over Inheritance (FCoI)
Why?
Composition promotes loose coupling and testability of a system and is usually more flexible.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| + | | | |
| Single Developer |
Object-Oriented Programing (OOP) has too well known candidates for the reuse of functionality: Inheritance (whitebox reuse) and Composition (blackbox reuse). If you try to reuse code by inheriing from a class you will make the subclass dependent on the parent class. This makes a system in many cases unnecessarily complex, less testable and makes the exchange of functionality at run time unnecessarily hard. As a CCD you should follow the Liskov Substitution Principle (LSP) when you need to decide if inheritance is appropriate.
Composition means that one class uses another. You will further promote decoupling by defining the interfaces clearly. That will also give you the advantage that implementations can be easily replaced. So before you start applying the Liskov Substitution pronciple, think about the Favour Composition over Inheritance concept and ask yourselve why you shouldn't prefer composition right away.
"
Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)
Practices
Follow the Boy Scouts Rule
Why?
Raise the bar just a little bit whenever a piece of work is touched. Get there completely free of bureaucratic planning. A grass-roots approach to improved quality.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| ++ | ++ | + | + |
| Single Developer |
You can't establish the Clean Code Developer value system all at once - it requires time. As a Clean Code Developer you rarely work on a greenfield and also rarely work by yourself. Therefore it is difficult to apply the CCD principles to an entire code base. We therefore believe that it is important not to aim too high. You will find it much more motivating and practical to seek small improvements only - as long as you continously do so.
The Boy Scouts Rule therefore belongs to the foundation of Clean Code Development principles and practices. It can also be found in
Clean code and reads:
Always leave the campground cleaner than you found it.Applied to software development this means: The Clean Code Developer always leaves his work item in a "better state" than they found it. When finished the code has been moved just a little bit further towards compliance with the Clean Development Code value system.
What exactly you need to do is of course dependent of the code and the situation you are in. It is also determined by the grade to which you work. For example in the red grade you would ensure that code not maintained in a version control repository before is now stored there. You would also make sure that repetitions of any kind - violations of the DRY principle - are "ironed out".
As a Clean Code Developer, whenever you become aware of violations of the CCD value system, you will try constantly to improve or completely remove them. Step by step. And of course you will avoid writing sub-optimal code from the outset - based on the grade that you currently work in.
This practice is critical at the begin of the journey to become a Clean Code Developer. It works against the implications of the
Broken Windows Theory which states that the road to total neglect begins with small issues that aren't taken care of in a timely manner.
If you choose to follow the Boy Scout Rule, you will not let "Broken Windows" happen in the first place - you will fix one issue after the other. You will smooth "cracks and bumps" in the code consistently on the basis of the CCD system of values, so that no additional "deposits" can accumulate. You will thereby proactively prevent code erosion.
We think that this practice is so fundamental that we included it in the red grade.
Root Cause Analysis
TBD
Why?
Treating symptoms only may bring fast relief - but in the long run it is more costsly. Always look beneath the surface of the problems, This will make you more efficient in the end.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| + | | | ++ |
| Single Developer |
Usually from the first day as a Clean Code Developer should be on looking for problems to more intensive search of the true root of evil. Clean Code Developer are not satisfied with a Symptomkur.
Example: The sorting of data in memory is too slow. A superficial treatment would now move to accelerate individual statements or statement blocks. Perhaps the use of unsafe code will be tried, perhaps a parallel. A closer analysis of the problem would arise, however, that a sub-optimal algorithm is the root of evil. Optimizations are difficult to understand at a low level of abstraction can be thus avoided. A better algorithm is the clean solution.
Root problem analysis is therefore a service to the course and the effort. Because if you know the root problem, the cleanup is usually less expensive than a Symptomkur. The performance by the Clean Code Developer on a problem, so he keeps holding the first, to give yourself a chance to look behind the symptoms.
The Root Cause Analysis is also known under the name Five Why's. This term comes from the terminology of the Toyota Production System (TPS). The basic idea: ask at least five times, "Why?".
Use a Version Control System
TBD
Why?
Fear of damage to a "running system" paralyzes the software development. With a version control such fear is unfounded. The development can progress quickly and boldly.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| | ++ | + |
| Single Developer |
An indispensable prerequisite for any Clean Code Developer is to provide its code under the protection of a version control system. Whether the Mercurial, Git, Subversion, VSS, TFS, or vault, is irrelevant. We only mean that today, no work on code should be more done without him to care in a version control system. The reason is quite simple: A version control system, freed from fear. Freedom and fear is necessary to boldly implement the principles and practices of the CCD system of values.
A version control system takes the fear that something is wrong, and thus to ruin. When code is kept in it, each CCD change the code at will, without fear of destroying an achieved status. Nothing is lost. The version control system is like a time machine for code.
Thus, a version control system, the very best foundation for all learning. Because learning means making mistakes. With a version control system as a safety net, we can allow ourselves any errors. So: The first prerequisite for entry into the Clean Development Code is the constant use of a version control system.
Where the project is not possible, we see the foundation for Clean Development Code absent. We would not even understand why the use of a version control tool should not be possible. Costs must be incurred and not for the learning curve is minimal in the simplest functions. CCD writes yes no particular use of a version control system, but only that one must be used.
See also under
Tools.
Apply Simple Refactoring Patterns
TBD
Why?
Code is easier to improve if we know typical improvement handles. Your application scenarios make sensitive to weak points in your code. As a recognized pattern, they strengthen the courage to use it.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| ++ | | | + |
| Single Developer |
To code a little more to leave better than you found it, more or less intervention is required. The developer can make a clean code, thanks to the version control system without fear. But how does he do the job as easy as possible?
The key word is "refactoring". Has
Martin Fowler, the as described in his book of the same basic technique to increase the code quality. He defines this as a number of code patterns of change to "code smells", ie suboptimal structures or general disregard of principles to clean up.
For the degree of red in it is mainly the refactoring
Methode Extract relevant in order to satisfy the DRY principle. The contact Clean Code Developer to occur several times to extract code into a method that is called instead of the repetition of its locations.
The second refactoring should be at work at the level of the red
Umbenennen are used where necessary. And fits the scout rule, because one often encountered "filth" in the source code are cryptic names.
Refactorings can be applied by hand, but there is also tool support. Modern IDEs like Visual Studio provide some Refactoringmuster, our lists other tools
Tools List.
"Refactoring" like "Clean Code" belong to
required reading Clean Code Developers from all the red level.
Reflect Daily
TBD
Why?
No improvement, no progress, no learning without reflection. But only if reflection is also planned, she finds under the pressure of daily business also held.
| Evolvability | Correctness | Production Efficiency | Reflection |
|---|
| | | ++ |
| Single Developer |
In the center of the CCD is personal development. It is about change: With each day to the CCD value system manifested a little bit more in the everyday life of the Project Clean Code Developers. This is the rule of the Boy Scouts Clean Code Developers applied to itself.
Such a Veränderungsweg goes alone, however, just not easy. So how to stay on track? How do you measure progress?
Without establishing a "monitoring system" to want, we believe that this is twofold:
- Small-step planning
- Reflection after each step
Regardless of target by a project manager should Clean Code Developer divide their work so that it consists of tasks that must be overcome in one working day. Only in this way in the evening, each day a balance to be drawn. We think this is important to work every day not having to carry home in the evening. Since she has no business, which serves to relax.
By such small steps in the planning work everyday is not only satisfying, however, because each day can determine success or failure. The very possibility of choice in the evening -
Do I have all my tasks done? As I have done my job- also allows the reflection on the compliance of the Clean Code Developer value system.
In order to consistently develop a Clean code developer, the developer should be put on every level after each working an account of whether he has considered all relevant aspects for him on the level of the value system. For the degree of red means e.g. Questions like: I really Manage all code fragments in the version control system? I've applied the DRY principle consistently? I generally leave code in a better condition than found?
If he on any of these questions then are reluctant to answer yes or no with no one must of course that is not the end. In all our efforts, it works just does not always mean you can translate the goodwill into action.
Nevertheless, or perhaps because of it, however, is to do the following:
- Improved either the Clean Code Developer for now, until he perceives in relation to his day job no more principles injury.
- Or he takes the recognized principles of injuries for the next day on his task list.
An aid to reflection, the Clean Code Developer
bracelet be. We are aware that it is not for everyone to wear a colorful silicone bracelet. Who has thus no problem is to use the bracelet as part of personal reflection. Can not or will not clean up the Clean Code Developer principles of injury or taking notes on his work, he should change the bracelet he wears, from one to the other arm. He makes it clear that he is a difference between the target and its degree Made it recognizes. This is not a defeat or even misunderstood as "repentance". It is rather a haptic support the learning process.
If a Clean Code Developer for 21 days no longer change after work had the bracelet, he can go to work the next grade. For the red level is that of the
degree orange.