| A lot of people are giving advice on changing/testing/refactoring etc, I'm not sure if that's what you are asking, as opposed to how to lean a new code base. My technique for learning code bases, other than asking other devs questions like :- "What architectural patterns are you using?"
"How do you deal with testing?"
"How is it deployed?"
"how do you deal with data access?"
"How do you deal with data migration"
"how do you deal with scaling / concurrency / security / authentication"
etc... broad stroke things. If there are no other devs...look at the code and look around at some of these broadstroke things. One thing you may find is they are using an architectural pattern you aren't familiar with, so be on the lookout for things that look odd but look very deliberate and duckduckgo to see if you can find any information around names in the code. Like if you saw FooActor BarActor, google for Actor / software etc. Another thing to keep in mind when you find odd stuff is that quite a lot of devs copy paste stuff from the internet, and implement partial ideas they have learnt about, so duckduckgo for snippets you suspect. Then the main thing I like to do is take a usecase from the software and follow it right through every layer, either through static inspection, or using a debugger. I then follow up on things that initially seem confusing. I then start sketch out a bit of an architectural diagram ( throwaway ) For Embedded systems code I tend to start from boot and draw out a bit of a flow diagram of what's happening. |