If any professional software development team, code review is very very important. It’s part of the day-to-day life of a coder. The way a team generally works is something like this
This video is a nice demonstration. It gets good at 6min 30 seconds: https://www.youtube.com/watch?v=oFYyTZwMyAg. If you watch it from the beginning there might be some confusing things.
Play around with it a little bit. Github doesn’t bite.
Since PRs are part of the day to day life of professional techies, we expect you to start practicing good habits now.
If you follow these simple guidelines you’ll be good to go:
1. if someone asks you for a review, then review as soon as you can
2. If someone has given you a review, act on it quickly
You need other people to Approve
of your code. If people are requesting changes then work through all the problems until it is ready for merge.
Once you have 2 Approvals
you’ll be able to click on the merge
button on Github.
3. If you need to merge some code into master
Make a pull request. You can use Github’s ui to request that specific people review your code. The people who should review it are the “reviewers” on your Tilde card.
Don’t add people to your PR as ASSIGNEES. Add them as REVIEWERS. Lots of people get this wrong. Be precise.
If there are not enough reviewers available for whatever reason, make some noise! Ask a staff member that you need a different reviewer.
REMEMBER: It is YOUR JOB to get your stuff merged. Your reviewers and the staff are there to help you to do your job. But it’s still YOUR JOB.
How to make this efficient
Smaller PRs are easier to review than bigger ones. You don’t need to do an entire project all in one go. You can start getting feedback on a piece of work as you build another piece
Prioritise feedback over writing new stuff. There are lots of reasons for this. It basically just makes the team faster as a whole
If you have a choice between finishing a thing, or starting a new thing: finish. Always bias your actions towards moving things to complete.