Reading source code like this is not awesome

In the course of their work, programmers will encounter many scenarios where they need to read source code, such as technical pre-research, selecting technical frameworks, taking over previous projects, reviewing other people's code, maintaining old products, etc. It can be said that reading source code is a programmer's basic skill, and whether this basic skill is solid will greatly affect a programmer's technical growth rate.

When I wrote "Core Programming of Qt on Android" and "Core Programming of Qt Quick" in 2014, I understood a lot of the content by analyzing the Qt source code. When I studied CEF and PPAPI recently, I also mainly relied on studying the source code to understand their usage. Recently, I had to modify a subsystem of an existing project at work, and I also had to bite the bullet and read the code first.

In short, in the past ten years of development work, I have read too much source code and learned a lot from the source code. If I didn’t read the source code, I really don’t know if I could grow.

Writing code starts with imitation, and improvement also starts with observing other people's excellent designs and codes. Therefore, reading source code is very important. Next, let's talk about reading source code from the following aspects.

• Purpose
• tool
• Knowledge Preparation
• Operation and development environment
• notes
• Practical tips
• Psychological adjustment (walking in various links)

Purpose

When we read the source code in front of us, we have the following purposes:

• Pure learning
• Adding new features
• Refactoring old code
• Fixing other people's bugs

Different purposes will lead to different moods, which will affect the progress of work. For example, fixing other people's bugs is similar to a non-gay male ape pinching his nose to wipe another man's butt. It is disgusting and easy to be rejected. Therefore, reading source code for this purpose is often reluctant, hesitant, and inefficient. However, in actual work, you will encounter situations like helping others fix bugs, and there is no escape. Therefore, psychological adjustment is very important.

Reading source code for learning is the most enjoyable and relaxing thing. But I would like to remind you that only when you set verifiable goals can you gain something. Otherwise, it will be like walking on the street and seeing a beautiful woman passing by. You will be amazed for a moment, but after that, you will lose the relationship and gain nothing.

Other purposes, such as refactoring old code and adding new features, are slightly better than helping others clean their gutters (Shaanxi dialect, buttocks) because they are creative. Creative activities can bring people strong pleasure. So although these two purposes also have many unpleasant parts, when I think that I can rejuvenate an old tree, the unpleasantness will gradually weaken.

tool

To do a good job, you must first sharpen your tools. This is an eternal truth. To complete the task of reading source code well, we probably need the following tools:

• SourceInsight, the best source code browsing tool, can maintain symbol libraries, dynamically display context, and draw call relationship diagrams. It is the best, no one
• Paper notebook, record your thoughts and doubts at any time, draw various diagrams (class diagrams, sequence diagrams, block diagrams) at any time, faster than UML tools and Visio
• Gel pen
• Notepad, Notepad++, Youdao Cloud Notes, Weizhi Notes, etc., to record the key points, experiences, and analysis process of reading source code
• Visio, used to draw simple block diagrams, describe the module division and hierarchical structure of source code, etc.
• StartUML, used to draw class diagrams, sequence diagrams, etc., to facilitate communication
• CamScanner is an app that can scan text or block diagrams written on paper notebooks and share them with others. If you are too lazy to draw icons with software, then hand-drawing and scanning them into electronic files is the best choice for you.

Knowledge Preparation

Foreplay is very important. If you are well prepared, the subsequent pleasure will come naturally. Otherwise, you will be frustrated frequently and feel that the road ahead is long and difficult.

• Business foundation. Every source code with practical significance is inseparable from the business. You must first have a concept of the business.
• Technical foundation, what language, framework, and third-party modules are used in this source code, all of which need to be understood first
• Documents, try to find business, requirements, summary, detailed and other documents, which will be very helpful. However, we often face the situation that there is only source code, only source code, only source code, and no document at all, so we have to firmly believe that source code is the best document. This psychological threshold is actually easy to pass. Just imagine that the source code is just a portrait of the fairy sister. No matter how many portraits you look at, it is not as powerful as a face-to-face look - either destroying your worldview or haunting you.
• Find out which programmer has maintained this code, so that you can ask for help when you don't understand it later. Sometimes people click on it and you can't figure it out for a day.

Operation and development environment

• The purpose of configuring the development environment is to debug. For some programmers, debugging is the best way to understand the internal mechanism of the software. Press F5, F10, F11, F9, and everything is done.
• Configure the operating environment to prepare for using and experiencing the software. From the user's perspective, take a look at the software from the outside to understand its internal logic.

notes

When reading source code, taking notes is a must. I have this experience, because the code is not written by myself, it is difficult to quickly engrave an impression in my mind. I often forget what I have read here and there. I think I understand the data flow in the morning, but I forget it after lunch. Therefore, taking notes is particularly important.

• Find a recording method that suits you, whether it is a notebook or software. There is a disadvantage of using software (Notepad++, Youdao Notes, Weizhi Notes, etc.) to record - you have to switch screens, which will interrupt the code reading process in form. So I often write some fragments of sentences in a notebook with a pen when I am too nervous to interrupt, and then use software to sort out the text when I finish.
• Record as much as possible, but you don't have to record everything you see. Record at intervals, such as when you understand the logic of a submodule, the role of a class, or the calling relationship of certain functions. Otherwise, the act of recording itself will interrupt your thinking.
• At the end of each day, record your progress (the part you have figured out), record your questions, and record what you need to figure out the next day. This way, your work status will be stacked, and it will be easy to get out of the stack the next day, and you can quickly get into work status.
• Record the excellent designs you see, improve your aesthetics, learn from others and grow yourself

Hidden gem

I have accumulated some experience in my long career of reading codes, which can be regarded as random thoughts for reference:

• It is critical to clarify how a certain business is mapped to the code execution process.
• It is critical to clarify the business relationship and code call relationship between different modules
• Debugging is one of the fastest ways to understand the code calling process.
• Find the key code (classes representing actual objects, classes connecting different modules, classes representing key business nodes)
• Analyzing logs can help analyze code execution processes and business processes
• First use the existing executable software to experience the business and figure out how the code might respond when you click here and there.
• Reading should be centered around the purpose, and achieving the goal should be put first. For example, if you have a deadline to fix a bug, getting it done before the deadline is the first priority. Then, if you have time, continue reading the source code or improving the bug fix solution, striving to have no side effects and sequelae. If you have time, fix the broken windows left by others (you can also despise the previous maintainer by the way)
• Ask a million times. Remember what I said before, you should find out who has maintained the code you want to read. Don't be shy, ask, ask, ask.
• Look at the code according to the design document, interface document or test case
• Debug mentally, don't be afraid of difficulties, don't give up. Sometimes I look at the code for two days and don't know what I'm looking at. It's common to be confused and dizzy. Sometimes I really feel that I can't figure it out. However, this is either because you are not prepared for the basic knowledge or you have found the wrong entrance. You should know that any code has an invisible line strung together. Be patient and you will always find it. If this doesn't work, try that. Change the angle and method more often. If reading doesn't work, debug. If debugging doesn't work, run. If running doesn't work, study the log. If none of them work, damn it, while(!i.isDead())i.analyzeCode(), fight with Y to the death! In short, if you don't give up on yourself, no one can give up on you!
• Set small rewards for yourself. After you understand a certain logic or the code of a certain module, reward yourself with a break of 5 to 10 minutes, walk out of the office, or just browse the Internet and browse your favorite websites.
• Read only when you don't understand, think only when you don't understand, this is the beginning of progress and growth. Those who block you, ravage you, and kill you but can't kill you will eventually help you grow and make you stronger.