understanding a big codebase you have never worked.
Get it up and running in a dev environment and start inserting changes to see what breaks where.
Revert and retry until you’ve learned where you’re supposed to be meddling.
Another big advantage of getting a dev environment setup is if you can get step by step debugging in place as well. You can then use that to follow the trail of a user action from the UI triggers all the way down.
Look at the packages. Try to break it down into architectural layers. Understand in a broad sense what each layer adds to the one before. Rage that it wasn’t so much architected as cobbled together from pieces never designed to fit together. Decry it as total garbage and recommend total rewrite.
As an advanced technique, you can usually skip the first half of this.
Everything except last 3 words.
Yes, I’d start from “Rage”.
Start early in the commit history, see if you can understand the general shapes and concepts the project was using at the start.
Then sort of binary-search your way forward in different sized jumps and see how quickly you can get to present day without sacrificing your sanity. Completely at least.
In what regard?
navigating/ making changes.
Use git? Use CI/CD? What do you mean?
