Recently looking at the source code of the Oauth2 Library of Twitter (simplegeo/python-oauth2 GitHub
), do not look in ah ... The whole library has a sense of self-system, it looks very close, so it is inconvenient to start from where to look. If you look at the code from the top down, you will definitely be stunned by various functions. From the beginning of main (), it will also be a lot of layers of calls Dizzy. Because before the HTTP request of Python library is not familiar (such as HTTPLIB2, requests), often need to look at some other library content, more dizzy ...
Now always feel that they understand the general process, but there is always a large part of the function can not understand, combined with the document to see there are always a lot of places do not understand. I just want to see something and then make some improvements to the library (because some APIs have different OAuth processes and other APIs, so I want to improve the OAuth process). But now the degree of understanding, completely not up to this request Ah ... (These two days found a new library to meet my requirements, but I still want to figure out how to read the code better ...) ）
Senior members of the program, what should I do just fine ...
Reply content:
Look at the document first, then the unit test. Code Reading (watercress)
(subtitle is the Open Source perspective, suitable for main needs)
Code reading (watercress)
It was slow to read the code before, and then the code was written to read these open-source projects at a significantly faster rate.
Reading code is slow to commonly used functions and common library unfamiliar, unfamiliar with Python's commonly used programming skills, reading code when the energy is too scattered, reading code is a sentence of reading, but also need to regularly surf the internet to check grammar, there is no way to focus on the overall structure of the Code, Even if every line of code is clear or not know the logic of the whole program, at the same time expend energy is relatively large, quickly tired, inefficient.
Familiar with the common library and programming skills to read the code when it is very versatile they have achieved similar, sweep a glance to understand, a lot of functions sweep one eye know what function, ideas will not be not understand grammar or programming skills interrupted, has been stuck in the logic of the program, so look at the code is much easier, and soon, Basically small project casually turn over to know its idea, big project words actually do not have to grasp, as long as the part with their own to see relevant familiar with the good.
Read the code fast people are not anything faster than you, when they encounter some things have not seen also need to query, write some examples to familiarize themselves, also take some time, familiar with a single point of knowledge is not faster than you.
Documents and test cases for the landlord's current stage is not very useful, these things can only be in your reading code faster after the icing on the cake, many times to see the document and test routine to speed up understanding the speed of the library, and the role of a Code control
If you want to be familiar with this library to improve the level of programming, the use of the third-party library and programming skills to write their own, so look back to know why the author wrote, a lot of code looks very complex in fact, the idea is very simple. At first I also felt that I did not master the method, once also wanted to buy a very famous book to teach people to read the code, and later did not buy, because unconsciously I found that I read the code more and more easily.
You think the call stack jumps and jumps, doesn't it? Do you think the module function is too complex to contact too many feedback loops? Actually, the real reason is you don't have enough brains!
At first, I read a three thousand or four thousand line of code to make thousands of notes for a couple of weeks, then no, read down the function call stack is in the brain, up to draw a grass icon for each module dependencies. Then one time to the new speaker module, with Si, function between point to point to point quickly, finally found me this breath has gone dozens of functions.
Computer running programs, too many call stacks will run out of memory freezes, people read code, the brain's call stack too many will run out of memory and faint, the solution is to read more code, your brain can support the deeper memory of the depth of the call to develop. When you break the tipping point, you will naturally know how to read. First scold the author, then find a small point of the example debugging. Look, look, look at the hundreds of thousands of-line scale system and then look at other systems on the natural hushed.
Original address: Aaron Liu-welcome to my blog! • Read the source code in a few steps
Skills Required: Program debugging capabilities.
1, run through the program.
2, run the core function of the program, from the outside to understand how it works.
3, read the official documents related to the core functions.
4, read the core function corresponding source code (that is, core modules) and unit testing, from the inside about the core modules of the link between.
5, put forward a question about the source code (such as how the state machine works, filters into several layers, etc.), to try to solve.
6, browse the problem related code and test, and then debug the side to solve the problem, (do not be very unfamiliar with the code to start debugging, too long the stack will consume too much time).
7, continue to ask questions, until the core module in the heart.
8, (optional) communicate with colleagues to learn the module, or write a blog and share with friends to deepen memory, get feedback. This time you are likely to find an understanding of the loopholes or errors, to check the leak.
9, start reading the sub-core module and repeat the 3-7 steps.
10, if not enough, for the program to develop plug-ins or libraries bar.
11, understand the source code.
For more information, see my PPT: How to read the source code. Pptx_ Free High Speed download
The method of problem-oriented reading code is divided into two parts: external and internal.
External reading: With the problem to see, oneself put forward a program common application scenario, and then go to the program to test some of the main logic, such as the background to add a, the foreground is generated B? Server modified C, the client will not appear like D.
Internal reading: Take the problem to see, put forward a how to write a program to expand the scene, (You want to expand this piece of logic later how to do?) There is no built-in API available to call), in short, do not be the document with ideas to go, to be the problem with the idea.
Please make more bricks or add, thank you.
There are several special books and articles in this area, and friends provide specific, systematic skills that are not repeated.
Or from a personal point of view, not to seek comprehensive, mainly two points:
- From the beginning to understand the goal, the level of understanding the design of the target system to the final how to achieve the specific details;
- If you have the ability, or even think about it: to read someone else's code, rather than to do it yourself again-then you can also start by figuring out the goal, then propose a solution, get a solution, and then break it down into modules ... Break it down by layer? Would that be a struggle?
The main techniques are about a few key words:
- Top-down: Features implemented from the target code, problem solving (requirements), layer-by-level decomposition/problem solving, top-down reading
- Sketchy: Figuring out the frame and avoiding staying in a certain detail, if you have questions about a particular detail, record it and look deeper.
- Breadth First: Read through one level at a time (such as first mastering the main modules and their relationships, the second is a few major classes, the third may be at the method/function level), ensuring breadth first rather than depth first
- Clear purpose, separation of duties: to clarify the purpose/responsibility of each module, class, method at different levels, rather than how to achieve this purpose/responsibility. Because any algorithm serves a duty or purpose, figuring out the purpose rather than how it is done, figuring out why instead of how to
Behind the ability to read code efficiently:
- The way the brain works--like the CPU, when the need to follow up to the next level (depth), you need to write down the current breakpoint, the relevant information pressed into the "stack" temporarily put, and so on to the next level back to revert to the previous breakpoint working state. Think of the brain's stack and the ability to accurately memory is obviously not as good as the CPU, so try to avoid traversing at different levels, even too deep. If necessary, use some computer software to help you read, such as UML tool class diagram, time series diagram, etc.
- Focus on what the goal/responsibility is, then how to achieve the goal/responsibility: Any system is to solve the specific problem exists. How to solve the problem is reflected in the solution, the code is just the implementation of the solution. The solution is embodied in the combination of functional modules, the combination of specific functions/methods, the implementation of specific algorithms (inside the method) and so on.
Therefore, the need for top-down decomposition of the problem, the idea of solving the problem, from top to bottom, each level to understand the level of the global context (breadth first).
- Outside the question: the most likely problem for the brothers who do development is to focus too much on the implementation of "how", common scenarios such as: see what other people do a system, software, functions, the first reaction is "this simple, I will", "Yo, how is this achieved?" I don't seem to "--whether you will or not, please refrain from your technology to achieve impulse. The first question is: Why did why--do so? That must be for a certain purpose, responsibility service. When you read the code that someone else has written, the code must serve the goals and responsibilities of a large and small size, so ignore how, get to know each of their goals/responsibilities, and temporarily ignore the details. Get it all figured out, and then pick the places you're interested in and go deep into the analysis, with plenty of time and opportunity.
--Please refrain from technical impulses and achieve impulse, which is very helpful to your career. Friends who have been through a similar stage may wish to review the experience. The more you are unsure of your technology's ability to achieve it, the more likely it is to have similar problems.
In fact, any industry, often with experience and ability to improve, more and more skilled in the abstract level of thinking, good at using the "top down" decomposition ability, and there is a strong global view and logic to ensure that at any level of the deployment is systematic and comprehensive (in fact, based on the previous layer as the basis for expansion is not easy to omit). Take an example of yourself: Once on my resume I am proficient, master, familiar with various technologies and platforms and a variety of experience cases, and later changed into a sentence- good at solving problems efficiently, and willing to solve complex problems and new problems, especially enjoy innovative ways to solve problems. the resume is written on the direction of the job is no longer limited to software-related-of course 1, this is not so much a personal ability to improve, rather than to find their own efforts and enjoy the direction. Such a stage, at least in thinking has been out of the specific software design and development of the relevant technical background constraints, have the courage to face any industry any problem; Of course 2, do not deviate from the actual choice of professional requirements too strong industry and job comparison; of course 3, Do the practitioners in these industries have the same periodic problem?
The consideration and discussion of such problems has a speed-up effect on personal growth.
Individuals think there are several basic abilities:
The computational power (the capacity of the brain's stack) determines the size and complexity of the problem (the physical limit), the mindset (methodology) that determines the effectiveness and efficiency of dealing with large and complex problems (augmented physical limits), self-restraint (understanding and even controlling physiological instincts), which determines the ability to remove distractions, Then there is the accumulation of experience (reusable modules: the experience of the pattern level and the specific implementation level).
--Like a good chess player.
My mother said that when I was a kid, I liked to play with thread and buttons, and I could sit in a place motionless one afternoon until I could untie a ball of thread.
With the growth, I have not satisfied with the release of all kinds of ball, and even solve the larger and more complex thread, but try and pursue another way: the angle of observation, reasoning, after clearing the clue to find a thread, pick up a gentle shake--wow, the whole coil elegant untied--cool!
A true leader, observed silently in the crowd, does not react immediately to the stimulation of the outside world (self-restraint), to do that sober understanding of the goals and the team and their own people (global view), to find solutions to choose the most appropriate way to influence and drive the people around. Not necessarily a leader in the spotlight, but a leader who is actually a leader who does not need power to drive the entire organization toward an effective problem-solving direction.
See "Ender's Game" friend, recommend its sister article "Ender Shadow", the protagonist of the small beans is an excellent example (to avoid the spoiler stop).
In the future ... Suddenly did not think how to express, first stop it, have friends interested me to share further experience.
Finally, to here also had to hide, hehe. 1. To establish hierarchies and structures
Look at the code is not read fiction, linear downward look on the line. Look at the code to understand the code, build the map of the hierarchy and structure behind the origin code in the brain. To this end, at the beginning of the analysis project, it is necessary to clarify the code of the sub-project, package (namespace), class hierarchy and structure, mainly by which packages, each package roughly what to do with. What are the main classes, and what are their general responsibilities? What are the main methods in the main class?
2. To seize the trunk
Any project that has considerable code is used to do some trivial, transactional things. To understand and grasp the code efficiently, we need to grasp the backbone. For some of the main methods in the code, or the process, can comb out their main steps, the secondary things can be ignored regardless, need to pay attention to.
3. To form a document
As the previous several friends said, the human brain is not good at remembering the methods of the incoming and outgoing things, in our analysis of these things, in an effective way to record the results of the analysis, both to save the work results, more importantly, to help us easier to analyze, to dig deep, know where they are now, Back to the time, and back out, not lost. class diagrams, Sequence diagrams, are useful document forms, or you can use a more flexible chart of your own definition. Good memory is not as bad as writing, diligent brain also diligent hands, see code will be much easier.
4. Reasonable use of all available means
Static analysis, of course, is the basic method of analyzing code, but in addition to static analysis, if your code can also run, run it, observe its call stack, LOG, or trace it with debugging tools. For those major methods, processes, it is necessary to use a dynamic tracking method to figure out its process. This will also be more straightforward than static analysis, telling you exactly what paths it is going through and what methods are being executed.
Personal habits First Look at the document description to understand the function and then do a demo, understand the basics of the function from this familiar point cut to see.
I have also seen the direct hard-biting code of the cattle, for him, this way is simple and rough, fast effect good.
