3 ms·
In one of the teams I worked in we had a policy to mitigate some of the things we found inefficient in our code reviews: 1- anything done in a pair doesn't nee
by _shadi 8y ago
In one of the teams I worked in we had a policy to mitigate some of the things we found inefficient in our code reviews:
1- anything done in a pair doesn't need a code review.
2- any story that is more than 3 story points should be worked on in pair.
3- if you are doing a code review and you find something that needs to change you don't leave a comment, you update the branch and ask the original branch owner to review your new commit.
- arwhatever 8y ago#3 sounds like a really good idea to get the reviewer to put their money where their mouth is, so to speak. Conversely,I could see that requirement causing particularly poorly-skilled developers tying up a disproportionate amount of the more skilled developers' time
- _shadi 8y agoI see your point but we found out that this way the review will be done quicker rather than having discussions on the PR, since before adopting this policy the comments usually had pseudocode in them. anyway duo to #1 and #2 what actually ends up needing a review is the only minor or medium scope changes, and most of the time the commit will be renaming a variable/method or adding a test case. of course if you see the PR went in the wrong direction you can still reject it.