I'm surprised I didn't see something similar to what I do: the deep-dive.<p>I start with a relatively high level interface point, such as an important function in a public API. Such functions and methods tend to accomplish easily understandable things. And by "important" I mean something that is fundamental to what the system accomplishes.<p>Then you dive.<p>Your goal is to have a decent understanding of how this fundamental thing is accomplished. You start at the public facing function, then find the actual implementation of that function, and start reading code. If things make sense, you keep going. If you can't make sense of it, then you will probably need to start diving into related APIs and - most importantly - data structures.<p>This process will tend to have a point where you have dozens of files open, which have non-trivial relationships with each other, and they are a variety of interfaces and data structures. That's okay. You're just trying to get a feel for all of it; you're not necessarily going for total, complete understanding.<p>What you're going for is that <i>Aha!</i> moment where you can feel confident in saying, "Oh, <i>that's</i> how it's done." This will tend to happen once you find those fundamental data structures, and have finally pieced together some understanding of how they all fit together. Once you've had the <i>Aha!</i> moment, you can start to trace the results back out, to make sure that is how the thing is accomplished, or what is returned. I do this with all large codebases I encounter that I want to understand. It's quite fun to do this with the Linux source code.<p>My philosophy is that "It's all just code", which means that with enough patience, it's all understandable. Sometimes a good strategy is to just start diving into it.
Am I the only one reading this thinking "as written by someone who seldom dives into foreign code bases".<p>After a few months you'll be familiar with it?<p>Wow, I'm lucky to get 8 hours on a new code base before I have to ship a bugfix. Months?? O_o luxury. Sip your pina colada as you write your immediately out dated documentation. Great advice.<p>No, that code base was probably written by several people <i>some</i> of whom knew what they were doing, some of whom were just 'getting the job done' and some of whom were idiots.<p>Probably, the only useful suggestion in that list is code reviews. Hack a fix in, get someone who seems clued up to review and suggest a better way.<p>Look for logging, thats the first thing I do; you're probably not the first person to be given this code to work with, and if you're lucky the last folk(s) made some debugging tools. If not, be a pro and leave some good ones behind when you go.<p>...not documentation.
From my experience, the "be humble" strategy is by far the most important one. Many developers tend to dislike whatever piece of code that was not written by them before even looking into the actual code or they get discouraged because they have a hard time learning how it works. For whoever is in this situation, be humble... pretend your way of writing software is not the only way and see if you can learn something. You may get surprised.
I once had to get my head around over 120k lines of complex, concurrent, buggy spaghetti Java code (for a real-time trading system).<p>My first attempt was to reverse engineer the code into a UML diagram. For some reason I keep making this mistake. A messy code base will result in an extremely messy diagram. It can give a few insights, but between finding a tool which will work and trying to make sense of a tangled mess of lines, visual diagrams usually aren't worth the time.<p>I found that a tool called Chronon was somewhat useful (google "DVR for Java"). This tools just records a single run of a program. It is great for going forwards AND BACKWARDS and you step through the code, take a look at different threads, state of various objects, etc.<p>My strategy was to run the server and have it execute a small and simple bit of functionality (execute a single order). Follow it all the way from input to output. Make the scenario a bit more complex and follow that through to completion. This way you get to understand the core functionality, edge case code and start to get a sense of performance enhancements, etc.<p>I found myself making steady progress and fixing a number of bugs, until I hit heisenbugs, caused by overly clever concurrency/object pooling. It is enough to drain your soul :)
Another strategy that I've often used is to just fix a few bugs that seem to be in the vicinity of the area you want to familiarize with. Heck, I even do this on my own codebases that I haven't touched in a while.<p>I find it helps focus the mind, provides a clear definition of success and forces you to think about a specific area of the code without requiring too much context.
I've done this a lot in my career. My strategy is simple: start by finding a trivial bug, and fix it. Then find a slightly less trivial bug. Do this four or five times. Don't ask anybody about anything unless I'm really lost, just chase the thread and let the bugs lead me through the active code paths.<p>After doing a few of these I've got a fair understanding of the structure of the code and can figure out where to go next.
I find it helps to focus on a 'successful' path through the code, starting with an important entry-point and ignoring error conditions and validation. Once I've covered a fair chunk of what the software does, I can go back and delve into the parts I didn't understand.<p>I'm also wary of comments as I find they can often have 'drifted' in old code and become misleading. I make detailed notes of things that look dodgy or could be improved separate from the code.<p>I'd add that if the project has poor-to-no build scripts that require a lot of manual steps it's worth at least bandaging it up with a shell script early on.<p>I recently worked on a project that had many separate modules with independent build scripts, requiring copy-and-pasting built artifacts that others depended on, and several manual configuration tweaks post-packaging. That stuff is very tedious and sucks your energy. It's not generally a priority to rewrite all the build scripts, but if you're editing several modules it's worth being able to do a one-shot build from early on.
There's a good episode of Software Engineering Radio on this topic, as well:<p>Episode 148: Software Archaeology with Dave Thomas
<a href="http://www.se-radio.net/2009/11/episode-148-software-archaeology-with-dave-thomas/" rel="nofollow">http://www.se-radio.net/2009/11/episode-148-software-archaeo...</a>
I think that the two most important strategies are to actually pair with someone and ask questions after doing some research.<p>Being able to do some pair programming helped me to understand a new code base, in a language I never used before bits by bits. I could ask questions and actually helped on the issue. Asking questions is important, but as stated on the post, you should try to find to answer by yourself first. I'll actually time myself for 10 minutes, and if I can't find an answer, I'll just poke the most prominent person based on a git blame of the file that is related to my question.<p>This is my second week working on a Ruby codebase, without any prior experience with Ruby, or Rails (I've mostly been doing Python with Django and Pyramid for the past 3 years). I managed to get quickly up to speed this way.
What types of tests—or testing software—could be run on a WordPress site? For example, after we update a plugin on a WordPress site we manually check that the site hasn't changed in appearance. What software – or methodology – would you recommend for automating this game of spot-the-difference?<p>The nearest I've found (but not tried) are:<p>Screenster: <a href="http://www.creamtec.com/products/screenster/index.html" rel="nofollow">http://www.creamtec.com/products/screenster/index.html</a><p>Wraith: <a href="https://github.com/BBC-News/wraith" rel="nofollow">https://github.com/BBC-News/wraith</a>
I recently started a new job with a new language and did a few of these steps. The only one that has really helped me learn this codebase is "make something".<p>Making unit tests can be great if you already understand the language (and the IDE), but when you're new to xcode, dont expect a unit test to make any more sense than the code.<p>Pairing can be a great tool, if you are pairing with the right person. You can't always find the right programmer (with the time or care) to sit down and work with you like that.<p>I was certainly humbled by this process, whether by choice or not, and asked my share of dumb questions, but I don't think you can really understand a codebase until you work on it
Working Effectively with Legacy Code, by Michael Feathers, is still my go-to reference, even though it's now ten years old. <a href="https://cmdev.com/isbn/0131177052" rel="nofollow">https://cmdev.com/isbn/0131177052</a>
Nice 10kf overview, but more hand on tips:<p>1. Run the program, look at stacktraces/profiler. Sometimes it's easier to analyze runtime and figure out what the program is doing and what are the main/common patterns.<p>E.g. Java - jstack, C++ - gdb, gprof<p>2. Use some static tools to get call/caller graph and be able to browse program quickly. Jump between definitions, see what's used, what's not.<p>E.g. C++ - docgen, Java - most modern IDE will do just fine
For my current employer I landed on the job during their regression test sprint.<p>Just running through the tests and communicating a lot with testers and developers helped me understand how the app (ought to) behave.
"Ask questions", I found that if you ask too many questions, management starts to get annoyed and actively avoids you and or has attitude in their response.
Somewhat adjacent to the conversation, but Bowery - <a href="http://bowery.io/" rel="nofollow">http://bowery.io/</a> - is building a toolset for getting a full dev environment in a few seconds.<p>Saw them on the "Made in NY" Product Hunt collection yesterday. Has anyone played with Bowery?
Can't over emphasise the importance of a good IDE for this kind of thing, even if you're a hardened vim or emacs zealot. A tool like IntelliJ IDEA makes navigating new/large codebases a million times easier.