1–10 of 19 posts
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?
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!
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.
halp
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
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.
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).
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…
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/