As a programmer , We seldom participate in the development of a new project from the beginning to the end . If you often develop new projects , Then you are so happy .
More often, they enter a project team halfway for development , Or someone else left , The system previously maintained by him is transferred to you for maintenance .
Another situation is that leaders don't know where to get a system and a bunch of documents , And then I'll just leave the system to you for maintenance .
How can we quickly get familiar with the first-hand projects in the above situations , How to deal with production problems ? Here is a summary of my work , I hope it can help you .
The information should be complete
When you take over a new project （ Other people's projects ） When , You need to get all the information to the person who handed over the project to you as soon as possible . Because after that , This colleague may leave , It's not convenient to have any more documents then . Normally , You need to get this information ：
* Address of project code （svn Address or git address ）;
* System deployed Linux Machine address , Login username and password （ It's convenient to log in and check the operation of the machine ）
* Database address / User name / Password （ Don't assume that all projects will have usernames and passwords , Some projects will encrypt the user name and password ）
* Login user of the system / Password （ If the system has pages , Will be able to log in to a user , No need to reinvent users ）
* Other middleware addresses （MQ,Redis etc. ）
* Requirement document
* Interface document
* All other information （ Required for the above documents , If you can get other documents besides that , Can be saved ）
Understand the technology stack
After getting the documents , My personal experience is to quickly browse the documents first , No need to see every paragraph of the document , But we need to know what the system is about by skimming the documents , What are the functions . This is very helpful for us to see the code later .
Familiar with project technology stack
After a quick review of the document , We're going to start looking at the code . This stage , You need to be able to run code locally , Know what technology stacks are used in this project , What is the role of each technology stack .
Familiar with upstream and downstream systems
The upstream and downstream systems are clear , We know who called our system , Or who our system calls , If you look up a problem, you'll have a definite purpose .
Know where to check the log
Log is the key to online problems , You have to know how to check the log , Where to check the log .
Know how to pack
Meet new needs or change Bug After that, you must release it , Then you have to know how to package and deploy this .
Know how to deploy
Familiar with business code
It's the most critical step , But for this step, I think different systems can be treated differently . We take over some systems to develop and maintain them for a long time , Then we need to sort out the business of this system .
But some systems are stable , No more new features , We need to weigh whether we want to study this system in depth or not . Because the cost of time may not be worth it .
Here is the general process I am familiar with ：
step1： Before looking at the business code , First of all, we need to read the table design of the database , Otherwise, I will not know .
step2： And then I'm going to sort out the interfaces , Generally, each Controller（ General system functions are through Controller Exposed ）, If you can follow every interface debug Once again , The whole calling process is clear , Then you can sort out the business （ This step is best sorted out according to the interface documents ）
step3： Of course , The functions of the system are not all controlled by Controller Provided , Some are triggered by timed tasks , So you need to see what timing tasks are configured in the system , What functions are implemented ;
step4： The other function is through consumption MQ Triggered , So let's see if we have one MQ Related interactions ;
step5： Similar to other interactions
There may not be a common way to be familiar with business code , We still need to sum it up .