| As with most things depends on the code base, but if documentation in whatever form is available, I'd start there rather than just jumping into code. 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. |