Let you know about software development in advance (38): fulfill the first new requirement

Part 1 software R & D work summary

Fulfill the first new requirement

 

Shortly after I joined the company, I got my first new task: to fulfill a new requirement for a specific version. The so-called"Requirement"Is to tell us what to do and what functions to implement in the form of documents.

After obtaining the requirement document, I carefully read it several times and found that I did not quite understand it in some places. If you modify the code without being sure, the consequence is very serious. The project manager once warned me. I sent emails to my questions.Se(System Engineer), let him understand the requirements. In our company, se is responsible for writing requirements. They want to write the functions that users want to implement into documents and then let the software development engineers implement them. It can be said that they play a "bridge" role.

Soon, se replied to the email and answered questions one by one. After clarifying what I want to do, I started to modify the code. Generally speaking, as a new person, it is impossible to do complicated things from the very beginning, all starting from the simplest. That is to say, you must first modify the code on the basis of others.

Comparing the "requirement document" and "Detailed Design Document", I quickly found the place for modification. Should I write the code right away? Not yet. What we need to do next is to find out the "programming specifications" and follow the instructions above, including: how to name variables? What if I write a comment? How do I add or delete code? "There are no rules, not a square area". We must abide by certain "game rules" to do everything ".

After all the preparations are done, you can edit the code manually. In this process, I am always careful, for fear of errors. After a certain amount of code is completed, I will go back and check it several times before proceeding. Wait until the requirement is met.

I thought it would be great to compile the code, but this is not the case. The instructor told me that self-testing is required after the code is compiled, and it can only be submitted after self-testing is correct. This also corrected one of my previous ideas: Code testing is a matter for testers. In our company, most of the testing work is done by development engineers. The code can be submitted to the specified place only after multiple tests.

As a summary, in general, in addition to coding, we also need to do the following:

First, self-testing

The so-called "self-testing" is different from the testing conducted by testers. The purpose of our self-testing is to verify the correctness of the code we have written, and to ensure that there are as few errors as possible.

If you want to complete multiple functions, I will test a function after it is completed.

 

Second, write a document

Generally, there are many types of documents involved, including unit test documents, integration test documents, detailed design documents, user documents, and Protocol documents. If the upgrade is involved, there are also upgrade documents.

The unit test document must be compiled to verify the functions of a single function you have compiled. In this document, you must write out the examples you have designed and the results you have achieved, and what problems occurred during the test.

The compilation of integration test documents focuses on interface testing. The purpose of "integration" is to combine modules with different functions, depending on whether they can work collaboratively. The method is similar to the unit test document.

The preparation of detailed design documents should reflect the entire process of design. That is to say, what are your own ideas, why? Which modules are the most important and which functions are the key functions. The detailed design document is very important, so we can compile the code.

Exercise caution when writing user documents. User documents are generally presented to users and field engineers. If they are not well written, the installation of on-site versions is very unfavorable.

Other agreement documents may be provided by users or by the Business Planning Department. For details, refer.

 

Third, go through the peer review process

We have made something that requires peer review to be recognized by others. As the name suggests, "Peer Review" is to let experts or colleagues see how we are doing, what are our shortcomings, and how to improve.

This process is very important. Through this process, we can discover and correct our own thoughts and loopholes.

 

4. Submit and build the version

The submitted version here is not just about putting the document or code as we did at school, but about to follow the specifications. There are strict rules on where to put code, where to put documents, and how to organize the file structure. Everything must follow the rules and procedures. This is the difference between the company and the school.

After the version is submitted, the next step is to build a version, indicating that the work of our developers has come to an end, and then the tester will be "posted.

 

Looking back at the process of completing your needs, we have the following experiences:

First, take the initiative to do anything, and ask questions if you don't understand it.

Second, developers should be careful in their work, ensure that the code they write is correct, and be responsible for their work.

Third, everything must comply with the rules and cannot be done based on your own ideas.

 

Experience is accumulated a little bit. The experience of completing the first requirement has taught me a lot and laid the foundation for my subsequent work.

 

 

(My microblogging: http://weibo.com/zhouzxi? Topnav = 1 & WVR = 5, No.: 245924426, welcome !)