41–50 of 69 posts
Try to profile the code and see where it's spending time. Get a good flame graph up, and you'll have a really solid visual representation of what's going on. Bonus: on almost any project, nobody has done a profiling pass in at least a few months, so you'll probably discover some extremely easy performance improvements and you'll look like a goddamn hero when you speed up e.g. the test suite by a factor of 3 in your f…
I'd start from the highest level abstraction of the code and work downwards until I reach a domain I'm either interested in or asked to work on and specialize on that vertical for a while (this can be anything from a few weeks to say 6 months). I then repeat the process on other verticals if needed/wanted.
So going from highest level of abstraction down to actual code:
1. read docs or converse with others around what the value proposition/s are of the product/service/app.
2. Understand the main use-cases or if not obvious, read product brochures or w/e you have in terms of "sales" material for end-users.
3. Try to map the main use-cases back to high-level architecture diagrams (if available).
4. After doing above steps if there are multiple domains I would pick one based on either personal interest or assigned work.
5. When starting with a business domain (meaning some high level grouping of code based on their business function), I tend to focus first on the design of the persistence layers as its usually less dense and less sprawling than other parts of a code base and can give you some idea of state management.
6. From here I generally start up the service/s or apps related to he domain I'm studying and try to play around with it, trying to tie previous steps together in my mind with what I'm observing with my interactions.
7. At this point I would generally have documented my findings (whatever means / form it is done) and ask for a session with someone that's familiar with this domain and ask their opinion of my documentation, making corrections where needed.
7. After this it's generally best in my opinion to just jump into work.
8. Personally I find doing support work fixing bugs for about 6 months gives you a very good lay of the land and people.
Jumping straight into feature work is not optimal in my experience as it's less likely to provide as wide an array of exposure as support.
This obviously only fits certain scenarios, but for your garden variety product/s this is how I'd go about understanding the code base.
Oh, commit history is also a very very rich source of info if there's an established culture of good commit messages.
Not using things like go to definition and any fancy tools, just manually forcing myself to work through files to understand how things fit together and using basic tools like grep
I'd give the complete opposite advice. I use "go to definition"/"find references" to go all around the code base and at the same time try to figure out how each files interact with each others.
Pharo(Smalltalk) IDE is one of the best IDE I've ever used. It even has a feature where you give input object and output object and it tells you what messages you need to send to get from input to output.
Run it under debugger and go thru whole codebase a few times and you'll start getting proficient at it I've recently did it on huge, very very specific codebase and after 2-3 months I understood it (what to add where, not just what's happening where) relatively OK
1: https://www.scitools.com/spaghetti-code
2: https://blog.ndepend.com/visualize-code-with-software-architecture-diagrams/
3: https://www.sourceinsight.com/#call-graphsNot using things like go to definition and any fancy tools, just manually forcing myself to work through files to understand how things fit together and using basic tools like grep
Very surprising! IIUC, you consider "Go To Definition"/"Go To References" and other "LSP assists" unhelpful (or worse) when familiarizing yourself with a new codebase. I personally find them indispensable. Could you say more to help me understand your position?