1. Preliminary understanding of the project

After opening an open source project on GitHub, the first thing to do is to read the README.md introduction document of the project. You can take a quick look at it to see if there is any content that can help you learn, such as technology selection, function introduction, and how to quickly start the project. , architectural design, precautions, etc.

Take the MallChat chat room as an example: https://github.com/zongzibinbin/MallChat. The project introduction document contains an introduction to the core functions. You can see if there are any functions you are interested in:

If it is an internal company project or a relatively mature open source project, there will also be a Wiki document, which often introduces the project in more detail, but there is no need to read the entire article for the time being. Pay attention to the "Quick Start Project" or "Project Structure Introduction" section. That’s it.

For example, if I am determined to learn a new project, in addition to the official GitHub documents, I will also collect some relevant information online and organize it into my own documents so that I can quickly find it during subsequent learning.

2. Understand the project structure

After reading the project introduction document, it is recommended to first understand the overall structure of the project from a God's perspective, such as what modules the project is divided into, roughly what files each module has, what are the file naming rules, etc., but there is no need to further understand the internals of the modules (or directories). organization and implementation. Especially for complex microservice projects, doing this can quickly help you locate the key points of learning.

In most cases, everyone should download the project code locally to study. But if you just want to quickly understand the project and don't intend to study in depth, there is actually a more efficient way.

For example, press on the home page of the GitHub repository. By pressing the period key, you can quickly enter the web version of the code editor, which is almost the same experience as browsing local projects:

For developers with certain experience, they will usually look for key files first, such as package.json (Node.js) for front-end projects, pom.xml (Maven) or build.gradle (Gradle) for Java projects, and requirements for Python projects. txt or setup.py, etc. These files usually contain project dependencies and configuration information. If the project is relatively standardized, you can generally quickly understand the project structure through dependencies and configuration information.

For example, if you see the aop dependency, you will know that the project uses aspects; if you see the freemarker dependency, you will know that there will be an FTL template file in the project resource directory; if you see Redisson, you will know that there will be a configuration class that initializes the Redisson client. These are The importance of accumulating experience.

3. Run the project

If you want to learn the project formally, don't rush to read the source code first, but run the project successfully locally first, so that you can learn while debugging later.

The steps to run the project are simple. Use the git clone command to copy the project to your computer, then follow the instructions in the README file or other documents to install the necessary dependencies of the project, modify the local running configuration, and finally run the project.

Although the steps are very simple, the reality is that people often report various error messages after pulling the project locally. Therefore, you should pay special attention to the following points when running the project:

Make sure that your system environment and project requirements are consistent. For example, pay attention to the front-end Node.js and back-end JDK version requirements.

Make sure that the versions of project dependencies are consistent with project requirements, such as the versions of MySQL and Redis that the backend depends on. For this mainstream technology, under normal circumstances, as long as you don't use a version that is too new, it will basically not affect the operation of the project.

Modify the local running configuration to your own, such as database account, password, etc., and be extra careful not to read the wrong configuration file, otherwise you may still be wondering "Why does the configuration not take effect" after changing it for a long time?

It is normal to encounter errors, because not all open source projects are "easy to use and easy to get started." When encountering errors, we only need to locate the key error information, and then follow the clues to find the corresponding files to modify. I really can’t figure it out. Aren’t there search engines and AI?

Here is a common technique for running projects quickly. Sometimes the project uses a lot of dependencies (for example, MinIO, RocketMQ, etc. are used in MallChat), but these dependencies are not installed locally, causing the project to fail to start. As shown below, because I did not install RocketMQ, an error occurred when connecting to RocketMQ at startup:

To start a project, the traditional method is to install all the dependencies yourself. However, if the project only uses a certain dependency in an inconspicuous place, it is not cost-effective to spend time installing it. At this time, we can use a simpler method to directly disable the loading of beans that use these dependencies.

For example, adding exclude to the startup class can quickly disable the automatic loading of certain dependencies. The sample code is as follows:

@SpringBootApplication(exclude = {RocketMQAutoConfiguration.class})

