You work overtime too much because your code sucks.

As a programmer, I am eager to join a team that "30% of the time I write code, and 70% of the time I drink coffee to discuss how to do the product." I think the software work should become a high intellectual activity of technical and artistic integration, our project manager should be a good understanding of the quality, scope and progress of the objective law, "efficient work, happy life" should be our motto.

But the reality is that the team is overloaded with demand while changing the endless bug. On the eve of the program, the project manager with red eyes staring at us all night overtime, quality commissioner over and over again to urge quality data is not enough, software work has been irreversible reduced into manual labor, not to mention happy life, life is gone.

Well, the above may be right, the project manager and the quality Commissioner is a non-objective law and no sympathy of the great demon, let us programmers have no dignity and humble life.

Just, there is a word suppressed for a long time: "Wake up, all of these, is because your code is too bad, you create too many bug! ”。 You may complain that this is clearly the result of a change in demand that is too fast and the leadership plan too tight. Well, listen to quite reasonable, but to know that the requirements of change itself is the objective law of software, and leadership requirements for progress, hehe, you can also consider the objective law.

This is not a proof of who led the programmer to work overtime too much of the argument, do not want to give everyone to pour chicken soup, so that everyone overnight into a programming master, but at least say some real experience and methods. In short, let us look at a little more to get a little more practical value.

on don't start writing code as soon as it comes up .

You may be impatient, or may have already been able to resist the temptation to just learn a little programming skills yesterday, I want to tell you is, not urgent, put away your that sharpening expression, before you get the demand ready to write your first line of code, there are more important things to do. I would like to emphasize the importance of this matter is not too much, in my previous writing very satisfied with the code experience, I have used this method, it can eliminate the original may be tested 90% of the bug list, or even to achieve zero defect, of course, this may require a process.

After you get the demand, you first have to ask yourself whether the need has been fully understood, and get a positive answer, we can begin:

1) in your busy work, find out the one-hour period that you can fully control, this one hours is entirely your own, to ensure that the one hours will not have any interruptions, or any can affect you do not go down this method of interruption. Keep in mind that this one-hour period is important, and it's definitely worth it than the time of all the activities you have to perform later.

2) on the top of the first piece of paper, write down "the normal flow of the demand characteristics and the scope of influence", and then start writing under a blank paper on the requirements of the characteristics of the normal flow of content, presumably will use which library functions, will provide which interfaces, whether it will affect the version of the upgrade, whether the impact of resource files, whether

3) on the second piece of white Paper, write down "all the abnormal scenes of this requirement characteristic and some mistakes I have made in the past", and then write down the beginning of one article under the blank.

4) Repeat the 2nd, 3) step.

You might think this isn't about the need to clarify the material, and what I'm going to tell you is that it's not the same thing, it's not a quality process activity that the Quality Commissioner asks you to do, it's a deep-seated conversation between yourself and yourself, which doesn't have to tell anyone that you don't need to export any deliverables to other areas, This is a self-drive to write good code for yourself.

At first you may find it difficult to write a few words can not be written, or flash "this thing is not really useful" idea, do not worry, get up to the window to breathe a fresh air or to play a cup of water to drink, in short, do not interrupt, unless the office on fire do not go to the matter to continue to do things. When you slowly write down to the 20th or 30th answer, you may suddenly have a "so obscure an anomaly is I found, it is too cow!" "The emotional gush, this time you will secretly exclaim a little hard to suppress their excitement, which means you are nearing the completion of the success, each one of the written out will let oneself moved. Remember, don't give up in the middle, your decision to persist will turn these one hours into the most important one hours of your entire need.

Geneva forget about the back and the damn mass activity.

All quality activities outside of coding are based on the company's distrust of the level of code you write. In other words, the company spent a lot of money to attract quality commissioners, network meta-test, solution testing these people are because you did not write the code well wasted.

Some common developers, when they first came to the quality of the Commissioner to arrange the quality of activities have a lot of criticism, "I used to do projects do not need to do these things are not the same can get the project done," "These quality activities, is simply the occupation of the code time." Say these all no problem, but you say these side write the code after the bug on the Wu Yang Yang come up, is not a bit shameless? The quality Commissioner designed these activities, is in order to not let your rotten code Yixieqianli rushed to the customer in front of the design of a checkpoint, when you "write good code" What did not do, just want to cancel these quality activities, can only be understood as bullying.

So, do quality activities can "write good code"? The answer is no. Quality activities is only the quality of the supervision of the Commissioner, it is neither a target nor a method, you write code is not to meet the goal of quality activity standards, but to pursue zero defects, and not because you wbit test done well can write good code. One of the things you have to do is "don't write code as soon as you come up," and another is to master as many refactoring methods as possible, to reconstruct the way of thinking, to master refactoring and not necessarily to refactor the original code, but to know how to write a good code before you start.

I let people forget the quality of activities, not to let people do not listen to the quality of the words, but everyone in the code to be in the heart of fear, after the code to write all the activities are you waste, you have to eliminate these waste and make every effort.

03 Remember, the code you write is for people to see.

Before I heard a colleague tell a very scary story about his last company, he was a colleague of his company left, leaving a bunch of very complex, looking at the c++++ code that would make people insane, after he left, found that the entire project team of people can not take over his module, The project manager had to pay a high price and invite him to come over and talk to the whole project team about his code for two days. This guy has a lot of "homecoming" attitude, "look, only I can handle it." I was curious to know why the project manager had not fired him as soon as possible and should have called the police.

Good code is pleasing to the eye, any lack of ability or the increase of the technical component of the reading barrier behavior needs to be improved, you can say 32 words will be able to clarify the context of your own code, of course, this also involves you to master as much as possible refactoring methods and reconstruct the way of thinking.

There is also a self-judging criterion that you ask yourself, "Have you ever been tempted to write so much code?" "Are you going to be tempted to read your own code and repeatedly marvel at the beauty of code?"

As a programmer, one of the few happy moments that you'll think of when you leave the company one day is because you're moved by the fact that you've just come up with a piece of code that makes you tick, and don't be the guy who said, "After leaving, the company knows how important he is."

04 Start now, deliberate practice

Do you find yourself maintaining a "just-good-to-do-story" code level for years and writing code that will still be tested by testers chasing the bottom bill of lading? The confusion is that the ability to code is not directly related to how many years of code you have written, and what you need to do is deliberate practice.

For example, I mentioned in the 01, 02, 03 mentioned in the method of repeated practice, or the method you figured out into an item, deliberately to practice, from the test to get feedback, and then constantly improve, slowly you will be from a whole day by the test personnel chasing the people, Become a person who finds it easy to reach the standard of quality process, and then slowly you will find that the code testers you write are becoming more and more difficult to find, and as long as you are in good shape, you can write the code of zero defect regularly.

In fact, there are some reasons we seem to know, but I feel away from the real understanding of the two steps, the first is that you need to experience, practice these principles and methods, the second is that you have to be able to repeat and let other people can understand. So the best way to learn is to personally experience, and then write down to share to everyone, so that you can really understand what you originally thought to understand the truth may not understand.

Transferred from: https://www.test404.com/post-1116.html

You work overtime too much because your code sucks.