Notes of Clean Code — Chapter 1 (Clean Code)
In this series, I will share summary of the book Clean Code by Robert C. Martin with you.
He starts with the following sentence: “You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.” I read this book because I want to be a better programmer.
He tells a story about a company in the 1980s.
There was a company that was very popular. Lots of people bought and used the product of the company. However, the release cycle slowed down and bugs went unrepaired. As a result, the product experienced longer load times and more crashes. The company eventually went out of business.
Two decades later, he met one of the employees of that company and asked him what had happened. The employee revealed that they had rushed the product to market and made a huge mess in the code. As they added more and more features, the code became increasingly disorganized until they could no longer manage it.
We all do that. We didn’t have time to clean up our code. Maybe we were tired of working on this project and wanted it to be over. We’ve all said we’d go back and clean it up later. Of course, in those days we didn’t know LeBlanc’s law: Later equals never.
If you have a programmer you have been slowed down by messy code. Team move fast at the beginning of a project then later every change they make to the code breaks other parts of the code. The mess becomes a big in time and they can not clean it up.
As the mess builds, the productivity of the team continues to decrease. As productivity decreases, management does the only thing they can; they add more staff to the project in hopes of increasing productivity. And everyone are under pressure to increase productivity. This pressure instead of increasing productivity they make more messes, reducing productivity to zero.
So what happened to code ? Why does good code quickly into bad code ? We have lots of explanations for it. We complain that the requirements changed. Deadline was too tight to do things. We blab about stupid managers and intolerant customers. But It’s all our fault. We are unprofessional.
I know you think that how could this mess be our fault? What about the requirements and the schedule ?
The truth is that;
The managers look to us for the information they need to make promises and commitments. And even when they don’t look to us, we should to say what we think. The project managers look to us to help work out the schedule. We are deeply complicit in the planning of the project and share a great deal of the responsibility for any failures.
If you think “If I don’t do what managers says, I’ll be fired!”, probably you are wrong. Most managers want the truth and good code, even if it change the schedule. Their job defend the schedule and requirements with passion and your job to defend the code with equal passion.
Next Chapter : Meaningful Names
