Preface
-
As the environment changes, everyone will always change jobs, some will be laid off, and some will change jobs. In addition to the old people coming in and out, there will also be a steady stream of new people entering the job.
-
Many people don't know how to adapt to work quickly after joining the company. For me, except for the few feelings of colleagues, changing jobs is more like changing the office environment.
-
Today I will record the work process of each function development. Of course, this process is not representative, especially compared with the perfect system of "big companies". This can only be regarded as a guide for newcomers. Each company's requirements development steps are different. Let's improve this development step together and point the way for latecomers.
Note: Steps are dead, people are alive. If you are unclear, ask questions in time. After all, there is no charge for asking questions to colleagues.
1 Obtain development documents
- Before development, there will be auxiliary materials such as development documents and product prototype instructions. Even small and simple functions will basically have corresponding descriptions. If it is all about verbal description, then? run? ! hhh
2 Requirements understanding and preparation
-
When reading the requirements document, you need to read it carefully, and while reading, figure out the positioning of this function. Especially for those who write code, you still need to figure out which functional module this function belongs to, or at least where your code is written.
-
Whether it is stone carvings or building new stone mountains, the relationship between the functions must be clearly understood. Is this function a new function or an extended function? The code associated with this function and other modules must be read, and the relevant data tables must be sorted out in advance. one time. If the context is unclear, the developed functions can easily deviate from the actual functional requirements.
-
If you still don’t understand some parts by reading the code, documents, and requirements documents, don’t worry, because there will be meetings to discuss them later. All you need to do is try your best to understand them. You can ask other colleagues about things you don’t understand. If you still have questions, write them down and ask them during the meeting. I have also encountered such a situation. I was a little panicked at the time, but after the meeting, I understood.
3 meeting minutes
-
Meetings are still relatively important. If you keep getting confused during the first meeting, then you need to review your homework.
-
It is necessary to clarify the required function points and development function points at the meeting. If you encounter difficult points, you must ask questions in time. If you still do not understand something at this time, you must ask questions clearly at the meeting. If you are not clear, development will be very painful. At this time, it is particularly important to understand the requirements in advance, read the relevant code, and understand the database tables in advance, otherwise you may not know what the meeting is about.
-
The important information captured at the meeting should be roughly recorded. My suggestion is to bring a notebook before the meeting: a good memory is not as good as a bad writing.
Note: At this step, decide whether you can communicate effectively with product colleagues
4 Interface definition
- After the meeting, it is usually necessary to define the interface data, input parameters and return values, and fixed interface structure with the front end to avoid major changes to the defined structure in the later stage, otherwise it will easily hinder the development progress of the project.
- As a back-end, one principle is: try to pamper the front-end as much as possible. Try to do what the back-end can do on the back-end. Adhering to the principle of not letting the front-end modify it, don’t let the front-end modify it. If you pamper the front-end like a little spoiled wife, you guys Wouldn’t the docking work be easy and enjoyable? The development of a function must not be done without the front-end, otherwise it will be like playing house alone. If there are any modifications, notify them in time. Don't wait until the end and directly send the document to the front-end, which will undoubtedly increase the workload of both parties.
- If there is no special interface tool class, so after sorting out the interface structure with the front end, it is best to sort it out yourself, so that there will be no ambiguity during the development process.
Note: Many back-end developers have unpleasant quarrels with front-end colleagues because the foundation here is not laid properly.
5 Code development
- Before code development, you need to clarify which branch your code is based on. How to clarify? Just ask! Everyone will ask, so I will take a screenshot of the current development branch information. Never refer to documents blindly. Some documents are never updated after they are written. So you need to communicate more with colleagues or leaders. Try to understand the function of each branch as much as possible, which will help us with our subsequent work.
- After the function development is completed, I need to debug it locally. Most of the time, I use postman to request my own interface to see if the input parameters and return values are the same. Generally, when we debug, we turn on the login-free function and focus on the interface functions. To avoid logging in, you only need to add the @NoLogin annotation to the interface. As for unit testing, everyone decides according to their own situation. This is hard to describe.
6 Code submission & environment construction & front-end and back-end joint debugging
- After the code development is completed, it needs to be submitted to the test branch for joint debugging with the front end (or local joint debugging is also acceptable)
- After the code is submitted, you need to use Jenkins to build the environment (this step is different for each company)
7 Code review & release document writing
- After the release is completed, just wait for the front-end joint debugging to be completed. After the work is completed, you need to write a release plan document and find someone to help review the code.
At this point, the main work of back-end development is almost completed. What is left is continuous testing, bug modification, and release. The specific implementation of the subsequent steps will be different for each company. The last step is to submit the code and merge it into the master. However, we may not have the permission to merge and handle it according to the actual situation. At this point, the development of a function is basically completed.
end
- It seems that I have finished speaking, but it seems that I have not finished speaking. This article is mainly described from the perspective of "working" as a back-end development. Of course, I don't want everyone to stop here. For example, many times, we need to write our own technical document based on the product document, and then do a technical review, or the ability to communicate across departments in each link is particularly important, and it can often show how strong a person is. Finally, I wish you all success in your career~