Working Method-how to work efficiently

The current project team is almost three months old. It can be said that this is the first formal project that I entered the company after graduation. as early as the end of August, the minister asked me if I would like to do this project, it was not until the Middle and Late of September that the project was officially started. Instead of joining the project, the project was completed after I understood what I was going to do.

 

I learned something and understood something during my more than two months of participation in this project, as shown in the following figure (no technical problem, only working methods ):

 

1. At the beginning of the project, the principle of doing more preparation and cutting down materials without mistake is shown here.

This is a communication project. My job with another programmer is to convert one type of message into another type of message, while for SOCKET communication, another person is responsible. Since there are many messages and documents are often changed, PL asked us to sort out the Conversion Relationship Between the two messages at the beginning of the project, for example, from A to B, the documents need to be subdivided into N-bits of B, which are calculated by M-bits of A. First, we can deepen our understanding of message conversion, second, when writing code, you don't have to understand how to convert the message, because this document only needs to be written. Facts have proved that this is a good method, because in the future work, if you encounter any problems, you can find the document about the conversion rules, saving a lot of time.

 

2. When reading the document, divide the detected problems into (1, 2, 3, 4 ...) The records are recorded in the notebook. During the meeting, the numbers are marked as 1, 2, 3, and 4.

You may encounter many problems when reading the documents provided by the customer. To deal with this situation, my previous practice was to draw out the document and wait for the meeting to start looking for it everywhere. In this way, there will be no problems when there are few problems, if there are many problems, some problems may often be missed. If you ask the customer for these questions, it will cause a lot of trouble for our work, so when I first looked at the conversion of the message, PL told me to LIST all the questions into a LIST, but I didn't listen. I did not ask a question, this made PL criticize me when I was in a group meeting, and I was very impressed. After that, I was very strict with me, as long as I found the cause of the problem was because of me, I am very strict. Therefore, classifying and listing problems is a good work habit.

 

3. In actual work, if you find that your style is different from others, you should propose it at regular meetings and determine a method to modify the code.

In fact, this is not mentioned at all, because as far as I know, all projects have their own set of coding specifications, how to name variables, and how to write annotations, A few lines are left blank between different modules. I don't know why, but I mentioned naming and commenting standards at a regular meeting when I started writing code, but I didn't explain the structure of the Code, so the code style of my buddy who made the conversion of messages is different. The main difference is that when he defined the class, the member variable followed by the attribute of the variable, what about me is to define attributes after defining all member variables. It is clearly displayed that the two styles are not allowed in the same project. During a regular meeting, the customer raised this question and PL asked us the solution, let me discuss it with my buddy, who is responsible for the change. Finally, I thought that I had not attended the work for a long time, and I would say I should change it. Alas, in fact, at the beginning of code writing, I found this problem, but I did not propose it. Otherwise, I would not spend two days modifying the already formed code. In fact, this broad concept of teamwork can be reflected here. when several people work together to complete a job, they cannot make a new idea, even if their methods are correct or better, this project is done by several people. Discovering and proposing problems in a timely manner can greatly improve the work efficiency.

 

4. Make sure that the running result of the intermediate tool is as expected. That is to say, ensure that the intermediate tool is correct.

For programmers, this is to ensure the correctness of some common functions. For example, in the coding work I am in charge of, an array should be used in a lot, and the position of an element in the array should be checked frequently, however, the data type of the array in C # does not have the IndexOf () method, so you can write it yourself. It is very simple. There are no more than 10 lines of code, after writing the code, I took it for granted that this method is correct. There are 10 lines of code in the code area, so I don't have to test it. So I will use it in other places without fear. During the tests over the past few days, I found that the running result of this method was not what I expected, so I went crazy about working overtime and had a crazy change. When PL asked me about the progress, I was nervous about the West, I am sorry to say that I am behind the schedule, especially when I announced that I had finished my work a few days ago, I had to leave late at night. In fact, after writing the IndexOf () method, you only need to spend 10 minutes or less to avoid working overtime over the past few days. More importantly, you can eliminate unnecessary tension.

 

