Talk about how to read the source code

   This article takes open source code reading as an example to talk about how to read source code, especially for large-scale systems, including how to quickly start and how to process it efficiently. Can be expanded into code reading methods; software debugging methods and technical skills; software optimization methods and technical skills. Related content will be added later.

   First, reach three points of understanding:

   1 The amount of information that the human brain can process is limited, and the information contained in a program can easily exceed the processing limit of the human brain. Dijkstra's famous saying about 10 to the 9th power.

   2 People need to perceive things from different perspectives of abstraction, hierarchy, and structure. This is the characteristic of the brain.

   3 People have limited time and energy. Modern large-scale systems can easily reach the million-line level, so it is necessary to master the methods and methods instead of using brute force.

 

One, learning of open source software

   This part uses open source software learning as an example to introduce ways and means to efficiently handle large-scale systems.

   <1> Understand the background of software development

   Understand the background to focus on the software. Only then will there be an overall goal.

   <2> Follow the official website of the software

   Many open source software have official websites that publish official authoritative information, interface descriptions, precautions, historical revisions, etc. about the open source software. Through the official website, you can have a more comprehensive understanding of the background, design architecture, current functions and subsequent improvement plans of the software. This is very important for us to "understand" the code.

   <3> The latest version and other information

   Introduce the current version of the software and all the old versions that have been retained. The reason for introducing the old version is because the initial version is generally the simplest, so starting from the early version that implements the basic functions is also a means of quick learning: because the code of these versions seems to be simpler. Following the selected early version, and then based on the historical data of the version evolution, we can not only understand some extended functions or advanced functions more easily, but also easier to understand the code close to the current version. If you start with the latest version from the beginning, the features are the most complete. In addition, it may also be the most stable, the least bugs, and the cleanest code. However, when faced with a large number of extended functions or advanced functions, especially Logically, when the code for a specific function is not designed but inserted into the implementation as the function evolves, it is easy to feel like a cloud, and it may also affect the enthusiasm and interest of continuing to learn because it is too complicated. Therefore, it is necessary to understand the evolution process of each version, and this is the purpose.

   <4> Purpose of the software

   This part simply and intuitively describes what the software is used for, how to use it, and some demonstrations of the effect.

   <5> Basic knowledge

   Introduce the basic knowledge of related fields involved in this software, and prepare for the following research and study.

   <6> Software architecture

   Introduce the overall framework of the software, which may include official and personal understanding, but it will indicate where it comes from.

   <7> Core data structure

   Introduce the key data structures used. Since they are the core, they will not be involved too much.

   <8> Process

   Introduce how the software works according to the function call process.

   <9> Programming skills and concepts worth learning

   Introduce some programming skills and design concepts used in the software, deepen your understanding and improve your own skills.

 

   Second, extra words about the architecture

   The order of the above points is basically arranged in accordance with the normal process of human understanding, and it is assumed that the reader basically has no relevant basic knowledge. In general, the whole process can be divided into three parts: background, software, and expansion. The first is background-related, including background knowledge, software purpose and basic knowledge. First introduce the background knowledge, so that readers understand the development background of this software; secondly, the purpose of the software, clarify what the software is used for, and the basic use process, so that readers can form a macro concept or framework in their minds. So that the subsequent reading is more purposeful; in addition, basic knowledge, introduce the basic knowledge needed to understand the subject and software, including basic concepts, the meaning of some abbreviations, and so on. For readers who have a good understanding of this knowledge, the first few parts can be skipped, or just a glance. The second part includes architecture, data structure and process. From the beginning of the software architecture, the core of the software is involved. The first is the software architecture, so that readers understand the basic knowledge introduced and the goals to be achieved, how the software is structured to achieve this purpose (bridge function, complete the conversion of solution space, from the real world to the software world). Then comes the core data structure. It can be said that the data structure is the core of understanding and mastering the open source software, so the core data structure is the core of the core. Each item in the data structure is actually related to each element or part of the element introduced in the basic knowledge. Although the data structure is a relatively loose structure, relatively speaking, each element in a data structure Elements still have a certain degree of relevance, so mastering these data structures is not only a deep understanding of the basic concepts in the basic knowledge, but also a certain understanding of the relevance between these basic concepts. The next step is the process. We talk about the program as an algorithm plus a data structure. In a sense, the process has the characteristics of an algorithm. Combined with the architecture, we will not only see how the software connects these data structures, but more importantly, the ultimate goal is reached: how the software works. With the above two parts, it can be said that the purpose is basically achieved. But an open source software not only exists, but is also used by most distributions including Ubuntu and Fedora The software that is accepted as the default is selected as the software of related functions when the system is installed, and it can continue to develop. There are new versions being launched continuously, which must have its own characteristics, and the design skills and design concepts are one of the characteristics. So after understanding the software, it is necessary to take these two parts out as an extension to discuss separately. This is the content of the third part of the extension. For the content of this part, it is still necessary to savor it carefully. This is also a way to quickly improve your design capabilities.

 

   Three, take Linphone as an example to talk about how to read the source code

   Personal despise, welcome to make a brick.

   This section uses Linphone as an example to illustrate how to read the source code of excellent open source software. What is recorded here is only the personal feelings during reading the Linphone source code, not suitable for everyone. Everyone has their own way of receiving new things, and the habits here also contain faster meaning. So all the following content is only for your reference in the process of reading the source code, if it can help you, then the goal will be achieved.

   1 Recognize software functions.

   Before learning a software, I think it is a basic step to understand its function. If you don't understand the software functions, what research and learning are you talking about? Of course, this is only for software learning, not including other industries. Knowing the function of the software mentioned here means that you should know what the software does.

   2 Run the software and feel the software.

   3 Go to the official website to view software related information.

   4 Find or draw a basically correct software architecture diagram.

   If the official website already has an architecture diagram of the software, then you are lucky. You can get started quickly by understanding the overall architecture of the software.

   5 Divide the software into blocks according to modules or functions.

   Even if information technology is so advanced now, people's process of understanding things has changed from simple to complex, and this basic logic has never changed. If you start to study the entire function of the software at once, I don't think even a genius can do it. So we need to divide the software into small pieces and learn piece by piece. This is called breaking up into parts.

   6 In the process of the previous step, add software debugging if possible.

   The easiest way is to add some printing information to the code, and then run the software and look at the printing to understand the software flow. Through this step, you will have a more specific experience of the entire software process.

   7 Integrated serial connection.

   When you have an understanding of the important basic modules, you can feel them together. At this time, you should have a clear understanding and understanding of the entire software process. This is called turning zero into a whole.

   8 Take specific tasks as the starting point for in-depth understanding.

   Once you have a closer understanding of the entire software process, you can consider modifying or adding some functions to improve the software and further deepen your understanding of the software.

   9 Apply what you have learned.

   Learning a software is not only to understand the function of the software, to learn the flow of the software, but also to apply what you have learned, and to apply the excellent coding ideas and methods to your own development in order to improve.

   10 Be fully psychologically prepared and keep moving forward.

   To learn an open source software, you have to be down-to-earth in the end, step by step, take your time, and don't be impatient. Generally speaking, unless it is to implement an algorithm structure problem, a software package with practical functions cannot be done by a source file and a header file as we did in the school. There are dozens of hundreds This file is normal, but we can't be intimidated by so many files, we should treat it as a paper tiger, don't be afraid of it. This is not to say that we need to look at each file one by one function, but to understand the overall structure based on module by module. On the other hand, the writing styles of many open source software are more conventional and commonly called, and there is a certain similarity. If you have read more open source software codes, you will have a deeper feeling about this. So for people with a certain foundation, generally through naming, layout and other information, they will have a preliminary psychological perception of the function. For novices, this may be a bit difficult, but it does not matter, this is the process you must go through to learn open source software, and it is also a process of digestion and absorption. The method can make you avoid detours and have a more correct or straight direction, but the process of mastering takes time to accumulate.

   11 Modular verification.

   If possible, you can run Test separately from the modules that can be run. Even if it is not a separate module, if this part of the package is relatively regular, independent, small in coupling, and complex in logic, you can compile it separately and add Debug information to see the result. In this way, you can see the function of the interface relatively quickly, and it is also convenient to follow up to see the specific implementation. For example, when the author is working on a media gateway product project, the firewall module is involved, and there is an interface for judging the input IP address range. The internal implementation is more complicated and there are iterative operations. So I took it out separately for compilation and running, and found that the specific functions are correct. The entered IP address range outputs all legal IP addresses in the range. So for this step, we can run a test project at any time while looking at the source code, which is used to add complex and computational logic interfaces to run tests separately. This seems to take a lot of time, but in fact it saves a lot of time. Looking directly at the code seems to be the fastest way, but there are problems such as unintelligence, confusion, confidence, and repetition for a while. In fact, A lot of time was wasted.

   12 Test-driven reading.

   Each module should provide a test Demo, which is also a major drawback of open source software, that is, there is no test program. This is related to the generation of open source software, because open source software is generally completed by one person or several people, and the focus is on implementing functions. Of course, external factors such as fewer participating developers, intermittent, and less time are some of the reasons. In addition, open source and free connection and no follow-up support are the main reasons. For commercial software, it is generally developed by multiple people, and the module division will be relatively clear. When the module is completed, a Demo is also provided, including the module's own test. In addition, as charged commercial software, stability and maintainability need to be guaranteed, follow-up support is required, and even some interfaces may be provided to partners to speed up development progress and reduce development difficulties. These factors also contribute to the modularization of commercial software. The test is relatively complete. For continuous revision submission, regression testing is also needed to effectively reduce the testing pressure and speed up the verification process. In general, many theoretical methods of software engineering are not fully and clearly reflected in open source software. This point requires additional attention when reading and testing open source software.

Guess you like

Origin blog.csdn.net/wwwyue1985/article/details/112726423
Recommended