Programmers aspire to work on teams where they spend 30% of their time writing code and 70% of their time drinking coffee and talking about how to get the product right.
Software work should be a high intellectual activity that integrates technology and art, and the project manager should be a person with a high understanding of the objective laws of quality, scope and schedule. “Work efficiently, live happily” should be the programmer’s motto.
The reality is that the team is overloaded with requirements while fixing endless bugs.
After a little eve, the project manager endure red eyes staring at us all night long overtime, quality specialist urged quality data again and again is not enough, software work has been irreparably reduced to physical labor, let alone happy life, life is gone.
Well, all of the above may be true. Project managers and quality specialists are devils who don’t understand objective laws and have no sympathy, leaving us programmers with no dignity and humble existence.
Just, there is a sentence held for a long time: “wake up, all of this, because your code is too bad, you make too many bugs!” .
You may complain that this is clearly the result of requirements changing too fast and leadership planning being too tight.
Well, that sounds reasonable, but you should know that requirement change itself is the objective law of software, and the leader requires progress, hehe, you can also think of it as an objective law.
This isn’t an argument for who causes programmers to work too much overtime, and I’m not going to give you a recipe for turning everyone into an expert programmer overnight, but at least here are some solid lessons and tips. In short, let everyone see a little more to get a little more real value.
Don’t start writing code right away
You may be in a hurry, or you may be itching to try a little programming trick you learned yesterday. Take it easy, I’m telling you, there are more important things to do before you get the requirements and are ready to write your first line of code.
I can’t stress enough how important this is, but in all of the code I’ve written that I’ve been very happy with, I’ve used this approach, and it has eliminated 90% of the bugs that would otherwise have been tested, or even achieved zero bugs, although it may take a while to get there.
Once you have the requirements, you should first ask yourself if you have fully understood the requirements. Once the answer is yes, we can begin:
1) Find an hour in your busy schedule that you have complete control over, that is your own hour, and that will be free of interruptions or interruptions that will prevent you from implementing this method. Remember that this one hour is very important, more important than all the activities you will perform later, and it is definitely worth it.
2) in the upper part of a piece of paper to write down “the demand characteristics of the normal process and scope of influence”, and then at the bottom of the paper to start writing down the demand characteristics of normal process contains a detailed content, which will probably be used to library function, which will provide the interface, will affect version upgrades, whether affect the resource file, whether to affect the original interface and so on.
3) On the top of the second piece of paper, write down “all the abnormal scenarios of this requirement feature and some mistakes I often made in the past”, and then write down one by one at the bottom of the paper.
4) Keep repeating steps 2) and 3).
You may find it’s not just about writing needs to clarify the material, I want to tell you that this is two different things, it is not a quality specialist activity requires you to do the quality of the process, it is a deep dialogue between you and yourself, it doesn’t need to tell anyone, don’t need any deliverables output to other fields, it is to oneself a self drive to write good code.
At first you may find hard to write a few can’t write out, or flash across the idea of “this stuff is really useful, don’t try so hard, got up and went to the window to play cups of water to drink, breath the fresh air or in short don’t interrupt, unless the fire in the office, don’t let it continue not to do.
As you work your way down to answer number 20 or 30, you might suddenly feel like, “Oh, I found this subtle anomaly. It’s awesome!” This time you will secretly exclaim a little can not contain their excitement, this means that you are close to the success of the completion, each later to write a line will let yourself moved.
Remember, don’t give up in the middle, and your decision to stick with it will turn that one hour into the most important hour of your entire requirement realization.
Second, forget about the damn quality activities behind
All quality activities outside of coding are based on the company’s distrust of your ability to write code.
This means that companies spend a lot of money on quality specialists, meta-testers, solution testers all because of the waste of code that you don’t write well.
Common some developers, just came to the quality specialist arrangement of quality activities quite complain, “my previous company to do projects do not need to do these things is not the same to finish the project”, “these quality activities, is simply the occupation of coding time.
All of this is fine, but isn’t it a bit of a shame when you write code while you’re saying it?These activities are designed by quality specialists to prevent your bad code from rushing to the customer at one checkpoint after another. When you do nothing to “write good code” and only want to cancel these activities, it can only be understood as a gangster.
So, do quality activities “write good code”?
The answer is no.
It is not a goal or even a method. Your goal in writing code is not to meet quality activity standards, but to achieve zero defects, and you do not write good code just because you do good WBIT testing.
One of the things you need to do is “don’t start writing code right away.” The other thing you need to do is learn to refactor as much as you can, the way you think about refactoring, and learn that refactoring isn’t necessarily about refactoring the original code, it’s about knowing how good code is going to be before you write it.
I ask you to forget quality activities, not to let you do not listen to the quality commissioner, but you should write code in the heart of awe, after the code is written all the activities are you caused waste, you have to eliminate these waste.
Remember, you’re writing code for people to see
I heard a colleague tell a chilling story from his last job:
A colleague of his original company left, left is a pile is very complex, see the c + + code can let a person a neurological disorder, he was gone, found the entire project team no one can take over his module, project managers have to high price and a dinner party in a way that he came to tell the person of whole project two days his code. This guy has a “look, only I can fix it” kind of homecoming attitude. I’m curious why the project manager didn’t fire him earlier. He should have called the police.
Good code is pleasing to the eye, any lack of ability or showing skills to increase people’s dyslexia behavior need to be improved, you can be a few words to clarify the context of your own written code, of course, this also involves you to master as many refactoring methods and refactoring way of thinking.
Another measure of self-judgment is to ask yourself, “With all this code you’ve written, have you ever been tempted by it?” Have you ever written the code and read it over and over again, marveling at how beautiful it is?
As a programmer, one of the many happy moments you’ll recall when you leave the company one day will be the feeling that you just produced a piece of code that caught your eye, not the guy who left the company only to realize how important he was.
Start now, practice deliberately
Do you find yourself maintaining a level of “just enough to complete a story” code for a long time, writing code for years and still being chased by testers?
The reason for this confusion is that it doesn’t matter how many years you’ve been coding, it’s all about deliberate practice.
Such as I mentioned earlier, the practice repeatedly, or you figured out the method of decomposition into every link, deliberately to practice, to get a feedback from the test, and constantly improve, you will slowly from a running all day by the tester, to find himself very easy to achieve quality process standards, then slowly you will find you write code tester is more and more difficult to found the problem, the last state better if you could often write zero defect in the code.
We all seem to know some of these things, but I think there are only two steps to understanding them. First, you need to experience them and practice them yourself. Second, you need to be able to communicate them and make them accessible to others.
So the best way to learn is to experience it yourself, and then write about it, so that you can really understand what you thought you knew, but you didn’t. .
If you want some video tutorials, please contact me at 756576218

Reproduced in: https://www.cnblogs.com/nice107/p/8109208.html