
Ask HN: How to deal with big existing code base when you are new to the team - maheshs
Context - I am just starting with a team as a new member which have huge ReactJS code base. I have only basic understanding of ReactJS.<p>Is there any mental modal, tips, experience which I can follow to speed up my understanding of framework as well as code base and start contributing ASAP?
======
machiaweliczny
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/

------
seibelj
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.

~~~
thescriptkiddie
My team's code hasn't been able to run locally for at least 7 years. All
development consists of committing changes to SVN trunk and running a Hudson
build to update a shared dev server. We have hundreds of commits per day,
mostly with unhelpful messages like "up".

halp

~~~
kls
I cannot agree with the GP post more, you should be able to reproduce a
working environment from source and environmental config. If you cannot you
may want to try getting your team and your management to see the value in
investing in doing so. When I took my latest contract, I literally walked into
an environment where developers where pushing to the same server, debugging on
the same server and generally stomping all over each other. I felt like I was
developing in the 90's all over again. They did not see that it was a huge
productivity killer. I took the time to automate the development environment
to the point where each developer was able to run a script and have a fully
local dev environment. Isolated DB, isolated server, isolated LDAP instance
everything needed to run the environment completely disconnected. It is really
not that hard to go thru the process of setting everything up and capturing
the process in scripts, even something as simple as shell scripts or
powershell scripts are better than having the dev environment fail, and having
to stop progress while everyone scrambles to get an environment back up.

As for the topic at hand, I always find the entry point of the application,
fire up the debugger and walk thru the main workflows of the application. This
generally gives me enough of a mental map of the app to be able to dig into an
area when I get a bug or feature request. The debugger allows you to break on
areas you don't understand and work thru them in more detail.

Total tangent: this is why I detest and will not whiteboard in interviews, I
am a debugger forward developer, it is how I reason about code. I think behind
the compiler (or interpreter) the debugger is the second most important tool
in a developers toolbox. It's sole purpose is to help a developer understand
what is going on at runtime. It is hands down the best way to learn a new
codebase.

~~~
thescriptkiddie
Any advice on what to do if the code is heavily entangled with AWS?

~~~
kls
You should have development or pre-prod versions of your AWS services, for
those areas local dev environments should point to those endpoints. Ideally
each dev would have their own AWS sandbox, but I get it that sometimes that is
an impractical solution so what I would personally do, is create a nightly (or
unstable) instance where one can test their code against the latest code base
and push needed changes to, a stable instance where known stable features and
bug fixes get deployed and then a release instance where testers can test
against items deemed fit to go out in the next release. Developers should
switch their local to unstable and stable endpoints based on their needs as
well as the condition of unstable. If someone breaks unstable, other
developers can still progress against stable they just cannot push to it. So
think of stable as can read but cannot write. Once unstable is back up, they
can push any service changes they need to up to AWS. As a side note, it is the
responsibility of whoever broke unstable to get it back up and running for the
other devs.

------
seanhunter
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).

~~~
seanhunter
oh also look at the repo history to know who the real major contributors are.
You don't want to waste these people's time, but buying them the occasional
coffee and asking good questions can be worth its weight in gold. `git
shortlog -ns --no-merges` is worth looking at.

------
Kagerjay
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

------
kbrannigan
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?

------
thiago_fm
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!

------
danbolt
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.

------
potta_coffee
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.

------
jammygit
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

------
AnimalMuppet
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.

