One of the main reasons is, to make sure that we always get another set of π on all the code that is going into production. And secondly, it's to improve our collective knowledge π§ .
When you're reviewing a PR:
- β If you do not understand something, ask why, it was done this way.
- π If you like something, point out that you liked it.
- π If you see something fishy, voice your concern and suggest ways how we can make it better.
- π° Donβt just think about the raw lines of code being added/removed. Think about the impact of this change in the project in general.
- π And, be thorough, dry run the code in your head, see if it makes sense, you can catch bugs before they even get merged (P.S. the only way to get better at this is to practice it a lot! So go ahead and start today :man-lifting-weights:).
- π€ No one is here to judge, that is not our job. Don't be shy to share your work and comment on other people's work. The goal is to improve together as a whole.
It is important that we all contribute to this process of reviewing each other's code. Don't expect anyone to ask you for a review, just go in and give a review yourself. Either you or the author will be learning something new!
Reviewing code is as important as writing the code itself. The quality standard of our codebase is directly proportional with the amount of effort that we put in making sure that this standard is kept by all of us. Let's do our best to not let pull requests collect dust when they are open and to not end up merging them in a hurry.
And last couple of points:
- π£ Keep your PRs small, so that reviews will have an easier time to review your code.
- π Review other people's code, your input is important. If we all do this we'll have a nice cycle of giving and receiving PR reviews.
π