Where do you start from the two-week handover of projects with 20 persons in one year?

As a program developer, it is very important to have the ability to learn new knowledge. This is determined by the particularity of the IT field. Our new knowledge includes not only new languages, new skills, new tools, but also a brand new project or even a new development environment. Recently, one of my colleagues encountered the following problem: a 20-year project needs to be handed over to him within two weeks due to organizational structure adjustment. This is a pure commercial project, with customers constantly asking questions, and company leaders constantly "care" about status updates. The pressure on customers can be imagined. Let's imagine what would you do if you were in such an environment? How can we quickly get started with a strange system?

Let me talk about this question first. Some of these points are a summary of similar experiences over the past 10 years, and also include some experiences shared by friends around you.

First, you need to familiarize yourself with the business background, that is, the industrial background knowledge.
Because there is nothing more important than figuring out what you want to do. Different business logic needs different software architecture support and needs to process different work flows. Familiarize yourself with the business background as much as possible to help you better understand the specific problems you need to solve in your project, and help you quickly create a large picture about the current project. Please start from this step.

What should we do next? Is it written into the code? Don't worry! Ask if you have any documents about architecture design. What you need next is to understand the software architecture from a macro perspective, the structure of the software at a large level, and the components of the software. How do these modules work together? Before doing any meticulous work, you need to outline the rough line of the item. Almost all software projects are inseparable from the flow of input/output and data. First, find out how data is transmitted between layers or modules. In general, what logic functions are needed to process the data.

After the above two steps, you have a general understanding of the competitor's first project. So far, all you know is based on static documents. Next, based on my experience, you need to get the program up as soon as possible-set up the development environment, prepare representative sample input data, and debug it in detail. At this time, F5 + F10 + F11 (VS) is your best helper. A good code structure will express the program's processing process as clearly as possible. Of course, you can't expect to simply grasp the accumulated work of others for months or even years through several cycles. However, dynamic debugging helps you go inside the program to get a glimpse. Once I have a general understanding of the program, my personal feeling is that the sooner debug comes, the better. During initial debugging, try to understand the program based on the understanding of the architecture and avoid wasting too much time on details. Skip this step if you don't quite understand it. The core objects that appear multiple times are recorded first and then carefully studied.

After several rounds of initial debugging, you will intuitively feel the program process, but many specific things are still unclear. At this time, as a caring person, you will accumulate a lot of problems. How are several core objects working? How is the relationship between classes designed? What design patterns are used? How is the data object of a program expressed? These are already specific issues. Only by asking specific questions can you understand a specific level. At this time, if you have good OOD and OOP experience, you will often be guided to think down. It is recommended that you do not stop to dig deep. Start the UML tool and try to analyze the structural hierarchy of the core class. A deep understanding of the core methods (algorithms) of core types ). Analyze how to design and package the data model. After figuring out the data model, you can try to modify the data to see how the program reacts and verify that what you understand is correct. And so on.

In fact, in addition to the correct method, you must be able to grasp the key points of a strange system within a limited time. Find the pain points of the program itself and check out the problems most complained by the customer. This is also a problem that needs to be solved by the project itself.

Programming is a science, but code organization and analysis is an art. Understanding a new project can often test a person's ability to understand new things. Quick understanding is inseparable from long-time development experience, and of course there is a trace of inspiration for the Code itself. There is no end to learning. Reading and maintaining others' code is also a good learning method.