In this series, there are many excerpts from the book, all of which I think are worth sharing. Of course, there will also be personal reflections, as a learning record and simple to share.
Code Monkey
The book’s author, Robert C. Martin (Uncle Bob), once opened a talk with the song “Code Monkey,” an allusion to poor coders.
Yes, we’re a bunch of code monkeys, jumping up and down, thinking we know what programming is all about. Alas, as we sit complacently on a branch clutching a few sour peaches, we are oblivious to the mess we have created. That jumble of “working” programs is rotting right under our noses. – order
The first time I read it, I thought it was funny and true. Reading it again, it got me thinking more. There are many external factors and objective reasons, but my coding level and attitude towards such problems are also a problem that cannot be ignored.
Why is there bad code
We abandoned work on the code too soon, not because it was finished, but because our value system focused more on presentation than on the nature of what was being delivered. The output eventually took its toll: the bad stuff kept coming back. – order
I don’t know if you have ever met the situation that the project is already scheduled when it is given to you. Recently, I have frequently encountered that the requirements are given to me and they tell me that the project will be online in 5 days or one week. Often, at this time, the UI design drawing has not been finished.
Above there is another meaning of this passage is part have no pursuit of coders (or code monkey more accurately 😏), because of their technical level or attitude problems do not pay attention to code quality, more reluctant to spend more time and energy to make your code better, if you encounter this kind of person, away from his 💨.
Why write bad code if you haven’t been on a great team for a while?
Are you trying to get it done? Are you in a hurry? Possible. Maybe you feel like you don’t have enough time to do well. The boss is furious if it takes time to clean up the code. Maybe you’re just impatient with the process and want it over with. Maybe you look at your other commitments and realize that you need to hurry up and finish what you’re doing so you can move on to the next project. We’ve all done it. We’ve all had a glimpse of the chaos of our own making that determines our temperament instead of moving on to a new day. We’ve all seen our crappy programs work and declared that a crappy program that works is better than nothing. We all said we’d clean it up one day. In those days, of course, we never heard of LeBlanc’s rule: Later equals never. Some teams make rapid progress in the early stages of a project and then slow down for a year or two. Every change you make to your code affects two or three other pieces of code. Every time you add or change code, you need to know the stack of twisters so you can throw more twisters on it. The mess got bigger and bigger, and there was no way to clean it up. As chaos increases, team productivity continues to decline to zero. When productivity drops, management has only one thing to do: add more people to the project in the hope of improving productivity, but the new people are not familiar with the design of the system, and they can’t figure out what changes meet the design intent and what changes break the design intent. And they, and everyone else on the team, are under terrible pressure to be productive. As a result, they create more chaos and drive productivity down to zero. In the end, the development team rebelled and told management that they could no longer develop on this boring code base. They asked for a completely new design. Managers are reluctant to devote resources to a complete reboot, but they cannot deny that productivity is horrendously low. They agreed to the developer’s request to license a gorgeous new design that looked beautiful. A new army was formed. Everyone wants to join the team because it’s a blank SLATE. They can start over and make something really beautiful. But only the best and brightest are selected, and the rest continue to maintain the existing system. There are two teams competing now. The new team had to build a new system that implemented all the functions of the old system and kept up with constant changes to the old system. Management won’t replace the old system until the new one is powerful enough to compete with the old one. The race can go on for ages. I’ve seen one that lasted ten years. By the time it was done, the old members of the new team were long gone, and the existing members demanded a new system from the ground up because it was so bad. If you’ve ever experienced even a little of what I’m talking about, you know that taking the time to keep your code clean is not just a matter of efficiency, it’s a matter of survival. — 1.3 Messy code
After reading the above paragraph, I confess that I have experienced many of these situations. Now that we know the importance of clean code, what is clean code? Let’s hear what the big boys have to say.
What is clean code
I love elegant and efficient code. Code logic should be straightforward, making defects hard to hide; Minimize dependencies and make them easy to maintain; Refine error-handling code according to a hierarchical strategy; Optimize performance to avoid tempting others to do unruly optimization and create a mess. Clean code does only one thing.
Grady Booch, author of Object Oriented Analysis and Design with Applications Clean code is simple and straightforward. Clean code is like good prose. Clean code never hides the designer’s intent, full of neat abstractions and straightforward control statements.
Michael Feathers, Author of Working Effectively with Legacy Code I could list all the traits I’ve noticed about clean Code, but there’s one that’s fundamental. Clean code always looks like it was written by someone who cares. There is little room for improvement. The author of the code thought of everything, and if you try to improve it, you’ll always come back to admiring the code someone left you — the code someone dedicated to it.
Here are three of my most personally resonant quotes from the book, each worth rereading.
Benefits brought about
I don’t know if you have heard the saying, code is written for people, people here, not only the other friends in the current team, the friends who will take over the project later, but also ourselves. One might wonder how much of the code is actually “read”. Shouldn’t the main focus be on writing? But have you ever met this kind of situation, there is a project, or have a module, when we need to add new functionality or adjust before a period of logic, we need to spend as much time to modify the code several times even read around the code, if the code before, this time even more, so when we write new code, Keep reading old code. In order to make reading easier, we should write clean and readable code, even if it makes writing more difficult, but overall, it will greatly improve our productivity.
At the end
In the end, of course, writing clean code takes more time and effort than writing random code, and many companies and technical teams don’t pay enough attention or give enough time to it. But as a qualified programmer, I think we have a responsibility, it is necessary to write clean and maintainable code, at least let each check-in, clean than when check out, maybe it’s just a variable named, is good to break up a non function of single responsibility, eliminate duplicate code, let the project, more than we come clean.
Of course, ideas and enthusiasm are not enough. Writing clean code requires skills, techniques, and tools. Let’s learn! 😁