How to deal with big existing code base when you are new to the team

Start with understanding what business problem the app solves.

Understand roles in application (admin, user, etc.) Click through the application, do list of all URLs/pages, describe what you think it does and consult with PO/team to clarify understanding.

Then learn where data comes in/out and in what format. Study schema of database (hint: ERD diagrams). Then study business API (schema, endpoints, graphiql).

Then you can move to frontend. Frontend is easy after you understand all above :P You will basically know what it does/should do, so you don't even need to read code.

React code is very modular so it's easy to navigate, to find where to start simply use React Devtools (shows component name on hover), then you should be able to navigate rest of code via IDE/editor.

If codebase is of high quality it should also have React Styleguidist or Storybook with most components to play with.

To understand react it's best to write it yourself:

  * https://jasonformat.com/wtf-is-jsx/
  * https://dev.to/ameerthehacker/build-your-own-react-in-90-lines-of-javascript-1je2
  * https://pomb.us/build-your-own-react/

Get the application working locally. You will likely find a lot of old half-written doc that doesn’t work anymore, and other developers have tricks and changes they made on their local machine to get things running. You should get it all running yourself and document what you did for the next developer.

I don't know ReactJS so the below is just generic advice. That said there are a few solid starting options that I have used at different times in my career:

1) start with tests - reading existing tests, adding tests, fixing tests which fail etc. Any of these should really help give you some threads to unpick to get started in understanding the bigger picture. I don't think I've ever seen a dev shop where an old hand would turn down a PR review from a new engineer who was adding new test coverage.

2) start with backlog - try implement some dusty feature from the backlog that has been sitting there for a while. One place I worked I started with "Convert 100+ functions from deprecated format A to new shiney shiney format B". Another was "fix the thing which isn't compiling on new platform X". Another was "fix the millions of warnings we get when we turn warnings on". These are really unimaginably boring tasks in and of themselves, but focused me on a few different things which are useful to know early (how to push a PR, how tests work, how the build infrastructure works etc) and get you started contributing something useful right away.

3)Start with infrastructure - I like the suggestion which someone else has made of getting the app to run locally. I would extend that to fixing a piece of broken dev tooling. If you're infrastructure-minded, this can be a nice way to start and win you some goodwill with other devs.

Don't think you need to understand everything to make a big contribution though. A lot of coding isn't about being an expert it's about putting in the work. Observe code reviews, see what gets merged and in particular make sure you understand and take on board why PRs get rejected/resubmitted.

One thing to bear in mind is you're going to be a bit of a tax on your colleagues while getting up to speed. Help them (and yourself) by making your PRs shorter and simpler initially to make sure you're on track. (eg in the example above, don't do 100 functions in one pr, do one, submit it, ask for feedback, then do more).

My coworkers at every new place I work at make jokes at me for doing this, but I usually identify reference code I can print off right away.

For instance, once you finish a feature or task, identify the most important bits that happen. Create a gist of it on github.com, then promptly print it. It needs to fit on one or two pages at most, delete stuff that's not relevant. Likewise, if you have to learn their styling guidelines and naming, print off the most important parts.

Stuck on javascript concepts? Print the parts you struggle on. Stuck on lifecycle methods? Print the diagram. Constantly flipping between jira tickets? Print them.

The reason why this works is because you apply the concepts of space repetition to pick things up quickly. Your forced to chunk the code snippets in print form in a meaningful manner

As time goes on just write reusable code that you can copy later for different parts of the app. You won't need to print anything anymore because its commited to memory.

Also I make small side projects with coding patterns I can copy paste easily too

Start with a small feature. Like a total count. Look what list of objects is being counted.

Make a note of the object's type.

Find what function is retrieving those objects say A list of users.

What is making the AJAX call to get those users.

Are there any tests?

Take a look at the completed merge requests/features. If any developer of that team was any good, there would be plenty of well-written merge requests and commits.

With that, you would know what to touch and when.

When in doubt, check tests, the feature itself and the git history.

If you are new to ReactJS, also try to look for a mentor inside your company/team. They don't need to to active mentoring, but more like a person you can fall back to, and that enjoys doing mentoring and does it well.

BTW, Good luck on your new job!

I'm not familiar with ReactJS, sadly but I often use breakpoint debugging and IO (eg: print statements, drawing shapes, logging, etc.) to help get a feel for the common data flow quickly. This lets me make a hypothesis like "when I click on this button, does this line get hit?" or "does this series of functions get called?".

Sadly, I'm not 100% what that would look like in your situation.

There are lots of good tips, I'll add mine: I always ask for a few simpler bugs or small feature requests that I can use to learn the codebase. For me, it's easier to dive in when I have a smaller surface to focus on.

I wrote a lot of sequence diagrams for tasks I worked on and saved the interesting ones. Also, finding somebody senior to explain a module pays off big time. Also, learn the database schema: all an app really does is manipulate data

Pick a part (like maybe the part that you're first going to have to work on). Get a tour of that part from someone on the team. Then dive into that part. When you have questions, ask.