Hello everyone, I haven’t written the public account for a long time. Recently, a friend attended an interview and was asked about the development specifications. Suddenly, he found that he was working every day, but did not pay attention to this problem.
As for specifications, every company has its own unique development specifications. In the final analysis, only good specifications can improve the efficiency of a team. Next, I will briefly talk about the development specifications of my company, if we can gain something from them, it is worthwhile.
Interface specification:
1, before the development must first define the interface, define the interface must think about your requirements, logic, in writing the interface document when you have already realized your needs in your mind.
2. The interface you define should also have standards, including no redundant fields, the data format of the formal environment and the test environment must be the same, the documentation and the real development interface must be the same, etc.
3. In the process of development, if there is any change in the interface, it is necessary to communicate with the front-end or client in a timely manner to avoid delay caused by information asynchronism.
For example, if the status field is int, you give it all enumerations and let it loop to determine which Chinese should be displayed. If the interface is defined like this, then the interface is not qualified. You can add a field to the interface return data to save the user extra work.
On-line specification:
1, after the completion of the first in the development, we need to self-test, self-test standards are not particularly high, only need through the smoke test, to be able to go through the normal process is ok, don’t self-test haven’t measured it to test, when test of painstaking record the data, go normal process when a system exception, this kind of mood should be very acid bright. Only when these routine tests work will the test give you the less obvious problems, and if the test always goes round and round on the obvious problems, the product may not be of high quality in the limited time.
2. Secondly, after passing the test, pay attention to whether resource application is needed in the formal environment, such as server, REDis and database. Work orders for these things should be submitted to the operation and maintenance in advance, so that the operation and maintenance can take their time to prepare, and avoid too long delay on the launch day because resources are not ready.
3, Once the test passes and the resources are ready for operation and maintenance, we can deploy the code online. Our code should now be on the dev branch. We need to merge the code into the master branch. We always make sure that the code on the master branch is consistent with the online environment), and then we can deploy the project through Jenkins or other deployment tools.
4. After deployment, we can’t directly notify the test to test. We need to use our test cases to visit the interface of our formal environment first to see if it works properly, and then inform the test to test back. Waiting for the test report reply (every time I heard the test said there was no problem when I went online, MY heart suddenly became clear).
When deploying online, review the dev and Master branches after merging the code to avoid unnecessary problems.
When we encounter problems in the formal environment, we need to locate the problems through our own test cases. Tomcat can be used to determine whether there are code problems in the service. If there are code problems, we should be careful when merging the codes for the second time after modification, and cross review can be used. If the fault is a configuration problem, contact O&M to solve the problem. After the deployment is complete, tag the master branch with the main contents of the deployment in the tag.
The above is just a simple description of the interface documentation and on-line specifications, and then I will say the specifications related to database design, as a summary of my knowledge, but also hope to help others.
Here we will share technical dry goods and summary of daily work for a long time. Your likes, forwarding and favorites are the biggest support for me, thank you.
