preface
In the days of the spring breeze, golden three silver four job-hopping season, I believe that many partners have got the offer, including some of the students who have just entered the workplace. So today, I would like to share some experience about the development process at work from the perspective of the service side. I hope that the students who have just entered the workplace can pass the assessment smoothly as much as possible.
Enter the company you will find that the classical point of companies will be many departments, such as development department (Ministry of Science and Technology or r&d), production (sales department), the two departments is reciprocal, meaning that the latter is responsible for product function creative, design, product direction, namely is responsible for the product demand, put forward the control of the product positioning and direction; And the former is the acceptance of requirements, responsible for software, technical level to achieve the latter proposed requirements. There is no subordinate relationship between the two departments.
For us programmers, the complete process of making a demand from receiving the demand to going online is roughly as follows:
- Requirement analysis (including requirement survey, requirement discussion, requirement determination, interface validation)
- System design (design the implementation details of the function, what technology to use, etc.)
- System implementation (function realization from software code technical level)
- Functional testing (including development self-testing, submission testing, business testing)
- Online requirements (business acceptance, whether the acceptance is passed, whether the code is rolled back)
Demand analysis
From the moment you get the requirements document, you will see that the requirements document contains at least two sections that explain the requirements: the requirements background and the requirements description.
Requirement background: Mainly tells you why you have the requirement and what the purpose of the requirement is. Requirement description: This is the main point of this requirement. It mainly tells you what to implement, what to achieve, some business rules, etc. It may include a few prototypes of the page, which would be great.
These requirements are considered by the business department and approved by leaders at all levels before they are sent to the R&D department. The R&D department accepts the requirements and distributes them to your team leader or directly to you.
Anyway, you get the requirements, you open the requirements document, you start looking at the requirements.
1. Read through quickly
Can first quickly read through, understand the general meaning of the demand, have an overall grasp of the demand, do know.
2. Focus on key points and remember questions
And then the second time, look at the details, catch the question point. It again, and you can see careful, put some key points carefully see understand, look at the same time, may find written requirements are unclear, or need to confirm, or you will have some questions, this time you can record the points down, carefully read it again after you record some problems.
3. Answer questions
After reading it twice, you have some questions. Then you can find a time to draw the head manager or demand, the development team leader, front end developer, business (demand of business personnel, he is a man is best know to demand), test head together a meeting face to face, can not face to face in the group chat), records to solve your questions point, write these needs do you think the uncertain place. The process is to answer questions.
During this discussion, the business rules must be recorded. After the meeting, you can send an email to write down the confirmed requirements or the new things added by the business, remind the business to update the requirements document after the confirmation, and cc the email to the people in the meeting.
Why take so many people with you? Because you have questions where your team leader, manager, etc., may also have questions, this kind of final decision can not only let you know, when the time comes to finish the line, the business found that it does not want that effect to fail to recognize how to do. The purpose of pulling tests is to avoid discrepancies between development and test understanding of requirements, and to avoid discrepancies between test cases written by tests and requirements.
Why email? This step is also done to standardize the development process and to provide proof that you have something to back up against later questions about why you did it. Otherwise you just say: that was the discussion. That’s not convincing enough. We must do it, do not throw the blame and do not blame for nothing!
4. Prepare materials
In the process of requirement discussion, if other systems are found to be involved, put it forward and confirm whether the interfaces of other systems are well provided, and ask for interface documents from other systems through the project manager (it is better to send and receive documents between systems through the system manager, even if they are internal systems); In addition, if UI needs to be provided when page changes are involved, urge the business to provide UI in time to prevent the delay of demand online.
Why UI? The purpose of the UI is strictly in accordance with the SIZE of the UI map, color value to do the page, to prevent the front end of the page after the business to buckle these details, so that you rework, but also appears that you do not work smoothly. If some companies do not have a UI designer at all, it is good to advance and business, do time to let the business to check, see whether compound he wants the effect.
5. Work records
Secondly, for this demand, when writing the daily work progress (daily), write down the stage of the current demand (such as demand analysis stage, development stage, etc., the specific stage of the evaluation, as well as the current obstacles, etc.). So if there is an obstacle, even if it is delayed online, it is not their own reason.
Note: 1. It takes 1-2 days for system indirect interface joint adjustment, and it may take longer for complex interfaces. System tuning is best done before system design, so that you can find out if the interface returns content that meets this requirement and ask the question. If you use this interface when you develop and then find the problem, it is not a waste of time.
2. If the system is called for the first time, attention should be paid to opening the network between the systems, otherwise it cannot be accessed. Open the network of course also need project leader to apply. The network of the test environment and production environment must be enabled together, and then test whether it is really enabled. So to prevent the network has not opened, online after the adjustment, and temporary email application to open the network, so will only make you embarrassed, appear you this person is not careful enough.
The system design
Requirements analysis, interface coordination, network opening and other preparatory work and chores to finish, you can start the system design or processing side of the system design (because you wait for the UI, open the network need time).
System design is to think about how to implement this function, realization process is what kind of, do you want to add tables, or increase the table fields, how to design the table structure, want to write a few interface to a front end, call order is what kind of, what kind of data returned, what kind of data format, can discuss and front-end development together. These should have a general idea after you analyze the requirements, and then extract the keywords and key points of the requirements for specific detailed design.
System design is also a very important part, is before writing code set goals, do a macro plan. Try not to write code while trying to figure out how to implement it, this will lead to a messy end of the code.
It is recommended that you draw a flow chart and review it within the group when conditions permit to find out the deficiencies.
In the system design stage, if a new technology needs to be introduced, we must consider what technology to use, the complexity of the technology, maturity, etc., why to use this technology, what are the benefits. If you’re not sure what technology to use, talk to your technical manager or a colleague with more experience. Just enter the workplace or experience quite little of the students, you can put their design ideas and they say, let them check.
System implementation
This step is your favorite code writing stage, write code some norms need not I say more, download Ali’s development manual to see, or their own company’s development norms.
Business code must be annotated, with simple annotations in key steps, so that when you look at it in the future or when other colleagues take over from you, you can see at a glance, understand what the code is doing, so as not to be teased and scolded behind your back. Many times some students write their own code, without a line of comments, a long time to see their own time are mengbi. Adding necessary comments is a programmer’s minimum.
When the feature is nearly halfway developed, email the test leader and cc the relevant person to inform them that the requirement is halfway developed, in order to remind them to write the test case of the requirement so as not to delay the test. This point is based on your development process, I suggest so.
A functional test
After the development is complete, the functional testing phase is entered, or the development of a certain interface (for the front-end call) developers can test while developing.
1. Develop self-test
Developers of their own development of the function of their own test, the main test interface logic, input and output parameters is correct, etc., while developing side test, before and after the end can be tested together.
When the whole function is developed, the developer will test the whole process of the requirement, focusing on the scenarios where problems may occur. When the local test is almost the same, the code can be merged into the test environment to conduct a complete test again. When you feel that you can, ask the group leader to initiate a walk through the code, mainly check the code logic and code specifications and other common obvious problems (after all, the bystander may look at the code for a long time and not find the problem), if there is a problem, change it, check the problem can be submitted to the tester.
Here the walk can be recorded to the code walk record, mainly write the person in charge of the walk, developers, walk time, demand name, walk found problems, whether to solve, when to solve and so on. By walking through the code, you can prevent the same problem from happening again, or everyone can learn from each other.
2. Submit tests
After the completion of the self-test, email to the test leader and related personnel, email stating that the requirements have been merged into the branch, or published in the test environment, now propose testing this requirement, timely test, etc.. It also describes the functions and systems involved, as well as the main test points. Then you cooperate with the tester, there are bugs to change the bug.
3. Business testing
When the testers are done, they email the business people. After the business test, I think it’s ok, so I’m waiting to go online.
Demand for online
Check your code integrity before putting requirements online, and submit SQL statements (such as new system parameters, new table structures, etc.) and modified configuration files (new or modified configurations) to O&M. (Important!!)
On the day the demand goes live, you stay up all night waiting for it to go live (most of them go live at night to avoid the rush hour, and some of them can go live in advance). When the production is finished, the testers and business people will verify the production. When the business says that the acceptance is passed, congratulations you can go home. If there is a problem, you have to go to the log to troubleshoot the problem, and then solve, and then verify; If the problem is serious, your code needs to be taken down.
The last
Once online, file all documentation related to this requirement and submit it to your documentation library or a development management platform such as Confluence. If you don’t have such documentation or are not required to do so, you can save it for future reference.
conclusion
Software engineering is a discipline. From the perspective of back-end programmers, I share my summary of requirements development process and experience in avoiding setbacks in the development process. I may write a little rough, or talk a lot of nonsense, and some companies may be less standardized, or some companies may be much more complicated than this process. However, the requirement analysis and system design mentioned here should have nothing to do with the development process set by the company. It is the developer’s own habits and experience, and the norms set by himself. Or that, we programmers do not blame blame for nothing!
“The END”