The Pull Request. The "PR". Celebrated and maligned alike, it's a pervasive part of the modern dev team's toolkit.
Depending on who you speak to, PRs can be seen as either a help or a hinderance to rapid development. Some have even come to dread the time when their code rears its head above the parapet, to be sniped at by rogue colleagues itching for a fight. So why do we put ourselves through this misery, this ritual flagellation?
The roots of the modern review process stem from good agile practice and have their foundation instilled in the Agile Manifesto. Open discussion and striving for technical excellence are pillars of the PR process. Constructive criticism should be highly-prized as a mechanism to build more quality into the product at low cost.
Mastery of this kind of interactive inspection should help avoid two PR smells:
the belligerent inspector (one who aims for the throat and doesn't let go)
the defensive author (one who takes criticism as a personal insult)
These two personas disrupt the process and create barriers to improvement and should be actively discouraged by the team.
The best PRs tend to have the following key characteristics:
small (quick to digest and review)
summarised (contains a summary of what has changed and why)
short-lived (created, reviewed, modified and closed as quickly as possible)
The scope of the review itself is more for the development team to decide in its own "PR Guidelines". There are no concrete rules as to what patterns should be searched for, or what coding standards to enforce. This should be the product of continual discussions and refinements by the team as a whole.
PRs should be used as an excellent opportunity for you to showcase work to your teammates and learn from your collective experience. Good luck with your next one and happy coding!