I do a lot of clean code workshops these days; it seems that, finally, clean code gets the respect it deserves. Clean tests too.
There’s one point I make (a few times even) during the workshop: While I give a lot of examples of what people think makes clean code, it’s eventually up to you. Ok, not just you, you and your team.
What I hope comes out of the workshop is when people come back to their work and code, they start to develop their “this is how we code here” method. They can pick and choose from what they learned or choose whatever they want to conserve.
But what the team picks needs to be enforced. If the decisions are not enforced, there’s not much point in them? People will just keep writing code the way they did before. Maybe they’ll feel a bit guilty at first, but since no one demands that they change their ways, that feeling will pass. Quickly.
The simplest way is to pick a couple of patterns and make sure they are addressed in code reviews. When the team starts coding according to these patterns, and there are fewer and fewer comments about them in code reviews, you can move on to other code smells.
The trick is focusing on a very small number of things consistently and fixing them. Use them as a teaching and enforcing mechanism, embed the behavior, and then repeat.
You can go at it alone. But once someone tramples over your code, you’ll understand that clean code is something you do together. As a team.
And if you really want to learn how to write some clean code and tests, check out the Clean Code workshop. Not just for you, it’s a team activity.
You are also more than welcome to join my FREE ZOOM WEBINAR on June 28th, 5 pm, CET
“How to fix A bug” don’t forget to register to assure your place
See you there