Why do I love reading code? Why should you love?

Http://blog.csdn.net/bvbook/archive/2011/02/16/6187192.aspx

I hate reading code.

I've found that many programmers hate reading code--Please don't hide it, admit it. Almost everyone likes to write code--it's fun to write code. However, reading code is not easy, but also very annoying, and there is no escape, the other people write code is always very rubbish (even if not, we also think so in mind). Even if you write the code, a few hours to see a bit of garbage, the time longer, more rubbish. Then, there is no reason to see other people's lame code, but not to write a few hands beautiful. Can you ignore this question for a few hours and look at someone else's code and look back to see if you are still so beautiful. Even if there is a master sitting in front of you, if you can not learn from him, you will never become a master. One way is to find a master who can teach you all your knowledge. Is that possible? Of course, it's just hard to meet the good luck. But you don't have to be so lucky to be a programmer, because all the ideas and skills of the masters are condensed into their code for us to learn. All you have to do is read the code--and, of course, if someone gives you a little bit of certainty, it's more of a time saver, but it's basically wishful talking. In other words, to be quite a good carpenter, a lot of fine furniture must be studied carefully.

I love reading code, I always intuitively think that the reading code is very rewarding, yes, it may be a bit annoying even annoying, but your income is definitely greater than this trouble. For example, if you're going to be a great writer, it's enough to be concerned with writing things for yourself. You can try it, but it's not going to make any difference. The accepted fact is that most great writers are hungry for a lot of reading. To write good works, you must first read the works of other great writers, absorb different styles, understand other people's attempts, then can develop their own creativity. In this way, your knowledge can gradually accumulate, eventually you write things only a bit mature, you will find "feeling". Writing code is also so, if you do not read those great code, how can write the program beautiful. Reading great code to a programmer is like reading a great piece of writing to a writer (I dare not Ameri, the phrase is Peter Norvig, a famous Lisp programmer, now the director of Google Research and Development), said he is not a simple figure, So remember this sentence.

Even if you don't believe the above, there is one fact that cannot be denied. To be a competent developer, it is important to be proficient in reading code. Now, as long as the project is not a joke, is the result of teamwork, so there will always be such a code: it is not you write, but you have to deal with it, to modify, or to expand. So, reading code is probably the most important and most commonly used ability in your body, bite the bullet and practice it--and fast.

To be like ... Like those guys who read the code ... Reading code
I don't know how many times I've seen things like this: programmers drag up and down a piece of unfamiliar code and still look blurred after a few minutes. It was not long before they announced that the code could not be understood at all, not to waste time, but to try to circumvent the problem. I don't know what they really want to do, a little bit to understand the meaning of this code, or open eyes waiting for the enlightened. Reading code doesn't depend on years dead stare, what you have to do is to understand it and make it your own. Here are some of the techniques I use, but not all of them, but I think they are very useful.

Look at the code see Blurred eyes

1. Try to build and run the program yourself. This is usually a very easy step, such as when you're looking at the actual working code (rather than the odd code from the unknown source). But it's not always easy, and if you can't build and run it easily, you can recognize the high-level structure of your code as you complete the build and run process. And, reading the work code, you'll be very familiar with how to build your project. Building is usually complex, but understanding the build process and knowing how the code becomes executable can greatly deepen your understanding.

2. Don't stare at the details. The first thing to do with reading code is to find the structure and style of the code. You should start browsing and try to figure out what the pieces of code are doing. This way you can familiarize yourself with the high-level structure of the entire code, and you'll see what kind of code you're looking at (refactoring good, or mess). All you have to do is find the portal (maybe the main function, or maybe Servlet,controller) and see how the following branches unfold. Don't spend too much time on this step, you can always return it when you are more familiar with the whole code.

3. Ensure that all constructs (construct) are understood. Unless you are very proficient in this programming language, there are probably some things you don't know. In a rough look at the code stage, write down every unfamiliar construct. If there are many such constructs, the next step is self-evident. If you don't understand the meaning of code behavior, you can't do anything about it. Even if you are unfamiliar with only a few structures, it is good to look closely at the scrutiny. You may find some knowledge about this programming language that you didn't know before, and I'd be happy to spend a few hours on it.

