Your code will be reviewed. And you can can take steps to make it easier for the reviewer and yourself.
The review is there to improve the code quality and to ensure architectural direction and correctness.
The big benefit of a review is to help you get better. You will learn from Code Reviews.
Everybody's code can be improved. And your code will get better with reviews. Programming is a skill that improves with training.
Code Reviews help reveal implicit knowledge that is not expressed in code.
Four eyes see more than just two. Even the best testing does not lead to 100% bug-free code. It helps, but Code Reviews are a big part of providing confidence in the code.
Everyone can submit their review and we encourage everyone to do so. But only the PM and the Lead Developers can approve a PR.
Once the PR is approved anyone can merge the PR. And you are encouraged to merge the PR once it is approved.
Create a PR as early as possible, and push frequently.
Use the --allow-empty flag with git to create an empty commit and push it to create a PR. Use the branch naming as described in the git handbook.
Create a Draft Pull Request to signal, this is a work in progress. Change to Ready to review once you're confident that it's ready to be reviewed.
If you share your progress early on, the reviewer can take a glance at your work early, and help you move in the right direction.
The template is there to help you and the reviewer to make the process as easy and fast as possible.
The description should reference the issue that the PR is addressing. It should include, in your own words, what you are trying to accomplish. How you understand the issue. It will help the issue creator and the reviewer to better understand and address potential misunderstandings early on.
The description should also include your thinking process. How do you approach this issue.
And It should include how you went about testing this locally. For the frontend which buttons to click on which pages, for the backend which API endpoint to call and how.
As well as anything you’d like the reviewers opinion on specifically (eg class names, time complexity of code, etc)
Run codeclimate locally and address issues early on. It will show you issues that will be raised once you push the code.
Make sure you run the tests locally (no need to run E2E) to make sure they pass.
Don't mark it ready too soon, when you still working on it or did not push the latest changes. Take a look if the code diff looks like you would expect.
If you wanna be proactive leave your own review and comment on the lines that you think might be worth explaining to the reviewer. You will also find issues you didn't notice while you were coding when you take a reviewer perspective.
djfldsjfdjfdfkdsl
read through story - what's the point of the change?
read through PR description
what change is the dev trying to make?
what tests does this rely on to keep working? which ones are new?
run the tests - do the tests actually pass?
review the code
Does the code fit in with the context?
Is the code of sufficient quality?
Does anything look scary? Risky?
Does anything not look right?
Does it solve the problem sufficiently generally or is it too specific?
Have we considered the
resolve conflicts if possible
approve
More QA
For all the different sorts of data, will this work?
For all the different sorts of silly things users and admins can do, will this work?
PO review process
Does it address the business problem?