How to read others' code

We often encounter something that takes over products or half done by others. Reading programs is like reading books. There are no annotations, no documents, unclear structures, chaotic logic, non-standard definitions, and non-standard writing. Do you have any solutions? I have finally summarized some experiences while reading and researching.
1. No matter the software first understands the input/output interfaces, for example, those I/O are led indicators, those are keyboard scanning I/O, those are ad ports, and those are communication ports. It is best to write it on the notebook and check it at any time. Otherwise, if you see half of the program, you have to go to check the schematic.
2. Starting from the main function, any function is implemented cyclically in the main function. Reading from the first function called by main usually involves many initialization functions. After reading the initialization, read the execution part. Check the implementation method of this module. The module calls each other and you can ignore it temporarily.
3. Use a notebook to write down the modules with clear ideas. The content includes the functions and definitions of the functions contained in the module. In this way, we can clarify the ideas of all modules one by one.
4. Use the search method to view the mutual call part. The relationship is basically the same.
5. In particular, because the program may be very long, you must write something in the book. Otherwise, you are a fairy and cannot remember the meaning of the module. When you cannot remember it, the efficiency of viewing the source code will be very low. (Transferred from Advanced Technology Development Network)

 

 

(1)Read others' program code (1)---Read the program code and use it all.

1.First understand the system architecture and behavior patterns, and then read carefully

2.Familiar with communication languages and Common Terms

3.Understanding the mentality and habits of programmers

(2)Read others' program code (2)-You can easily understand the entire architecture

1.The purpose of reading program code is to understand the whole picture, not the details.

2.After clarifying the architecture from top to bottom, you can easily understand the composition relationship.

3.A sense of attention is required to understand the architecture.

4.First thing to explore the architecture: Find out how the system initializes

5.Step 1-Find the program entry()

(3)Read others' program code (5)-Find the program entry, and then tap it up and down.

1.The tree structure is recorded at the same time.

2.I cannot look at the function. First, try to look at it.

3.Determine the number of layers to expand based on the granularity you need to know.

Read others' program code (1)---Read the program code and use it all.

The program code is written by others. Only the original author can really understand the purpose and meaning of the program code. Many programmers have an unconscious fear of being forced to touch the program code written by others. However, instead of resisting others' program code, it is better to thoroughly understand relevant languages and practices as the cornerstone of Self-strength cultivation.

For most programmers, writing program code may be a pleasant thing, but I believe that more people are afraid to read the program code written by others. Many prefer to re-write the program code on their own, and do not want to receive the code from others, so as to correct errors, maintain them, or even enhance functions.

Where is the key? It is actually very simple if it is a single phrase. The program code is written by others. Only the original author can really understand the purpose and meaning of the program code. Many programmers have an unconscious fear of being forced to touch the program code written by others. This is from the original fear of strangers in the human heart.

 

Read the program code written by others, so that you can get full

However, for many practical reasons, programmers are often forced to receive others' program code. For example, if a colleague leaves the company, he must take over the work left by him. Maybe you are a newbie in the Department, and your colleague's experience is sufficient. After the upgrade, the flow of wind and water will flow, A generation of cainiao for cainiao. Even the project your company undertakes must take over or integrate the system left by the customer's previous vendor. You only have the original code of the system (good luck, there are also a number of files ).

Such stories are often staged by the programmer's side or body. Many programmers take over others' program code as a miserable thing. Everyone doesn't want to take over the program code written by others, because they don't want to take the time to explore. They 'd rather spend productivity on generating new program code than learning about it.

Unfortunately, the above situation is hard for programmers to avoid. We must always touch the program code written by others, or even understand it and modify it. This demand is so prevalent today in today's open source code, as mentioned in the previous article "Program Design 2.0, you can learn new technologies through the open source code, learn the architecture design of experts, and greatly improve the learning efficiency and effect. You can even extract the code from the open source code project, extract the code you need, and stand on the shoulders of giants to directly obtain the required productivity from each other. From this point of view, reading the program code written by others is not just "Forced to receive" from the negative point of view, but a very positive value "to take advantage ."

First understand the system architecture and behavior patterns, and then read carefully