4. After familiar with most of the construction, you can do several random in-depth exploration. This is similar to the 2nd step, to quickly browse the code base, but this time to randomly draw a few functions or classes, a line to look down. The real test is starting now, but your earnings are also starting to show up from this point forward. The idea is to really dive into the conceptual system (component structure) of the whole set of code you read. This is another step to speed up, but in this step, you must try to understand a number of complex details. And the 2nd step, in this step, every time you know more about the context to look back, you understand more in-depth.

5. There must be something you don't understand in the first few steps, and now the best thing to do is run a few tests to see what you've already tested. Testing is likely to greatly dispel your doubts and deepen your understanding of the code you are testing. I often fail to understand why some developers ignore rigorous and sophisticated test suites while reading and interpreting code. Of course, there are times when there is no test procedure.

6. If there is no test procedure, this time should write a few. There are a lot of benefits to this, it will deepen their understanding, it can improve the entire code base, reading the code is also writing code, so for the existing code and you are good, you can also really hands-on participation. Even if you have a ready-made test procedure, you can write some more to deepen your understanding. Testing someone else's code, generally requires a different perspective, before you feel confused concept will become clearer.

7. Get the parts that you don't understand to a separate program. I find it very fun to do this when reading code, even if only to adjust the pace of reading. Even if you don't understand the underlying details of your code, you may have some high-level thoughts about the functionality of your code. So why not take some of the functions and test them in a separate program? Debug is much easier if you run only a small piece of the program, and the process in turn will deepen your understanding.

8. The code is very messy (dirty) very bad (smelly). So refactor it. I'm not suggesting that you put the entire code base down, but refactoring some of the parts really gives you a better understanding of the building. The first thing to do is to transform the functions you understand into independent functions. Before you really understand, refactoring functions just seem to be fine, and refactoring can turn them into what you want them to be. Depending on refactoring, you can turn your code into your own, rather than rewrite it all. A good test program can help, but if you don't, just refactor it while you're testing it, and just change the functionality you've identified. Even if the test looks too small and imperfect, believe in your own level of development, and sometimes you just have to make a bold attempt (revert can always be rolled back if you really need it).

9. If none of the above works, find a companion to read the code with you. You may not be the only one who can benefit from reading code, so you might as well grab the others and read along. But don't look for experts, they give you a high level of interpretation, so that the attention of the code when the details are ignored. If you can't find someone to read together, you really don't understand, sometimes the best way is to ask someone else. Ask your co-workers if the code you're reading is open source, and you can ask other people on the Internet. Remember, this is only the last resort, don't do it from the beginning.

If the time is very tense, must understand some code in a short time, the above step can only choose one step, I will choose to refactor (8th step). You may not be able to understand too many things, but you can certainly understand the real moving parts. Whether the time is tense or not, you have to remember is: if you first contact with the important code base, you must not immediately read, and even can not quickly read. You may need to be patient for a few days, weeks or months--just be honest with yourself. Even if an expert sits next to you, it won't save much time (the last installment of my series on teaching and learning is about the question). If you have enough patience to read (or write) code, you can be a person who is familiar with all aspects of the project and who will answer questions when there is a problem with the code base. You can also not read the code and choose to be the guy who always wants someone to explain. I want to be who I am, I know it myself.

Seize the opportunity to read the code, do not miss
We all like the new code, the temptation is that we can fix the problem. At least, this time, it can be done next time. The truth is: you are constantly improving in practice and you will never be able to get it done. That's the value of the new code, you're practicing, your level is improving, but reading and changing the code written by others is also valuable (at least as much as you re writing), from which you learn not only valuable technical knowledge, but also knowledge of the entire field of work (after all, the code is the final form of the document), This knowledge is usually more valuable.

Every paragraph does not follow the traditional, unpredictable code, are valuable. You know what I'm talking about, though it looks a mess, but it's not meant to be (or maybe because it's Perl code:)). Every time I see such a code, I think so. Consider reading it as a guessing game and think about what you can learn. Yes, it's torture, but it must be admitted that you want to be able to write such bad code. If you take the time to read this code, you're certainly more likely to write code like this--not that you're going to write that code, but you definitely want to be able to. The last thing to say is that attitude is always very important. If you think of reading code as a chore, it's a chore, and you're sure to run away, but if you look at it as an opportunity, things are different.

This article from Csdn Blog, reproduced please indicate the source: http://blog.csdn.net/bvbook/archive/2011/02/16/6187192.aspx