How to familiarize yourself with an open-source project

From: http://www.blogjava.net/killme2008/archive/2012/05/22/378885.html

You have a task and need to use an open-source project. Or, the boss tells you something to let you know something. How can this problem be solved? How to get started? My habits are as follows:

1. first, search for and read the blogs and materials of the project. You can use Google to find the blog about a project, you can get a general idea of the project's purpose, functions, and basic usage.

2. Read the project documentation and focus on documents such as getting started and example to learn how to download, install, and even use the project.

3. if a ready-made example project is provided for this project, first try to run example according to the introduction in the Start document. If it runs smoothly, congratulations! If you encounter any problems, first, try to find the answer in the FAQ and other documents of the Project. Again, you can use the question (for example, exception information) as a keyword to search for the relevant solution, others may also encounter the problem. Enthusiastic friends will record the solution process. Finally, you can submit the problem to the project's email list. Please take a look. Do not modify example before running example successfully.

4. After running the first example, try to modify the example according to your understanding and needs, and test advanced functions.

5. After learning about basic usage, you need to get to know more about the project. For example, project configuration management, advanced functions, and best practices. Generally, a well-functioning project will provide a user guide from the shortest to the deep test. You do not need to read this guide from start to end. Based on your time and interest, especially your own task needs, read and take notes (Evernote is recommended ).

6. If time permits, try to build the project from the source code. Open-source projects usually provide a build guide to guide you how to build an environment for development, debugging, and building. Try to build a version.

7. If time permits and is interested, you can try to read the source code:
(1) Before reading the source code, check whether the project provides the architecture and design documents. You can read these documents to understand the general design and structure of the project. You will not be able to read the source code.
(2) You must be able to build and run the project before reading the source code.
(3) The first step to read the source code is to grasp the backbone and try to clarify the call path of a normal running code. This allows you to use DEBUG to observe the variables and behaviors during running. Modifying the source code and adding logs and printing can help you better understand the source code.
(4) draw appropriate pictures to help you understand the source code. After clarifying the backbone, you can draw the entire process into a flowchart or a standard UML diagram to help you remember and read the next step.
(5) read the "branches" code you are interested in. For example, if you are interested in network communication, read the code at the network layer and go deep into the implementation details, such as the library it uses, what design mode is used, and why. If possible, DEBUG detailed code.
(6) When reading the source code, pay attention to unit tests and try to run unit tests. Basically, a good unit test will clearly describe the functions and boundaries of the Code.
(7) after familiarizing yourself with the source code, you may find that there is something that can be improved. If you have the energy and willingness to give improvement suggestions or issue to the developer of the project, or even help him fix and implement the problems, participate in the development of the project.

8. after reading the documentation and source code, you can have a deeper understanding of the project. However, you may want to search for related projects and materials in the project field, check whether there are other better projects or solutions. Weigh between breadth and depth.

The above are some of my personal habits, and I did not fully follow this, but in this order, it basically allows you to learn and use an open-source project more efficiently.