How do you do code reviews?
This question was recently presented to me from someone considering adding code reviews to his team's process.
This...
For further actions, you may consider blocking this person and/or reporting abuse
Very interesting and I completely agree with that.
I would just add, from personal experience, the case that the discussion between developer and reviewer(s) goes over and over: in this case I found that the only way to solve this is to speak (phone call or personally) and leave the online tools. Most people are much more "soft" by person than behind a monitor
that is very true. we are much better in overcoming differences when we talk face to face. If you cannot come to a common ground it also helps to invite a third opinion into the review to "de-personalize" the issue.
Right. Sometimes text is a terrible medium, especially if people have attachment issues with their code (all the more reason to make branches small and short lived!). I try to make liberal use of happy emojis so folks understand that I'm not trying to be a jerk. Sometimes pointing out flaws in code can cause a visceral reaction that we need to be careful with.
I generally try to avoid taking a code review to a phone call or video chat unless I'm really struggling to understand a branch. I find that having the discussion in written form is helpful for the rest of the team and other reviewers of the PR. Once the conversation moves to voice or video, the context of that conversation can be lost unless the PR author or reviewer goes back to recap the discussion in the PR itself.
I like the 500 lines rule. I would be interested if that could be incorporated as an automated rule in a devops setting - with the ability to override of course. It would really help devs to consider the scope of what they are working on when they know they are going to need to defend any huge changes.
Yeah, that's an interesting idea. I bet someone could whip up a one-liner with
diffstatfor a PR that could fail a CI build if the branch was too big. Overriding that behavior would be the hard part though.Awesome one! Another principle which I believe reviewers should follow is the “ask for 50 changes once and not 1 change 50 times”. Otherwise the review takes forever. What are your thoughts on having a good balance between getting s**t done and writing really high quality code?
That's an interesting question! It might be a false dichotomy because sometimes really high quality code with good test coverage is necessary for getting stuff done. I like high coverage test suites because it gives me good leverage to let me do less manual testing. So, in my experience, I find that writing high quality code enables me to go faster.
On the other hand, I'll sometimes throw out robustness depending on the context. For instance, I've got some GitHub Actions scripts that don't need to be bulletproof. In a case like that, I write something reasonable with the mindset that I'm willing to come in and fix things if stuff breaks on me.
Nice article on an important topic often neglected. Is the 500 line limit per commit or per Pull Request? Its not clear in the text to me.
I liked that you said that you greenlight PRs even if the changes are still not applied as a sign of trust and not act as a gatekeeper. Its easy to damage relations in this "power dynamic", especially when the code freeze is just around the corner. I used to go for the "needs changes" quite often in the past but use it less and less. Its important to realize that as a reviewer your job is not to throw bricks in the way of a fellow developer but help your colleagues to improve and ship code.
The 500 line limit I had in mind was per PR. Some devs like to make lots of commits in their PRs. That's fine with me, but that would start to get crazy if someone kept piling on commits to blow up the overall PR size.
Well written :)
Thanks a lot for sharing. Content is completely relative.