A shortcut to source code reading and learning

Source code reading is naturally one of the shortcuts for computer learning, and its importance will not be repeated here.

Due to the needs of the project, I was reading the source code library of OpenSSH & OpenSSL recently. At first, the progress was very slow and fast, but after mastering some skills, it became faster. Here, I will post the so-called "skills" I have summarized. I will throw a brick first, and everyone will smash it with jade! !

Reading a good source code is like digging for treasure.

1. If a worker wants to do a good job, he must first sharpen his tool - a shovel?

Source code reading tool recommendation:
MS vs or eclipse+plugins is recommended for desktop software or web development, that is, the corresponding IDE;
source insight (wine/samba) is recommended for linux projects.
It can be determined according to personal habits.

2. Choose good items - what counts as a treasure?
A good project: a project with good quality; I
personally think that the code with good quality should have at least:
1) Well-designed software architecture and module interface, high cohesion and low coupling;
2) Code writing specifications and clear processes;
3) Comments, Documents and related network materials are complete;
for the pros and cons of a specific project, you can refer to the evaluation of mainstream forums.
In addition, good projects must also be suitable for their own projects.
Make choices based on your own level, interests, professional direction, etc., more often because of some constraints, such as work or study needs.
The purpose of this is to allow us to read with a purpose. First, because of actual needs, it is easy to correct our attitude and not give up easily; second, to read the source code in the context, it is easier to understand and achieve more with less effort.
for example:
If you want to learn about the architecture design and design patterns of asp.net, and you want to implement an e-commerce website in your graduation design, you can read petshop;
if you want to learn the specific implementation of the http protocol, you can read some web server source code, micro_httpd, shttpd, boa, apache...
If you learn Godson or MIPs CPU architecture and are familiar with mips assembly, it is recommended to read the source code of mips simulator, pcspim, vmips, msim
...

3. Pay attention to Doc - about treasure Readme, readme in
many open source projects Q&A, buglist, manual, etc. will provide a lot of information. Understanding these documents will obviously help a lot to grasp the entire project, but this part is also the most easily ignored by us.
We can also expand these materials through wiki & google.

4. Setting up the environment - preparation before departure
A runnable environment will be very helpful for code reading:
1) It is convenient for us to understand the project from a functional perspective;
2) Through debugging, tracking and other means, understand the process of source code running .

5. Analyze the project structure - draw a map

After the above steps have been used to roughly grasp the project structure, we can analyze the project structure by combining the source code. The common methods are as follows:
1) With the help of the project directory;
2) Analysis of project management tools Makefile, analyze the dependencies of modules;
3) Browse the source code, it is not necessary to specify each function here, you can read the comments when you encounter key functions;
4) Read the documentation, use google, etc.
At this point, we should have a good understanding of the structure of the project. It doesn't matter if some problems are not fully thought through. We will leave it to the following, and we will settle accounts in the autumn.
Before proceeding to the next step, we should draw the structure of the project, which is similar to the system module diagram in the outline design. The unclear places are left out, and tools such as visio, Rose, and smartDraw can be used.
Note: This step is necessary, because this is the map for our treasure hunt, it can prevent us from getting lost in the vast ocean of source code.

6. Go deep into the source code - search for me

According to the map in the previous step, we began to go deep into each module and annihilate one by one. The order is roughly as follows:
1) The principle of bottom-up
This our top-down in the software design stage, and gradually seek Jing's idea is the opposite; for the analysis inside the module, we need to start from the bottom, combine the map, gradually cover this module, and nibble it. This is the main reason why we draw maps.

2) Public module priority
Public modules are basically some code with strong versatility and high reusability, such as some tool code;
the module interface of these codes is usually clear, and these codes can basically be regarded as gold, here A lot of the code, or even the entire module, we can directly use it in other projects. We need to store these codes in our own code base, which is not enough, we also need to add the usage instructions and runnable example codes of these codes.

3) Virtual data, analog interface, so that each module can run independently.
The concept of simulation is more important, and it means to isolate the enemy. Surround the current module with virtual data, cut off the relationship with other modules, isolate the module, and annihilate it.
This step requires more skills, and the difficulty is usually related to the selected project, which is why we emphasized low coupling in the previous article. For these, we can refer to the Mock principle in unit testing. While writing a lot of fake data, we have a deeper understanding of interface interaction between modules, data flow, etc.
In this step, we can think from the point of view of the software designer. At this time, we should be able to write a detailed design document for this module.

7. Summary After reading
a source code project, we have to review the whole process and fill in the blanks left in the start map.
We can't be satisfied with extracting some codes and have some understanding of this project or even similar projects. These are just fish; more importantly, we must learn how to fish.
The reason why the early Communist Party was able to survive and even grow in such a difficult environment, I personally think, is mainly due to continuous thinking and continuous summarization! We always have to guess the designer's design intent:
why do it? Why not do that?
If I design it, how should I implement it? What to avoid and what to watch out for?
Is it really best to do this? Is there any other better way to do it?

Sorting out these ideas can be called source code reading experience.

In this way, we basically read a project three times:
1) Browse, get a schematic diagram of the module design;
2) Fine product, get the detailed design of the module, enrich the personal code base;
3) Review, get the project The essence of design;

finally, don't forget to share these materials in relevant mainstream communities, leave contact information, if there are any mistakes, someone will point it out to you, everyone is for me, and I am for everyone.