However, after disabling RocketMQ Bean initialization, if any code uses this Bean, an error will be reported due to missing dependent beans. In this case, you can use the @Lazy annotation to lazily load the Bean. It will only be loaded when it is used, and no error will be reported when starting the project. The sample code is as follows:

public class MQProducer {

@Autowired

@Lazy

private RocketMQTemplate rocketMQTemplate;

}

4. Understand business processes and database table design

Before reading and studying the code, it is best to have an overall understanding of the project's business process and library table design, which will help clarify the order and learning direction when reading the source code later.

Core business processes can be understood by reading documentation or experiencing the system yourself. For example, for a chat room system, the core business process is: user login => user online => add friend => create room => join room => send message => message review => other users receive message => reply to message.

There are also skills to understanding the database table design of the project. Rather than looking at the SQL file directly, I usually initialize the database locally first, and then view it through visual charts.

As shown in the figure, the relationship between the tables is clear at a glance! For example, rooms are divided into individual chats and group chats. There are multiple conversations and messages in a room:

5. Read the code

When you first start reading the code, don't rush to read the code line by line in order. Instead, you must first fully understand the role of each directory and the file organization form within the directory. However, you do not need to understand the specific implementation in depth for the time being.

For example, for the MallChat project, you must first be able to clarify the information in red letters:

There is a little trick when viewing the file organization within a directory. You can right-click a package directly in IDEA to view the UML structure diagram:

Through the structure diagram, we can quickly understand the relationship between classes. For example, in the figure below, the factory creation strategy and two specific strategies inherit the abstract strategy class:

After that, you can find the core functional modules of the project you are interested in and learn them. Here are a few learning tips:

1) If you want to quickly learn the implementation of a certain function, it is recommended to first understand the business process through documentation and other methods, and then learn the source code. When studying source code, it is recommended to start the project in Debug mode, send requests through the interface document (or front-end), and completely analyze the processing flow of a request.

You can quickly view the interfaces in the project and locate the source code through IDEA's Endpoints function:

2) If you want to quickly understand the core structure of a single file (such as methods and properties), you can use the Structure function of IDEA, as shown in the figure:

3) You can use the Call Hierarchy function to view the hierarchical structure and relationship of methods, classes or variables called in the program. For example, in the picture below, I looked at the caller view of the doMark method. I can see which methods call it, which makes it easy to quickly understand the interaction between codes without having to go through it layer by layer.

4) You can quickly view all usage locations of a method or class in the project through the Find Usages function:

5) Of course, for complex functions, you may not be able to understand them by looking at the code alone. In this case, you need to use documentation and code comments. What? No documentation? ! Don’t write comments? ! Then just find the original author through the Git version control tool and ask.

6. Understand project development processes and specifications

After you are familiar with the project, you can try to participate in development. You can first read the project's contribution guide or development documentation to understand the project's development process, development specifications, etc., and be consistent with other developers of the project. If you have any doubts, you can take a look at how other people's code does it, and just imitate it; if you are really unsure, it's best to ask in advance instead of submitting a bunch of code that doesn't meet the specifications, only to have others call it back, which is a waste of time. Time for each other.

7. Participate in projects

Finally, the best way to learn about open source projects is to personally participate in project development. This is what I always recommend everyone to do. It can not only improve your abilities, but also add points to your resume.

In fact, it is not that difficult to participate in open source projects. You can first check the bugs reported by others in the Issues section of the project, and help fix them, so that you can become familiar with the entire process of participating in open source projects. You can also communicate with the author later and try to add new features, optimize, etc.

If you want your contributed code to be accepted by the author faster, you must communicate well! Because I have many open source projects myself, and some friends have contributed code to me, but it is impossible to accept all codes. Because everyone has different ideas about the project, without communicating with the author, the functions you make may not be helpful to the project, exceed the project plan, and will instead make the project more complicated. The same goes for team development. Everyone should review the requirements together to ensure that the requirements are valuable and match the project positioning, rather than just adding functions if anyone wants to.

OK, the above is what I will share in this issue. It is not easy to be original. If it is helpful, please like and support!

