![]() There are some common effective flows when selecting the reviewers: A possible flow is to pick two to three colleagues who are familiar with the code and ask them to be reviewers. ![]() This is something I see happening more than I’d like: Pull Requests with a bunch of people tagged as reviewers and ending, ironically, in a non-productive code review. Meanwhile, whoever decided to not review the code, is then spammed with zillions of e-mail notifications with all of the review comments, thus creating noise in their productivity. Once the reviewers start to do it, the review process takes forever because everyone has their own opinion and it’s a nightmare to reach a common agreement. ![]() Since nobody started the review yet, your colleague will remind each one of the reviewers to do it, i.e. The thought of “someone else will do it” pops up in their minds, leading to ignore the code review and close the link. Each one of the reviewers receives a notification, then opens the PR link and sees a lot of people tagged as reviewers. Let’s say your colleague is submitting a code review and decides to tag “everyone” because, unconsciously, she/he might want to speed up the process, deliver the best code possible or making sure everyone knows about the code change. In my opinion, picking the reviewers is one of the most important decisions for an effective and healthy code review as a team. Stay humble because the second you stop being a student, your knowledge becomes fragile. The professional finds learning (and even, occasionally, being shown up) to be enjoyable they like being challenged and humbled, and engage in education as an ongoing and endless process. As Ryan Holiday says: “An amateur is defensive. Look at any feedback as an open discussion rather than a defensive reaction. Receive any feedback gratefully as an opportunity to learn and to share knowledge. Stay A StudentĪnyone can do a code review, and everyone must receive a code review - no matter the seniority level. Whenever you see a repetitive comment during the review process, look for ways to minimize it (being with better guidelines or code automatization). Another way of making code reviews seem less nitpicky is to use linters to find code formatting and code-quality issues before a reviewer even gets involved. Screenshots and reference links (Git issue, design file, and so on) are the final touches for a self-explanatory submission.ĭoing all of this will prevent early comments from reviewers asking for more details. A PR description should explain what’s the change purpose, the reason behind it, and how to reproduce it. This will help the author to submit a healthy PR with a complete description. Save Time With Guidelines And AutomatizationĪn effective way to guarantee consistent contributions is to integrate a Pull Request template in the project. As a team, remember to include code reviews in your workflow and set expectations about how long a code review might take, so everyone is synced and confident about their work. Don’t try to rush a code review nor look at it as a bottleneck.Ĭode reviews are as important as writing the actual code. If a change took one week to be made, don’t expect the code review to take less than a day. The team attitude and behavior should embrace the value of a nonjudgmental collaboration, with the common goal of learning and sharing - regardless of someone else’s experience.Ī complete code review takes time. Knowledge sharing and team cohesion are beneficial to everyone, however, if done with a poor mindset, a code review can be a huge time consumer with unpleasant outcomes. □□□□ Working As A Team Foster Out A Culture Of Collaborationīefore we start, it’s fundamental to understand the value of why code needs to be reviewed. In this article, I’ll share how this outcome can be changed by changing your mindset during a code review: This lack of empathy and wrong expectations between the two sides can trigger unfortunate situations and rush the process until it ends in an unpleasant experience for both sides. On the other side, when submitting a code review, you might not know what to wait for. When doing a code review, you might not be sure of what you are looking for. ![]() In such a moment, you can be either the code author or one of the reviewers. Did your team overcome feedback resistance and manage time expectations? Fostering a healthy mindset is the key to build trust and sharing knowledge with your colleagues.Ī ‘code review’ is a moment in the development process in which you (as a developer) and your colleagues work together and look for bugs within a recent piece of code before it gets released. Take a moment to remember the last time you collaborated in a code review. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |