如何阅读代码摘抄（not too good）

1. Try to build and run it . Often this is a simple one step process, like when you're looking at work code (as opposed to random code ). However this is not always the case and you can learn a lot about the high level structure of the code from getting it to build and execute. And, on the subject of work code, you are intimately familiar with how to build your current project are you not? Builds are often complex, but there is a lot of understanding to be gleaned from knowing how the build does its thing to produce the executable bits .
2. Don't focus on the details just yet . The first thing you want to do is get a bit of a feel for the structure and style of the code you're reading. Start having a browse and try to figure out what the various bits of the code are trying to do. This will familiarise you with the high level structure of the whole codebase as well as give you some idea of the kind of code you're dealing with (well factored, spaghetti etc. ). This is the time where you want to find the entry point (whatever it happens to be, main function, servlet, controller etc. ) and see how the code branches out from there. Don't spend too long on this; it's a step you can come back to at any time as you gain more familiarity with the code.
3. Make sure you understand all the constructs . Unless you happen to be the premier expert on your programming language there are probably some things you didn't know it could do. As you're having a high level fly-through of the code, note down any constructs you may be unfamiliar with. If there are a lot of these, your next step is obvious. You're not going to get very far if you have no idea what the code is doing syntactically. Even if there are only a few constructs you're unfamiliar with, it is probably a good idea to go look them up. You're now discovering things about your language you didn't know before, I am happy to trade a few hours of code reading just for that.
4. Now that you've got a good idea about most of the constructs, it is time to do a couple of random deep-dives . Just like in step 2, start flying though the code, but this time, pick some random functions or classes and start looking through them line by line. This is where the hard work really begins, but also where you will start getting the major pay-offs. The idea here is to really get into the mindset (the groove ) of the codebase you're looking at. Once again don't spend too much time on this, but do try and deeply absorb a few meaty chunks before moving on. This is another step to which you can come back again and again with a bit more context and get more out of it every time.
5. There were undoubtedly things in the previous step you were confused about, so this is the perfect time to go and read some tests . You will potentially have a lot less trouble following these and gain an understating of the code under test at the same time. I am constantly surprised when developers ignore a well-written and thorough test suite while trying to read and understand some code. Of course, sometimes there are no tests.
6. No tests you say, sounds like the perfect time to write some . There are many benefits here, you're aiding your own understanding, you're improving the codebase, you're writing code while reading it, which is the best of both worlds and gives you something to do with your hands. Even if there are tests already, you can always write some more for your own benefit. Testing code often requires thinking about it a little differently and concepts that were eluding you before can become clear.
7. Extract curious bits of code into standalone programs . I find this to be a fun exercise when reading code, even if just for a change of pace. Even if you don't understand the low level details of the code, you may have some idea of what the code is trying to do at a high level. Why not extract that particular bit of functionality into a separate program. It will make it easier to debug when you can execute a small chunk by itself, which – in turn – may allow you to take that extra step towards the understanding you've been looking for.
8. The code is dirty and smelly? Why not refactor it . I am not suggesting you rewrite the whole codebase, but refactoring even small portions of the code can really take your understanding to the next level. Start pulling out the functionality you do understand into self-contained functions. Before you know it, the original monster function is looking manageable and you can fit it in your head. Refactoring allows you to make the code your own without having to completely rewrite it. It helps to have good tests for this, but even if you don't have that, just test as you go and only pull out functionality you're sure of. Even if the tests seem totally inadequate – learn to trust your own skill as a developer, sometimes you just need to go for it (you can always revert if you have to ).
9. If nothing seems to help, get yourself a code reading buddy . You’re probably not the only person out there who can benefit from reading this code, so go grab someone else and try reading it together. Don't get an expert though, they'll just explain it all to you at a high level and you will miss all the nuances that you can pick up by going though the code yourself. However, if nothing works, and you just don't get it, sometimes the best thing you can do is ask. Ask your co-workers or if you're reading open source code, try and find someone on the interwebs. But remember, this is the last step, not the first one.