How to read others' code

To read the code, you must first perform intensive reading or extensive reading. For the purpose of learning, you must read a certain amount of classic code. Intensive reading means that every line can be read and the basic structure of the program can be outlined without looking at the code. There is a very vivid state here. when you read the code, it will be full of code, so it cannot be put down, or even code in your mind before going to bed. However, this article focuses not on how to read the code, but on how to master the existing code at work, which is equivalent to extensive reading.

To read the code, you must first perform intensive reading or extensive reading.

For the purpose of learning, you must read a certain amount of classic code. Intensive reading means that every line can be read and the basic structure of the program can be outlined without looking at the code. There is a very vivid state here. when you read the code, it will be full of code, so it cannot be put down, or even code in your mind before going to bed.

However, this article focuses not on how to read the code, but on how to master the existing code at work, which is equivalent to extensive reading.

Many existing systems are often very large, and hundreds of thousands of rows may only be common. Once such a project is added, how do I read the code? Here is my personal experience.

Before reading this kind of code, you must make a rough idea of the specifications, instead of reading the code. for example, for an application, you must first make a general idea about how to use it. If it involves domain knowledge, such as process and accounting, it is better to know it in advance. This type of things is unlikely to be pulled back from the code.

I personally think this is a huge obstacle for reading programs. if you do not know the encoding rules, but read the encoding program, it will always be in the fog. at this time, it is not because the program is difficult, it is because you do not know the professional knowledge in the program. In this step, it is best to extract several typical application scenarios, which will be useful later.

Once you get started with the code, you must first understand the basic static structure of the code. Such as package composition and class composition. This involves a level problem. All of a sudden, the hierarchy is too deep, so it is easy to stare at the details.

For projects with design documents, you can use packages to define this level. It's terrible if you don't design any documents. you can only divide them by yourself. it's better not to include more than 10 documents. if you do not design more documents, you can't remember them. In the static structure step, it is easy to understand the core responsibilities of each part, and it is best to remember.

Next, we will use the above typical scenarios. In typical scenarios, we need to examine how the above static structure works. In typical scenarios, the interfaces used are usually key interfaces. they need to be clear about their definitions and functions. Make it clear that the data flow changes in typical scenarios.

This step is to figure out the code sequence. Similar to the Sequence diagram in UML. However, when data is involved, you generally need to understand the data specifications.

Next, pay attention to the process and thread structure. For example, when and when are all started, and what are the responsibilities in the above typical scenarios.

After the preceding four steps (specification, static structure, typical scenario, and process thread) are completed, the program is fully read for the first time.

The test criteria are very simple. in this case, we should be able to describe the Sequence diagram of typical application scenarios by paper and pen alone. When doing this, we need to suppress our thirst for knowledge, because we always want to use the call function in the debugger? Stack makes the implementation details of a function clear, but at least at the first level, you can skip this.

? After the first extensive read, it is necessary to enter the deep mining process. the target object should be the part that you will be responsible. These functions are often hidden under an interface. At this time, functional modules, such as the XML parsing module, can be omitted. The other part may be deemed to need to repeat the four steps mentioned above. But at this time, we need to pay attention to the details and call stack.

There are two basic skills that are always needed at the level of the read code. one is to master the embedded Log mechanism in a specific program. to view the Log, you may have to add the Log when necessary; one is the basic debugging method. Debugging is very difficult. The book software debugging has written more than 1000 pages.

However, it will still be a little lacking if you just set a breakpoint and wait for him to stop. You must be aware of the issue of conditional breakpoint, multi-thread debugging, and multi-process debugging.

There are too many program types, so it is estimated that there are many methods to read the program. The above is just my personal experience. please add it.

This article is available at http://www.nowamagic.net/librarys/veda/detail/2417.