1. Preliminary understanding of the project

After opening an open source project on GitHub, the first thing to do is to read the README.md introduction document of the project. You can take a quick look at it to see if there is any content that can help you learn, such as technology selection, function introduction, and how to quickly start the project. , architectural design, precautions, etc.

Take the MallChat chat room as an example: https://github.com/zongzibinbin/MallChat. The project introduction document contains an introduction to the core functions. You can see if there are any functions you are interested in:

If it is an internal company project or a relatively mature open source project, there will also be a Wiki document, which often introduces the project in more detail, but there is no need to read the entire article for the time being. Pay attention to the "Quick Start Project" or "Project Structure Introduction" section. That’s it.

For example, if I am determined to learn a new project, in addition to the official GitHub documents, I will also collect some relevant information online and organize it into my own documents so that I can quickly find it during subsequent learning.

2. Understand the project structure

After reading the project introduction document, it is recommended to first understand the overall structure of the project from a God's perspective, such as what modules the project is divided into, roughly what files each module has, what are the file naming rules, etc., but there is no need to further understand the internals of the modules (or directories). organization and implementation. Especially for complex microservice projects, doing this can quickly help you locate the key points of learning.

In most cases, everyone should download the project code locally to study. But if you just want to quickly understand the project and don't intend to study in depth, there is actually a more efficient way.

For example, press on the home page of the GitHub repository. By pressing the period key, you can quickly enter the web version of the code editor, which is almost the same experience as browsing local projects:

For developers with certain experience, they will usually look for key files first, such as package.json (Node.js) for front-end projects, pom.xml (Maven) or build.gradle (Gradle) for Java projects, and requirements for Python projects. txt or setup.py, etc. These files usually contain project dependencies and configuration information. If the project is relatively standardized, you can generally quickly understand the project structure through dependencies and configuration information.

For example, if you see the aop dependency, you will know that the project uses aspects; if you see the freemarker dependency, you will know that there will be an FTL template file in the project resource directory; if you see Redisson, you will know that there will be a configuration class that initializes the Redisson client. These are The importance of accumulating experience.

3. Run the project

If you want to learn the project formally, don't rush to read the source code first, but run the project successfully locally first, so that you can learn while debugging later.

The steps to run the project are simple. Use the git clone command to copy the project to your computer, then follow the instructions in the README file or other documents to install the necessary dependencies of the project, modify the local running configuration, and finally run the project.

Although the steps are very simple, the reality is that people often report various error messages after pulling the project locally. Therefore, you should pay special attention to the following points when running the project:

Make sure that your system environment and project requirements are consistent. For example, pay attention to the front-end Node.js and back-end JDK version requirements.

Make sure that the versions of project dependencies are consistent with project requirements, such as the versions of MySQL and Redis that the backend depends on. For this mainstream technology, under normal circumstances, as long as you don't use a version that is too new, it will basically not affect the operation of the project.

Modify the local running configuration to your own, such as database account, password, etc., and be extra careful not to read the wrong configuration file, otherwise you may still be wondering "Why does the configuration not take effect" after changing it for a long time?

It is normal to encounter errors, because not all open source projects are "easy to use and easy to get started." When encountering errors, we only need to locate the key error information, and then follow the clues to find the corresponding files to modify. I really can’t figure it out. Aren’t there search engines and AI?

Here is a common technique for running projects quickly. Sometimes the project uses a lot of dependencies (for example, MinIO, RocketMQ, etc. are used in MallChat), but these dependencies are not installed locally, causing the project to fail to start. As shown below, because I did not install RocketMQ, an error occurred when connecting to RocketMQ at startup:

To start a project, the traditional method is to install all the dependencies yourself. However, if the project only uses a certain dependency in an inconspicuous place, it is not cost-effective to spend time installing it. At this time, we can use a simpler method to directly disable the loading of beans that use these dependencies.

For example, adding exclude to the startup class can quickly disable the automatic loading of certain dependencies. The sample code is as follows:

@SpringBootApplication(exclude = {RocketMQAutoConfiguration.class})

