Ask HN: How to deal with big existing code base when you are new to the team | Hacker News Reader

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

28 pointsmaheshs18 comments

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.

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?

View on HN

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.

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

Wow. Can you take a byte for byte copy of the shared dev server and make a VM image or something?

Phoenix project irl

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.

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

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.

This! My first job was a large Django app. It was very intimidating for me at first and the stakes were very high.

After the first successful build everything seemed very natural onwards. Reading the docs and trying to understand he whole system flow were much easier after that. Also, the version control history can give you more insights on the features and the decision being made.

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

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.

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.

Reply on news.ycombinator.com