If writing program code is one of the important skills of programmers, then reading and modifying other people's program code will be another important skill. If you are not familiar with this job, you will not be able to solve the problem of taking over others' program code in front of you, but more importantly, when you look at the current ready-made program code, but you do not know how to extract your needs from it, so you can only go back to Baoshan empty-handed.

The program code that comes into contact with others can be divided into three levels: one, understanding, two, modification, expansion, three, extraction, refining. Understanding other people's program code is the most basic work. If you cannot understand the program code you want to process, you can modify or expand the program code. It is even more difficult to extract what you need from it, reuse the program code written by others. Although it is "reading", the program code is not like an article or novel. Through this method, you can get a certain degree of understanding. When reading articles or novels, you can read them in sequence. You just need to open the first page and read them one line at a time. However, when many programmers try to read other people's program code, they often have difficulty reading the code. It may not be difficult to find the first page of the system (that is, the starting point of the execution of program code), but the complicated system is sometimes very large and sometimes complicated.

Starting from the starting point of the program code, it takes time to read all the program code in sequence. Second, it is difficult to build a system in your mind to understand the system in this way, then we can understand the real behavior of the system. Therefore, the focus of reading program code is not to read every line of program code, but to efficiently explore and read to understand the system architecture and behavior patterns. So that when you need to know the details of any part of the implementation, you can quickly reflect the specific program code position in the brain, until that moment, is the time to read carefully.

Familiar with communication languages and Common Terms

In either case, some basic preparations are required when reading others' program code.

First, you 'd better understand the programming languages written in program code. If you want to read a novel written in French, you cannot even understand French. Some situations are special. Although we do not understand the language used for writing the program code, because of the advanced nature of modern languages, and most popular programming languages are of similar lineage, even if we are not so familiar with it, sometimes, you can do it with stress.

In addition to understanding the language used, you must first confirm the Naming Convention (naming convention) used by the program code ). It is very important to understand naming conventions. Different programmers or development teams may be very different. This naming convention typically covers the name of the variable, the name of the function, the name of the category (if it is object oriented), the original code file, and even the name of the Project Build directory. If you use methods such as design patterns, these names have more specific expressions.

Naming Conventions are like a group of communication lines that programmers build on the programming language. Programmers will express some high-level concepts through common constraints and naming conventions. For example, the famous Hungary naming method combines variable names with attributes and types to describe them. For programmers, This method provides more information to understand the role and nature of the variable.

For program code reading, it is important to be familiar with this practice because when you understand the practice adopted by the entire system, you can try to understand it in the vocabulary they use together. If you are not familiar with the practice, these additional information cannot be used for you. Program codes written in design patterns are also full of pattern names, such as factories, facades, and proxies. The categories referred to by these names also express their own roles through the names. Readers who understand this naming convention can quickly capture the meaning of these categories without in-depth exploration.

When you get a set of program code that must be read, it is best to get the description file of naming conventions first. However, not every set of program code has such a description file. Another way is to browse the program code by yourself. experienced programmers can easily find out the naming conventions used by the system.

In this case, experience is very important when naming a few classes. If you know more conventions, you can easily identify the conventions used by others. If you are lucky, the program code is never seen before. You also need to take some time to sum up and find out the naming rules for the program code based on your own strength.

Understanding the mentality and habits of programmers

Most program codes follow consistent naming conventions. However, when luck is worse, a system may be filled with multiple naming conventions. This may be because the development team is composed of multiple groups of people, each group has a different culture, and the project development management is not properly controlled. In the worst case, there is no obvious convention in the program code. At this time, reading is more difficult.

To read the program code, you must first try to understand the "heart" of the author of the program code ". If you want to do this, you will have a better understanding of the language used by the other party and the commonly used vocabulary. In the next round, we will continue to discuss topics related to reading program code.

Read others' program code (2)-You can easily understand the entire architecture

In this article, we focus on: to understand a system, it is best to take the top-down approach. First, try to capture the concept of system adequacy, and do not drill into details too early, because it usually doesn't help much for you to understand the whole picture. Reading program code does not need to start from the first line. Our goal is not to read every piece of program code.

