Code reviews are essential for code quality, team collaboration, and to make sure that best practices are followed in the development process. Gues...
For further actions, you may consider blocking this person and/or reporting abuse
Great post that will be very helpful for teams to improve their communication, particularly in the area of PR reviews.
I would like to add two additional points based on my experience so far.
For PR creators.
Make your PR as small as possible: Small PRs help reviewers to quickly understand the intent of the changes, eliminate the danger of missing a potential issue in a huge PR, and avoid receiving a huge number of PR comments that may delay PR merge.
For PR reviewers.
Take it offline: If a conversation in PR comments has more than two replies on the same topic, try to understand and resolve the conflict in a quick adhoc one-on-one meeting if possible. This shows that you truly care and want to resolve the conflict as soon as possible in order to avoid any delays in the PR merge.
And to expand on your last point: bring the conclusions made offline back to the PR itself for other reviews
Amazing points, Michael! I totally agree with your two considerations
I approve your article. I'm a senior engineer, and a good reviewer.
I like how your article is related to mine and what I explained about cognitive biases.
Discover your cognitive biases 🧠🤔, and how to deal with them 💪🤩 !
Christophe Colombier ・ Apr 22
For example, the "avoid pull request friendship" is such a good point. It relies in confirmation and error attribution biases. It's almost the same for "review the code, not the person"
If you want good review and to improve yourself. You must face people who disagree with you. We learn from our failures
Thanks a lot for your comment, Christophe! I'm also a code review lover, and I think that is a worthwhile moment. We can learn, practice, and teach.
Thanks for sharing your article. It's an important subject and, to be honest, I need to reflect on it.
Really a good article! It brought me several points of reflection about my way of working. Thank you very much for that.
If I could contribute here, I would add a point about creating a pull request. I believe it's also very valid to have a description of how to test that feature. It's not always easy to validate something in production or staging environments, but having a path to follow already helps a lot and serves as a way to explain more about the context of the feature, making the review easier later on
Amazing remember,@italolourenco! Thanks a lot for your suggestion and feedback!
I have created the 3.Provide context about this 🚀
Amazing points, I try to follow most of them..
As an engineer, I consider PR reviews a vital step in development process.
For my experiences I would like to add is:
Create a
pull_request_template.mdfile on.githubfolder . Add all the points as a checklist you think are important in your company for PR creator to mark while creating the PR.There are tons of template online, pick one and change it to your needs and add it. Helps when you scale and also reminds to always do those tasks.
Example: github.com/cezaraugusto/github-tem...
Happy coding!
Thanks for amazing remember, Murtaza 🚀
I agree with pretty much everything here, however, I'd like to push it one step further. What about not following the pull-request model at all? I find stacked-commits in the style of tools like Gerrit offer a much better code review experience, both for the reviewer and the developer. Helping greatly in keeping reviews small and isolated. Being able to comment on the commit message itself is also a great advantage.
I have never heard about Gerrit, thanks a lot for sharing, Daniele. I'll take a look at it, looks great.
Sure. Essentially it helps greatly with keeping PRs(Which are called Changes in the Gerrit world) small, by enabling stacking of commits, which can then be reviewed and updated individually, while still making it easy to test the whole chain of commits as one.
This way, developers don't need to compromise between keeping PRs small or creating separate PRs, which are then a nightmare to maintain and merge separately.
Also, having the commit message as the "PR Description" helps greatly in keeping a clean and expressive git log, helping future debugging.
This is amazing and easily overlooked part of the job as a software engineer/developer. The difference between a good and a great engineer/developer is this right here, PR reviewing and creating skills.
Thanks a lot for your comment, Kirk!
Nice article! I wonder if I can make an AI copilot to do my PR reviews for me in this season of AI… 🤔
Gerrit already supports integration with ChatGPT, I'm sure GitHub and GitLab have something similar.
Awesome article!
Very interesting. I learned a lot, thanks for writing!
thanks for the feedback, @best_codes 🚀
Pretty good rules ! Always good to keep in mind.
Hey @tassiofront
I thought about you and your article by writing this, 🤣😂
dev.to/ccoveille/comment/2eob1
hahahaha great comment, @ccoveille 😂😂😂😂 I remember the biggest PR I have reviewed: more than 7000 lines changes (1 feature). I have had nightmares since then... I don't wish it on anybody else. 😜
Great perspective! Polite communication from both sides can make things so much more efficient. And yep, devs can use AI code assistants to help with code reviews, saving some repetitive tasks.🤧
That's something awesome and useful article. Thanks
Thanks a lot, Arafat!
Nice article
Screenshots and visuals go a long way!
If anyone is interested in creating a free portfolio website in 1 minute ⚡️ check out my site 👉 mydevpa.ge
Good tips, but this was AI generated unfortunately according to GPTZero.
I have used AI to help me with English, as I'm not a native one.