21–30 of 49 posts
You can use the debugger on low level api calls to get pretty much anywhere in the codebase. If you want to find whats changing a label to "foo" you can hook into every set_Text call and put a conditional breakpoint on all label changes to break on "foo", then just go up the callstack to find the logic. This strategy works on network interfaces and file interfaces as well. I abused this on our 2M+ SLOC legacy codebas…
I'd like to point out that if it is truly large, then deep intimate knowledge of specific parts will never be truly had. Those who do know the entire project understand the flow and architecture of it but the details are blurred.
Starting to understand it involved reading our documentation on the data-flow between different components during operation, to know the purposes of the important binaries. For the really core components, we had a fair bit of documentation at the level of classes.
You'd usually end up learning the sections of particular programs that you worked on in great detail, the programs themselves as a whole in slightly less detail, getting fuzzier as you moved away from your areas of greatest experience.
I'd like to point out that if it is truly large, then deep intimate knowledge of specific parts will never be truly had. Those who do know the entire project understand the flow and architecture of it but the details are blurred.
You can use the debugger on low level api calls to get pretty much anywhere in the codebase. If you want to find whats changing a label to "foo" you can hook into every set_Text call and put a conditional breakpoint on all label changes to break on "foo", then just go up the callstack to find the logic. This strategy works on network interfaces and file interfaces as well. I abused this on our 2M+ SLOC legacy codebas…
This isn’t abuse... it’s exactly how you’re supposed to use a debugger.
I don't consider it abuse either, though.
Earlier quoted context omitted.
This isn’t abuse... it’s exactly how you’re supposed to use a debugger.
I suppose the difference is you'd normally use a debugger to find out why the code isn't doing what it's supposed to, rather than using it to find out what the code is supposed to be doing in the first place. I don't consider it abuse either, though.
I see the debugger much more like a "REPL for a compiled language" than a "bug removal tool". I try to teach people to think of it as an interactive inspection tool, not as (merely) a thing to fix broken programs.
* Read any developer contribution docs.
* Glean what info you can from the layout and naming of the source tree.
* Peruse the code and any comments and see what does what.
* Read the unit tests to see how things are expected to work.
* Peruse the issues list to see what's breaking.
* Try to get a feel for how the contributor(s) think by reading any public blog posts, etc.
If none of those approaches yield any insight, don't blame yourself; maybe instead look for a different OSS project to contribute to.
Use a static analyzer to build a graph of the codebase.
Build an adjacency list and a graph of the imports; and topologically + (…) sort.