Why is clean code important?
If you ask 10 developers what “good code” is, you'll get 10 different answers. That is why we think it is important to (continue to) have this discussion within Blis and to come to an idea of “good code” together. The book 'Clean Code'by Robert Martin is therefore a fixed cost for us.
But what makes clean code good code? And what exactly is “clean code”? Code is clean when it's readable for everyone. As a developer, you often dive deep into the challenge that lies ahead. You are fully focused on realizing your solution and you are happy and proud when you get it to work. But working code isn't your only responsibility. Your code will be part of an application that supports critical business processes and must therefore be easy to maintain and adapt quickly. Even by someone who wasn't there when it was written.
That means that a developer who looks at your code in a year should be able to easily understand what you did and why. To achieve that, Martin follows in 'Clean code' consistent conventions and uses clear language. A developer who needs to fix a bug will therefore be able to see where things are going wrong much faster. But you also make fewer bugs with clean code, because it's easier to see how the different parts of the code work together and work together.
So, as far as we're concerned, clean code is the cornerstone of every good software development process.
A common language
Martin's book consists of 3 parts. In the first part, he explains what he means by clean code. He focuses on naming, writing logical error-handling and formatting your code. The second part is full of case studies and exercises. In the third part, he summarizes the lessons learned and gives you, as a developer, the knowledge and techniques you need to 'smell' code if it is well written.
The book's core and raison d'être are well summarized in this quote:
“The ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.”
Totally true. As a developer, you are constantly reading old code to find out where to make adjustments, how best to add functionality and how to fix bugs. So you can really get a product or feature up and running with sloppy code, but in the time that follows, you'll get lost in your own mess. So writing clean code saves you a lot of time, frustration, errors and — ultimately — money.
In his book, Martin mentions a number of principles for readable, clear code. The most important thing is that you all speak a common language. And I'm not talking about the programming language, but about a set of work agreements within that language. If everyone consistently adheres to the same principles, you always know their way around each other's code. This makes adjusting and maintaining much easier.
The importance of sharing knowledge
By thinking together about the cases and ideas in the book, we often have fun and fruitful discussions while enjoying pizza and a drink. We challenge each other to tell us what we noticed in the book, whether it contained things we disagree with, and what things in the book we would like to put into practice at Blis Digital.
To start with the latter: we quickly notice that junior developers want to write clean code, but don't know (or can find) exactly what the rules are. More experienced developers often know these rules “from tradition” and apply them “by feeling”. So we decided to do more to transfer knowledge between junior and senior developers. Not by writing thick handbooks, but by sitting together more often at the table and behind a monitor. This will also help us further standardize our code conventions and thus make our code more readable.
Keep challenging yourself
By the way, we don't agree with everything in the book. First, it is about 14 years old and there is progressive insight at various points. Secondly, Martin has a very strict black and white vision of the matter. At Blis, we are a bit more pragmatic and opt for a slightly less stringent regime of code standards for small projects, for example. But Martin's vision, namely that software is never finished and that you should always keep working to make it better, is something we 100% support. And during that work, you grow as a person, as a professional and as a company. Because you're constantly challenging yourself to do better.
The Iron Triangle
What's the biggest challenge when it comes to writing good code, most developers don't have to think long about: time. The “iron triangle” of project management is reflected in code quality: the budget and available hours are often too tight for the code to be real, in the opinion of many developers. clean to make. An example of this also came to us when we were talking about software maintenance. The most important KPI here is how many issues have been resolved. But you can resolve an issue in 20 hours or 40 hours. In that first case, you have working code that is not necessarily easy to read. So we, as developers, need to learn better why you should take that extra time.
Inspiration
At Blis Digital, we often organize knowledge nights. Because it's fun. And because we want to get to know each other better. But mainly because we notice that sharing knowledge, experience and insights helps us to make better software. We will provide plenty of inspiration during these evenings and we will also be back to work in the near future to build even smarter software. Because code that 'works' just isn't good enough. Code is only good when everyone who works on it understands it.
.jpg)