For many reasons, programmers need to read the program code written by others. For programmers in the 2.0 era of programming, the most positive value is that people who can understand other programs can extract the programs they need from them to improve productivity.

The purpose of reading program code is to understand the whole picture, not the details.

The fundamental foundation for understanding others' program code is to understand the program language and naming conventions used by the other party. With this foundation, it is possible to have the basic reading ability. As I mentioned earlier, I can't even understand French novels. To read program code and literature, you must understand the language used for writing and the vocabulary used by the author.

However, we are reading literary works in sequence, that is, reading them one by one from the first page, following the steps that the author has laid out for you, gradually enter the world he prepared for you. Reading program code is quite different. We seldom start reading from the first line, because unless it is a very simple single-thread program, it is rarely done. If this is done, it is difficult to understand the overall picture of the entire system. Yes, we have mentioned a key point here. The purpose of reading program code is to understand the overall picture of the system, rather than simply reading every piece of program code in a blanket.

Taking the systems written by the object-oriented programming language as an example, the entire system is split and analyzed into independent categories. Read the program code of a specific category to understand the individual behaviors of each category. However, it is easy for blind people to figure out how different types of objects interact and how they work together. This is because of various program codes that only describe the behavior of individual objects, and reading fragments can only create a one-sided understanding.

After clarifying the architecture from top to bottom, you can easily understand the composition relationship.

If you want to skip the predicament and do not want to waste a lot of time reading program code, but you can only capture the knowledge of system fragments, you must switch to another view of the system. Starting from individual class behaviors, it is a bottom-up (bottom-up) method. When reading program code, you should first adopt the top-down (top-down) method. For reading program code, from top to bottom means that you must first understand the entire system architecture.

The system architecture is the backbone and pillar of the entire system. It shows the most prominent features of the system. Knowing whether the system architecture belongs to that type is usually helpful for understanding the static and dynamic relationships between individual components of the system. Some systems depend on the technology or framework used to determine the upper-layer architecture. For example, for an application system using Java Servlet/JSP technology, the outermost layer architecture is based on J2EE (or at least the Web Container in J2EE.

The use of Java Servlet/JSP technology determines the relationship between some components. For example, a Web container loads all Servlets, listeners, and Filters Based on the content in Web. xml. When an event (such as initialization) occurs in the context, it notifies the listener category. Whenever it receives a request from the client, it will follow all the configured filter chains to give each filter the opportunity to check and process this request, finally, the request is directed to the Servlet used to process the request.

When we understand that a system uses such an architecture, we can easily understand the relationship between components. Even if we do not know how many servlets there are, we will know that every time we receive a request, there will always be a corresponding server to process it. To focus on how a request is processed, I should find the server corresponding to the request.

A sense of attention is required to understand the architecture.

Similarly, in Web applications written in Java, MVC frameworks such as Struts and data access frameworks such as Hibernate may be applied. Both of them can be considered as the secondary architecture under the primary architecture. However, various application systems may even establish their own secondary architecture under struts and sleep.

That is to say, when talking about the concept of "architecture", we must have a sense of attention. Regardless of the layer-level architecture, roles and relationships between roles are defined. For readers, it is better to know how many roles exist in a specific architecture and how they interact with each other than simply exploring the most subtle single role behavior, it helps us understand how the entire system works.

This is a very important key. Before you try to get to the details, you should first try to find the involved roles and their relationships. For example, an event-driven architecture has three important roles. One is the dispatcher for event processing (event scheduling), the other is the event generator, and the other is the event processor (event processing program ).

The event generator generates an event and sends it to the event dispatcher. The event dispatcher identifies the event processor corresponding to each event, transfers the event to the event, and instructs the event processor to process it. Windows applications on the graphic user interface of images adopt an event-driven architecture.

When you know that such applications are all event-driven architectures, you can learn that there are three main roles in these architectures. Although it may not be clear how many types of events will be handled in the system, you have established a general understanding of the entire system.

Although you still don't know all the details, such information such as the specific event type is not important at the moment-don't forget, we adopt a top-down approach. First, we need to understand the structure of the main building. As for how to deal with the color of the wallpaper, it will be done at the end.