"Excellence is no coincidence. It is always brought by strong intentions, sincere efforts, and smart actions. Excellence represents a wise choice, rather than an opportunity. It determines your fate. "& Amp; n...
"Excellence is no coincidence. It is always brought by strong intentions, sincere efforts, and smart actions. Excellence represents a wise choice, rather than an opportunity. It determines your fate. "-Aristotle
Now you can be reserved.
I will try to prove that I have made a good choice. It will be something that all developers will do, and at the same time, they will be able to filter out excellent people from ordinary people.
All developers occasionally write spam code.
Let's take a look at this. You and I will write some very spam and shameful code from time to time, so that we never want to be seen.
We all have occasional reasons to write spam code. I don't want to discuss the legitimate reasons, because each of us has its own legitimate reasons.
Before presenting some code violence, let's review the reasons for writing spam code. Then we can avoid getting stuck in the Code smell and struggling.
Common Reasons for spam code writing: 1. Time out
"Not enough time" is one of the most spam code currently. The commitment to the customer, the tight schedule, and the pending new release may all be the cause of this evil.
2. Deep in pain
The existing code library is too spam, so you don't want to write good code at all. You know that no matter what you do, you cannot save the junk code library that will crash at a certain time.
3. "I only need to complete the task and then leave"
As developers, we sometimes work in different project groups. If you write the last few lines of code, you need to switch to a new project. This is not a big thing that affects others.
I know that my time on this project is coming to an end, and no one will review your code. So you just submit and push, and then count on the unit test to ensure there is no problem.
Look at the truth
We occasionally write spam code. Does this mean we are all bad developers?
Of course not. This is because everyone occasionally writes bad code, so it cannot be explained.
However, over the years, I have gradually discovered a surprising truth about developers.
How the spam code is presented is a fundamental test of our developers' qualifications.
That's incredible, but it does. Realizing that you are writing spam code and the actions you take to avoid future occurrence all reflect how you write code and how you generally write code.
How much does spam Code have to do with evaluating developers' excellence?
There is a lot of relationship.
Let's take Ron for example. Ron wrote bad code today and is not happy with it. Because of an annoying five-level deep inheritance chain of the Backbone model, Ron cannot modify a line of code at all, except to break everything.
Ron wrote a piece of super junk code, bypassing this issue. Everyone is happy because Ron delivered the code on time. However, except Ron himself.
He told the team leader what happened. They repeatedly thought about how to solve this problem. They made it clear that it is the best solution to break the inheritance chain and divide it into horizontal composite modules.
Ron asked the boss to give him time to implement the reconstruction solution he and the boss just discussed.
Roger also wrote bad code today. He told his development partners that he used an incredible hack technique to bypass a strange five-level deep Backbone model inheritance chain. He planned to bypass the entire architecture and deliver it on time.
Roger was very satisfied and felt that there was no need for further improvement.
Four types of JavaScript developers
You can classify the spam code into four categories, from poor to excellent.
Tell me you haven't met all these four types of developers at the same time.
Barney-poor JavaScript developers
Barney is not concerned about writing spam code. He only cares about the ability to finish his work on time. Nothing else matters. If the code runs properly, there is no problem.
The Spam code written by Barney sometimes hinders the progress of the entire project. When the code works, it will also bring a lot of problems, so that the entire project progress is regressed. Barney thinks he doesn't need to learn anything new.
He knows everything about JavaScript needed to complete the work.
Bill-common JavaScript developers
Bill didn't realize he was writing spam code. He followed the team's conventions and lint rules and thought that he had done nothing wrong. However, he does not spend time understanding the entire project structure and how different components interact.
The final result is, unfortunately, a mess.
Bill did not consult anyone before making major design choices. He can do what he thinks. He has read three blog posts posted a year ago and they have been guiding his decisions.
I often say that when I enter the code of Bill, it feels like a thunder war. If I move a wrong step, everything will blow to your face.
Roger-Good JavaScript developers
We mentioned previously this type of Roger. I am fully aware that I am writing junk code. He knows what the code looks like if he wants to write it well. He patted his back and continued to write the spam code.
The main problem with Roger is that he did not try to make some changes. He did what he was asked to do, and it was done well. But he would rather let things do what they should, rather than taking some time to make some efforts to make changes.
Ron-Excellent JavaScript developers
Ron is a good programmer, but sometimes he still has to write some junk code.
What makes Ron different from others is that, when writing those junk code, he will seriously think about how to make this happen again, neither for himself nor for himself, no one else. Ron will figure out which technical solution can be changed or upgraded for that type of refactoring.
Then, based on these findings, Ron will act to push these changes.
Cool reality
I have to confess. I am Roger here. But I am also Ron. I also believe that I have been a Bill more than once, but I don't know it myself. I don't think I have ever been like Barney, but does anyone know! We are all going back and forth on the road to lasting excellence. Sometimes we are ordinary, sometimes we are good or good. I'm always trying to avoid being bad.
The role that ultimately lasts for the longest time will decide what kind of developers we are.
To be honest, from a common developer to a good developer, You need to accumulate more knowledge and experience than other things. But to jump from good to good, you only need to change the same attitude.
"Remember, before you become great, you must be good. Before you become good, You must be poor. However, you must try it before it gets worse. -- Atwilliams
The above is the difference between JavaScript developers of different levels of excellence. For more information, please follow the PHP Chinese Network (www.php1.cn )!