preface

In the second week after graduation, I began to make requirements and write codes. I felt a little apprehended, because I really had to add my own code to a real project, and I was afraid that I would mess up and cause serious problems after the code was put online.

Now after more than a month, the demand has also made a few. Some went well; Some delay; Some Bug frequency in the test phase, repeated modification; Some Crash during grayscale. Now go back and redo it, learn from it, and try to avoid mistakes in the future.

Brain outline of figure

Matters needing attention

1. Get your mindset right

First of all, it is important to pay attention to every requirement, no matter how big or small, which is a reflection of the quality of a developer. However, there was no need to be nervous at the beginning. After all, it was a gradual process. At the beginning, I only touched some small requirements, just a few lines of code, which would not be very difficult. Later, as I get familiar with the business, I can gradually cover some complex business, which is growing step by step. If I keep doing small requirements, I will feel that I am not able to use it. Grasp each need as a way to improve yourself.

2. Study the requirements document carefully

Requirements document is the most important material, all the implementation should start from the requirements document, otherwise even if do again cattle force, and the document is not on, but also in doing useless work. (If you think the requirement design is not good enough and want to provide better reference, it should be put forward in the requirement review stage, and work with PM to improve the requirement. After confirmation, it must be implemented strictly in accordance with the document.)

In the previous requirement, there was a lack of interpretation of the document, and I took it for granted when implementing it. For example, the value of buried point parameters was specified by myself without finding a data analyst for confirmation. Knowing that the current design is not in full compliance with the document and there may be inconsistencies, I did not confirm with PM, and moved the risk to the testing stage, increasing the number of bugs required by myself.

So don’t take it for granted. During the research or development, if there is any inconsistency with the documents, no matter it is caused by your own factors (maybe historical factors), you need to communicate with relevant parties in time to clarify the final plan.

3. Research

After the demand in hand, there will be a stage of investigation and evaluation before development. At the beginning, I did not know much about it. When I received the demand, I began to pull branches to write code. In fact, this is very inefficient approach, when encountering complex requirements will certainly end up in a lot of situations. For example, if it is found that the estimation time is too short, it is impossible to complete, it may need to work a lot of overtime to supplement, or even serious, it may cause the delay in getting on the bus in time. Adequate research is important. Estimate will reflect the complexity of a demand, received a demand before, although the demand is not large, but the complexity is very high, if only because it looks like the situation estimate a relatively short time, it may cause a lot of trouble for themselves. At the same time, estimate to consider a variety of circumstances, such as the burial point, self-test set aside a certain amount of time, improve their delivery quality.

Another very important point, in the research stage, must find more information, fully study the problem, will be possible to step over the pit in advance, the risk in advance, do not leave the pit to the development stage, otherwise it may cause the code writing is not smooth, write a lot of bugs. The technical scheme should also be determined in the research stage, and the coding has a clear scheme, so that the overall quality will be much better.

4. Development: Be aware of Plan B

In the development stage, in addition to following the code specification, while trying to write high-quality code, do not write out the code is difficult to understand, even after a period of their own do not understand.

In addition, the biggest lesson I learned from the previous development is that PlanB must be taken into consideration, which can be divided into the bottom-of-the-line strategy and the downgradeable plan. A bottom-of-the-pocket strategy ensures code robustness for smaller scenarios, such as non-null judgments; For larger scenarios, such as the introduction of a third-party framework in your application, you should not migrate all at once, but have a backup plan in case the framework fails to degrade to a guaranteed bottom line. In fact, there is also the shadow of this idea in the AB experiment, when the problem can be switched to the AB experiment, back to the control group, for degradation. Some time ago, there was a requirement that the copy displayed was issued by the server side. In the development stage, abnormal conditions were not taken into account and the correctness of the data on the server side was too much believed. This is definitely not possible. So the awareness of PlanB is very important, to always remind yourself whether to do a bottom and downgrade.

5. Test yourself

Self-testing is also an important part of the development process. If the self-test is not sufficient, the delivery quality will be not high, so that they need to modify the code frequently, compile, package, the process is very troublesome, do a lot of extra work, if there are other requirements are also in progress, may also delay the development of other requirements. In addition, if the delivery quality is too low, QA and Leader will also have an impact on their own views and doubt their own abilities, which may affect performance and other things. In short, as a qualified engineer, we still need to have higher requirements for ourselves, strive to improve the quality of delivery, and be a reliable developer.

Therefore, it is necessary to test yourself thoroughly. First of all, the previous considerations are also needed to provide support, after careful study of the requirements document and thorough research, in the test case discussion, need to work with QA to refine the various possible boundary cases and exceptions, so that in the future development, also pay more attention to these cases, improve the quality of the code. Then, if any other abnormal cases are found during the development process, it is necessary to inform all parties in time and confirm with QA classmates. As mentioned before, we need to set aside some time for self-testing in the estimation stage to ensure that we can fully test all kinds of normal and abnormal cases, and focus on all kinds of boundary cases.

conclusion

The above five points are my replications of what I have done for more than a month. I hope I can use these points to demand myself and strive to improve the delivery quality when making requirements in the future. At the same time, I also continue to absorb, summarize and improve my business ability and programming ability from various requirements.