5. regularly check the work results.

In fact, this is similar to 4th, but I still think 4 is a little different from what we will talk about below. Take the actual situation of the project as an example. After converting one type of message to another type of message, we should test it to see if the result is correct. However, I did not do this. Instead, I wrote the conversion of a message and then wrote another conversion. In the past few days, DEBUG found many problems, in this way, the original plan for testing will be postponed until this afternoon. Although the conversion of each message is parallel, there is no conversion of a message that will use the result of the conversion of the previous message, so there is no such situation as described at above, however, after completing a module, you can check yourself when your mind is still clear, solve the problem immediately, and in the following work, in the same place, it can be handled with special care, instead of being solved one by one during the final test. In PL's words, leaving the problem to the end is of no benefit, and it will increase anxiety for itself. No, I 've been working very hard recently. When I heard PL call my name, I sent a token and thought I was doing something wrong.

 

6. For the corresponding problem point, it must be confirmed again before submitting the work results.

At each meeting, PL always points out several new problems and asks if the last problem is completely resolved. This is nothing for those who have a serious attitude. But for me, careless and careless people sometimes make serious mistakes. For several times, I have not matched all the problem points, or only some of them correspond to all the problem points, but some of them have not been changed at all. That's why PL is so strict with me. Therefore, during the last few days of modification, I have always completed the modification. before uploading the server, I will use a comparison tool to compare the results before and after uploading them to the file server.

 

7. When modifying the common part, you must notify all members of the project team.

This has happened twice recently. The other two modified the number of parameters for one LOG message I want, but did not notify others, the result is that I spent almost three hours corresponding to this change. Second, after I modified a constant, I did not notify anyone else, as a result, another guy spent the morning debugging his code and found that the reason was that he changed the value of the constant. Although the common part is small, it has a great impact. Therefore, do not notify all members before making the change, and confirm that the change should not be done. This can greatly save the team time.

8. Effective communication: listen to other people to finish talking.

This should be the basic etiquette for people, but I often ignore this. It can be done when I was not familiar with other members of the project team at the very beginning, but later I am familiar with everyone, when I was working, I often knew what the other party meant when others did not finish talking, so I was very rude to interrupt the other Party. This will undoubtedly increase the cost of communication, seeing that the project's deadline is getting closer and closer, you can't waste any time on internal communication. In fact, no matter how good the relationship with the other party is, you cannot interrupt the other party. In this case, pay attention to it in the future.

 

9. Back up data before making major changes and upload the data to the version management server.

This is especially true when multiple changes are made. After the changes are completed, upload them first, then modify them, and then upload them ..... Otherwise, when it is found that a change is unnecessary, it cannot be found in a cry place. It is also explained by the LOG information related to the common at. At first, four parameters were defined, modified to three parameters, and then the other two colleagues changed to four parameters, at that time, I was modifying the modification according to the three parameters. It took me one morning to finish the modification and didn't upload it. Next, I made the second major modification. When I changed it to half, I referred to the code of other colleagues, I found that he still had four parameters instead of three, so I told him that I found that they changed the three parameters to four again, if I re-obtain the previous version, I will make all the changes in the afternoon. If I continue to make the changes, I will do the work in the morning. Where can I find the place to cry?

 

10. At the time of definition, the constant indicates who defined it.

I don't know if it is correct. I just feel that it is much easier to sort out constants. Because during the project, there is no time to discuss the definition of each constant with others, and in the middle and late stages of the project, someone will organize these constants, this undoubtedly creates a great deal of trouble for this person, because he does not know what it is often used for, or which constant can be combined with other constants. Therefore, when defining a constant, indicate the user. In this way, if you do not understand the comment, you can easily know who defined it, it is much easier.

 

 

Bytes ---------------------------------------------------------------------------------------

Today, I think of more than these 10 points in public steam. I will try again later.