1–10 of 69 posts
What are the ways you do it? Is there anything similar available for functional programming?
Hopefully there's an overview of the code base in an `ARCHITECTURE.md` file[1], and then read through it, and the respective documentation and tests for the main modules mentioned in it.
If you assume their tests cover the important business logic / stuff "they want to keep" (ref. "Beyonce Rule"[2]), they should inform you about the most important stuff.
> [1] https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html
> [2] https://www.oreilly.com/library/view/software-engineering-at...
I suggest:
1. Find a senior dev, ask then for exisiting pointers to good documentation to self learn.
2. give that a go, make note of all the questions you have
3. then have a session with that dev for platform walk through. Take lots of notes and ask your questions.
4. offer to update docs where you found errata or missing steps or even complete topics not mentioned
5. suggest to the team anything about onboarding that can be improved.
Someone can explain a code path, what it should do, what the bug is and with that you can get familiar with a path through the application.
Run the code. This sounds so trivial but it's not always that easy. Once it get's running, I discuss with users of the code (be it customers or developers) and try to understand what they use it for and look for that same functionality in the code. Usually by this point I know where everything is and how to make changes if needed.
Honestly, learning to read code and execute it in your head is a super power
(This might be more abstract than you wanted) Hopefully there's an overview of the code base in an `ARCHITECTURE.md` file[1], and then read through it, and the respective documentation and tests for the main modules mentioned in it. If you assume their tests cover the important business logic / stuff "they want to keep" (ref. "Beyonce Rule"[2]), they should inform you about the most important stuff. > [1] https://mat…
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
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
Fixing bugs. Someone can explain a code path, what it should do, what the bug is and with that you can get familiar with a path through the application.
Ask around about the big things everyone would like to change and where the scary code is that nobody wants to touch, and with those things in mind, fix some bugs.
The initial questions will tell you what to avoid initially. Longer term, if you can fix them you'll look like a rock star.