Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
So says the title page of Clean Code – before even a foreword or introduction.
If you are object-oriented programmer you will have heard of Uncle Bob’s book, Clean Code. If you have read Clean Code, you’ll know that there are lots of signs of a poor design that you can attack in order to improve your code; to make is cleaner. If you are an object-oriented programmer who hasn’t read this book, it is imperative that you do so as soon as you can. Clean Code is the fundamental, minimal, shared coding standard between all curly-braced object-oriented languages.
So on the understanding that we all have a similar idea of what clean code looks like, let’s talk about shooting at invisible ghosts.
There are two common times where teams try to introduce design into their code.
- Before they write it (often called “Design”)
- After they write it (often called “Refactoring”)
Up front design works great for abstract ideas, architectures, and general principles; but it sucks for low-level code design. If you try to design a code change up-front, you solve invented problems and miss real-life problems. Your design may be worse than the duplication!
You can’t manage what you can’t see.
So say Jim Benson and Tonianne DeMaria Barry, authors of Personal Kanban.
The only way to get a good low-level code design is RED-GREEN-REFACTOR, where you go from RED to GREEN without any design at all, then go from GREEN to nicely refactored code when you can see the actual duplication that needs to be removed.
Trying to prevent duplication from occuring in the first place is actually close to impossible because it depends on you predicting where it will occur. Fixing duplication during refactoring is easier because you can see the real problem that needs to be solved, and you can solve it without also having to think about the original behaviour your code was trying to create.