2 ms·
Following one feature through the code base can be one interesting way - especially if that feature is something you understand from previous experience. e.g. f
by trebligdivad 7y ago
Following one feature through the code base can be one interesting way - especially if that feature is something you understand from previous experience. e.g. follow the life of a packet or a block read sya in a kernel; or one particular library call somewhere and just follow the path it takes.
You do have to be a little wary that you might be following an unloved/old part of the project that needs work; so you might not be learning the ways that they want new contributions to use.
- mikekchar 7y agoThis is pretty much what I do. Very few people do literate programming, so it's hard to read code like a book. Instead, I think, "How did they do X" and try to find out. This introduces you to the code. Another interesting way to read code is to ask yourself the question, "If I wanted to add feature X, what would I have to do"? This allows you to peruse the structure of the code. I find that searching code is much, much easier than reading it and once I've answered my questions, I usually have a better understanding. The last way I read code is to add a unit test. Most code is poorly structured for unit testing (by "unit test" I mean testing some function with real collaborators -- the real collaborators are important for this exercise). Then I try to refactor the code so that it's easy to write the unit test. Just trying to create the collaborators usually leads to a lot of insight into the code (and is one of the reasons why I recommend to people that they avoid over-mocking their tests -- but that's a story for anther time). You may not succeed in writing your test, but you will almost certainly understand how the code fits together and where the smooth and rough parts are.