However, after disabling RocketMQ Bean initialization, if any code uses this Bean, an error will be reported due to missing dependent beans. In this case, you can use the @Lazy annotation to lazily load the Bean. It will only be loaded when it is used, and no error will be reported when starting the project. The sample code is as follows:

public class MQProducer {

@Autowired

@Lazy

private RocketMQTemplate rocketMQTemplate;

}

4. Understand business processes and database table design

Before reading and studying the code, it is best to have an overall understanding of the project's business process and library table design, which will help clarify the order and learning direction when reading the source code later.

Core business processes can be understood by reading documentation or experiencing the system yourself. For example, for a chat room system, the core business process is: user login => user online => add friend => create room => join room => send message => message review => other users receive message => reply to message.

There are also skills to understanding the database table design of the project. Rather than looking at the SQL file directly, I usually initialize the database locally first, and then view it through visual charts.

As shown in the figure, the relationship between the tables is clear at a glance! For example, rooms are divided into individual chats and group chats. There are multiple conversations and messages in a room:

5. Read the code

When you first start reading the code, don't rush to read the code line by line in order. Instead, you must first fully understand the role of each directory and the file organization form within the directory. However, you do not need to understand the specific implementation in depth for the time being.

For example, for the MallChat project, you must first be able to clarify the information in red letters:

There is a little trick when viewing the file organization within a directory. You can right-click a package directly in IDEA to view the UML structure diagram:

Through the structure diagram, we can quickly understand the relationship between classes. For example, in the figure below, the factory creation strategy and two specific strategies inherit the abstract strategy class:

After that, you can find the core functional modules of the project you are interested in and learn them. Here are a few learning tips:

1) If you want to quickly learn the implementation of a certain function, it is recommended to first understand the business process through documentation and other methods, and then learn the source code. When studying source code, it is recommended to start the project in Debug mode, send requests through the interface document (or front-end), and completely analyze the processing flow of a request.

You can quickly view the interfaces in the project and locate the source code through IDEA's Endpoints function:

2) If you want to quickly understand the core structure of a single file (such as methods and properties), you can use the Structure function of IDEA, as shown in the figure:

3) You can use the Call Hierarchy function to view the hierarchical structure and relationship of methods, classes or variables called in the program. For example, in the picture below, I looked at the caller view of the doMark method. I can see which methods call it, which makes it easy to quickly understand the interaction between codes without having to go through it layer by layer.

4) You can quickly view all usage locations of a method or class in the project through the Find Usages function:

5) Of course, for complex functions, you may not be able to understand them by looking at the code alone. In this case, you need to use documentation and code comments. What? No documentation? ! Don’t write comments? ! Then just find the original author through the Git version control tool and ask.

6. Understand project development processes and specifications

After you are familiar with the project, you can try to participate in development. You can first read the project's contribution guide or development documentation to understand the project's development process, development specifications, etc., and be consistent with other developers of the project. If you have any doubts, you can take a look at how other people's code does it, and just imitate it; if you are really unsure, it's best to ask in advance instead of submitting a bunch of code that doesn't meet the specifications, only to have others call it back, which is a waste of time. Time for each other.

7. Participate in projects

Finally, the best way to learn about open source projects is to personally participate in project development. This is what I always recommend everyone to do. It can not only improve your abilities, but also add points to your resume.

In fact, it is not that difficult to participate in open source projects. You can first check the bugs reported by others in the Issues section of the project, and help fix them, so that you can become familiar with the entire process of participating in open source projects. You can also communicate with the author later and try to add new features, optimize, etc.

If you want your contributed code to be accepted by the author faster, you must communicate well! Because I have many open source projects myself, and some friends have contributed code to me, but it is impossible to accept all codes. Because everyone has different ideas about the project, without communicating with the author, the functions you make may not be helpful to the project, exceed the project plan, and will instead make the project more complicated. The same goes for team development. Everyone should review the requirements together to ensure that the requirements are valuable and match the project positioning, rather than just adding functions if anyone wants to.

OK, the above is what I will share in this issue. It is not easy to be original. If it is helpful, please like and support!