Ask HN: How to deal with big existing code base when you are new to the team 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? |
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/halp
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.
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.
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).
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
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?
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!
Sadly, I'm not 100% what that would look like in your situation.