Doing good code reviews as Senior Frontend Engineer in team

Code reviews are important part of delivering the quality code. It is not only helps in maintaining quality in the project but also building habit of writing good code. One thing we need to remember is that thorough and detailed code reviews takes time.
In a team where there are so much code been pushed to the production and by several developers

• Product managers and engineering mangers should give enough time to do code reviews
• We can have the guidelines, we should try to utilise Eslint rule or Tslint rules, as automation is better than manual guidelines. But not all things can be automated so we can set guidelines. We can have guidelines around naming convention in html , css or javascript. So these guidelines helps a lot keeping code consistent

We can follow these things to have better code review process

• Every pull request should have proper description about changes.
• If the change involves any ui changes we can add screenshots, all possible cases of UI — it helps reviewer a lot
• If possible then add a proper video of whole feature with covering all UX flows and cases
• Every function can have JS doc style comments its good to have.
• We can make sure very function doing one functionality else extract it out in a separate function
• Each pull request should not be bigger than 300–500 lines. As Reviewer can reviews the code better and can pick bugs more easily than are reviewing the big pull request. If bugs can be picked in code review process it will helps you shipping least number of bugs or bug free code in production
• Always add a /TODO or /TODO : refactor or /TODO write unit test`, it helps in later picking up things
• Checking the code is not getting duplicated
• If a parameter takes more then 4 parameters it’s better to use object and pass arguments in it
• Checking if something can be cached
• Making sure all code is covered by tests

We can have following automation checks on code

• Making sure code coverage will not falling on any of the pull request if it is then block it (depends if your team is writing tests)
• Flow JS coverage or typescript also not failing
• Ustory for ui component testing can be used if anything changes in a component

Testing

• All independent functions can be covered through testing using jest
• For component we can write test using

Handling unexpected cases

We know that we are sometimes 102% sure that values will always come but it good to handle edge-case

Tone of code review
Code reviews are important but the the tone of reviewing is important. If we do code reviews with aggressive language