Highlights of the modern software engineering series (3) How to maintain a normal mind in the case of continuous bugs... [Zz]

From:

Http://teamkingofcsharp.spaces.live.com/blog/cns! 59FC2D3DD66822AA! 222. entry

Feelings
Normal
Junior high school mathematics teachers often say to me: "You must learn to maintain a normal heart ". I am a less open-minded person. I am very interested in many things, such as GPA, ranking, game winning or losing, and so on. It is easy to take care of things. In these days, when I am struggling with coding and debuging projects, I sometimes think of idle people in the group, and my mind will inevitably be unbalanced: "Why can they be so leisurely ". This kind of imbalance increases, and the dissatisfaction increases, which directly leads to my previous impression or, more specifically, complaints. After sending the mail, I felt a little more comfortable, and I felt very happy.

The next day is New Year's Day. I attended a reunion and talked about the changes in my hometown and the interesting things around me. For a total of nine hours, there were only happy exchanges and no annoying softwares, which swept away the haze of the past few days. I suddenly found that I had been troubled and worried by soft workers every day for more than ten days. They were like two stones, I couldn't breathe. I seem to have taken "soft workers" and "scores" too seriously. This reminds me of my three-year GPA. Although I can still be smug when I see my transcript, the days of pursuing GPA in the past three years are indeed a little tiring.

There are too many wonderful and important things in my life than a soft engineer course in this area. Why make it a burden? Many things do not need to be too valued, so they should be treated with a normal heart.

Let's take a look at the soft work class and have a clear conscience. What will happen.

Interest-Work
At the beginning, I proposed the bbs function because I am interested in bbs and want to study it carefully, write something that includes posts, posts, replies, and even automatic snatching.

Interest is the best motivation. In the first month of the team project, I was exploring all the details of bbs, pondering the implementation of functions, and I was so happy. For me, these functions are for myself, and my target users are myself. I don't even care if others want to use these functions.

Unfortunately, as a Team Project, users of this software cannot be limited to myself, and we also need to consider other target users. It's easy to write software for myself. I just need to use it myself. It's nice. User Experience is good. It doesn't matter if I don't care for myself. However, considering that this is a Team Project for other users at the same time, there are more things: good looking, there is enough prompt information, and whether the operations are user-friendly, in some cases, which operations are not allowed to avoid bugs, unstable performance, and release of release on time are all annoying. Especially if problems emerge and deadline approaches, it is really annoying.

This may be the difference between interest and work. Just like many people like playing World of Warcraft, but if they want to become a professional player, they have to practice dozens of disks every day to win the game. It is estimated that many people cannot stand it.

Important requirements document
Each group of soft workers needs to write requirements and design documents for the last semester. At that time, I thought it was a boring and laborious task. However, this semester, I gradually realized the importance of the requirement document. Each group had only three people in the previous semester. It was very convenient to communicate with each other in the group. But this semester, when there were too many people, the problem emerged. Assign a task to someone to implement such a function, but it is easy to make mistakes without careful instructions. For example, if a function is assigned to "delete folder" without instructions, it is very likely that dev will delete the folder directly. However, it is possible that you have set up an email account to download the email to that folder. Now that the folder has been deleted and the email has been deleted, the folder does not exist and an error will occur. Although our members are generally close to each other and it is quite convenient to communicate with each other, we feel that if we have a detailed requirement document, we can avoid the above situation to a great extent. (Of course, there are many situations because we did not expect this boundary situation beforehand, which requires pm to have a comprehensive logical thinking capability)

The most helpless thing for programmers
I just finished writing my own code and finished debugging my own bugs. I found that bugs are still one by one, and they are not the cause of my own code. I don't know how to fix them, so I have no way to do it. I have to look at the bug ......

-- LIU Ke

4: 31 AM | Blog it
Comments (3)

 

Yuan CHEN-Jan. 2, 2009
> I feel that if you have a detailed requirement document, you can avoid the above situations to a great extent.
The second item in Agile manifesto is: Working software over comprehensive documentation. In addition, the document will introduce new problems. For example, if someone has a problem, he can say to you with confidence: "spec is not so written, of course I didn't do that ". In addition, according to our level, the design can not be done well in the first place. If we change the spec design three times or five times during the development process, I guess someone will be worried ......
Btw: it is the most difficult process to convert "requirement document" into "feature design...

> After writing your own code, you can call out your own bugs and find that the bugs are still one by one, and they are not the cause of your code. You don't know how to fix them, in a hurry, you can only look at the bug and sigh ......
There is a kind of "odd-Clever technology" called Test driven development, a quality ensurance development method, using a bunch of test cases to limit the code behavior. If someone else has a problem with the code, use automated testing to fail itself (before they reach your sight :))...

The most important thing is the people's hearts, the mountain shift...
Let me say something that Mr. Yan once said to all the teams at the last stage of MS ^ 2 training: keep moving is better when you do your best!
 

Xin xinxin-Jan. 3, 2009-Delete
> After writing your own code, you can call out your own bugs and find that the bugs are still one by one, but they are not the cause of your code. You don't know how to fix them, in a hurry, you can only look at the bug and sigh ......

The Code of others should be understandable to those in the same group...
Let's take a look at the story of radish and cabbage.

 

Ke Liu-Jan. 3, 2009
Because I don't know the functions ...... For example, if I don't know the XX protocol and want to change the function of the XX protocol, I have to study the XX protocol first, which is too time-consuming ...... In addition, according to the division of labor, only persons responsible for implementing that part of the function can study it.