Having a clear picture of how your code should look is crucial in times when communication is reduced to a minimum and direct human interaction is hardly possible. Understanding and applying the fundamental principles and practices can make life as easy for you and your peers as possible right now.
Most professional developers probably already stumbled across the terms “Clean Code” and “Clean Architecture” within their career. But do you actually write Clean Code? Do you apply all these principles and practices in your everyday work or is the first draft of code “good enough” for now, most of the time? How often do you catch yourself thinking: “Oh, I will clean it up later”?
As time goes on and the more often the answer to this question was “yes”, the more in trouble you get. There are many definitions and opinions on what Clean Code is. There are individual styles per developer, team or company, and also distinct “best” practices, which seem to be “the must haves” in a git repository. So, how do you accomplish a clear (and clean) picture for every developer involved? How do you prevent the formation of the well-known “islands-of-wisdom”, where the only one who knows what’s going on is the writer themself?
Where to begin
As the title of this post states, when working as and with professional developers, it should be less about actual teaching or learning the hard-facts regarding “how to write good code” and more about being aware of them and being mindful while working on various tasks. There can be lots of disturbances throughout a workday, but if you can successfully establish the habit of thinking one second longer about the code you are about to write, you will see a change – and hopefully a positive one.
Clean-Code-Fridays
My team and I have been taking some time (usually around half an hour) to cultivate a weekly Clean Code topic for 6 weeks already! But we don’t just list up random topics that come to our minds, we “take part” in the Clean Code Developer initiative. This site provides awesome guideline-like content to follow. By discussing one or at most two topics at once, we are working ourselves up the different degrees that can be reached. It is pretty much like becoming a Coding-Ninja!
Our Agenda
We first discuss the previous topic and present code we found within our system, which are either a good example or violation of the weekly principle or practice in question. In case of a violation we try to figure out how we could improve the code, but we don’t do that without asking: Why was it done that way, is there a reason for it?
It is always a great opportunity for everyone involved to learn something new, talk about struggles and ideas, and also to get inspired by your peers.
Additionally, to the presentation on Friday, I send out a newsletter-like e-mail reminding everyone of this week’s topic, summarizing the key points and providing interesting links and sources I used in order to establish Friday’s agenda.
The magic of Clean Code
I love how we seem to really work together on presented problems, without the usual pressure of work, and seeing everyone enjoying themselves trying to come up with an awesome solution. These few minutes every week have really strengthened our team spirit and motivated us to be more mindful about our code. So we’re able to present a good example for a principle on the following Friday!
Additionally, I want to thank everyone, who took the time to read this post.
Think of the people around you and also don’t forget about yourself!
Top comments (1)
I think clean commits help to drive clean code. People think it takes more time, but I disagree if you have a good code review process in place then spending time to organize what you want to communicate leads to cleaning up your code and understanding the changes better. If you don't understand the changes you probably are not ready for a code review.
Git provides good tools so you don't need to be clean the first time.