How to quickly take over a project (internal project or open source project)

1. Understanding the Project

Read the relevant documentation and articles, at least know what the project is for, what features to run on (mobile, PC, or multi-platform), release license (Gpl,apache or??). ), Target format (applications, libraries, middleware, etc.), etc. Usually these problems can be found in the documentation of the project, Wiki,faq and other places.

2. Get the source code

This needless to say, no source you also study what, this official document will say, usually through SVN or git, of course, also have the source code package download (if the source is relatively small).

3. Compile and build a target product that can be run

Later on, the source of light is like reading Boolean algebra, or Marxism, are dry theory, let people irrelevant, not touch the mind, forgotten also quickly, the most important thing is no field use. Often the source of research is to make changes.
Compile and build the project will also have a special document, the biggest difficulty is the build environment, due to different development environment differences, compilation is usually not possible once success, it is necessary to look at the official FAQ, or Google, or it is easy to solve.

4. Running

Be sure to run it yourself, play, and see what functions you can accomplish. To understand the source of the project, first of all must be familiar with the project from the user's point of view, each function must be tried and familiar. Try some extreme operations, enter unconventional data, and see what happens.

5. How to Debug

This depends on what language and what the target file, overall is the tool and log logs, the tool is nothing more than eclipse,gdb, such as log to see the specific project, each project will have its own log mechanism. Check the documentation or search the Web.

6. Read unit test Cases

Do not come up to see the source code, so it is easy to get lost in the source, especially when the source of the project is many, you do not know what this class or method is used to do, the dependencies between the class and association more confusing and fear, resulting in a quick loss of interest.
You can read the unit test cases first, which are live documents of the code.

7. Grab a function point, drill down into the debug tracking process, and analyze the code until it's clear

This is important, although we have to understand the whole project, to grasp the whole, but it takes time, it is impossible in a short time. A better way is to catch a function point from the upper layer has been tracking down until the entire function point of the process to make clear, analyze the code, draw a diagram (without the standard UML, can read, can express meaning can).

8. Modify the source code, compile and run, see what changes before and after the changes, this is the best way to sense the use of code

In order to sense the code, make changes, and then run, see changes before and after the change, this can quickly sense the role of the Code. Especially for parameters, it is difficult to see the code of the large number of parameters is what to use, modify it, change to the opposite value or change to a non-conventional value, see how the program reacts, and soon can know its role.

9. Modifying unit tests or writing unit tests

This is also a good way to sense code, writing unit tests, may involve decoupling, if the relationship between classes is too tight, it is necessary to decouple the separation, it is possible to read Michael Feather's "Working with Legacy code" in the "Sense and Separation" section.

10. Try to understand the business logic of the entire project

This is something that needs to be done, to study a project, or to maintain a project that makes it clear that the overall business logic of the project must be done, but it takes time. So you can't give up, depending on the size of the project it usually takes months or even years. A bit of accumulation, a day to see a little, a long time on the whole project is familiar.
The key point is to conquer, don't look at the code. Grab a function point, track, Debug, modify, run, make it clear, then turn to the other function points, when all the functional points are understood, the whole project is naturally clear.

11. Refer to the project's documentation and other written articles

This can speed up understanding of code and business logic. It is best to refer to the documentation for the project (design documentation, etc.), but many projects are not documented.
For the article on the network must have the suspicion of the heart, can be used as a reference not to rely on, but not all-faith. Its value depends entirely on the author's level and the author's understanding of the project code, as well as its ability to write and the time spent on the article. There are few good articles on the internet, just a few articles at the beginning, then there will be a lot of copy and reprint, so for some questions you will find the article is actually the same article, in other words, the overall quality is not high. There are also false or misleading ones. In addition to the timeliness of the issue, the project code will be persistent updates, but the published article but few people update it. Therefore, the document on the network must have a skeptical attitude.
In addition, it is best to use Google search English articles, usually speaking of foreigners writing articles or more reference value (people are very impetuous AH).

12. When you have a certain understanding of the project and the code can write a document or article to deepen their understanding, but also share to others own experience

Writing an article, drawing a chart, this is the best way to test your understanding of the project, you can tell others clearly, you can understand the project is the best proof that you understand the project. Be careful to write your own understanding, the table copy code, according to the code to draw out the sequence diagram, prove that you are not familiar with the code, and do not understand the code, for others is useless, must be expressed in their own words. In order to deepen their understanding, it is also a help to others.

13. Tools: Eclipse,vim+ctags+cscope, gdb,grep,find These tools have great help in browsing the source code, how these tools can be used under Google, a search a lot, graphic tutorials, quite detailed.

How to quickly take over a project (internal project or open source project)