Commit 5b052605 authored by Grzegorz Bizon's avatar Grzegorz Bizon

Extend code review docs with chapter about the right balance

parent 09806605
...@@ -70,10 +70,36 @@ experience, refactors the existing code). Then: ...@@ -70,10 +70,36 @@ experience, refactors the existing code). Then:
- After a round of line notes, it can be helpful to post a summary note such as - After a round of line notes, it can be helpful to post a summary note such as
"LGTM :thumbsup:", or "Just a couple things to address." "LGTM :thumbsup:", or "Just a couple things to address."
- Avoid accepting a merge request before the build succeeds. Of course, "Merge - Avoid accepting a merge request before the build succeeds. Of course, "Merge
When Build Succeeds" (MWBS) is fine. When Pipeline Succeeds" is fine.
- If you set the MR to "Merge When Build Succeeds", you should take over - If you set the MR to "Merge When Build Succeeds", you should take over
subsequent revisions for anything that would be spotted after that. subsequent revisions for anything that would be spotted after that.
## The right balance
One of the most difficult things during the code review is finding the right
balance in how deep the reviewer can interfere with the code created by a
reviewee.
- Learning how to find the right balance takes time, that is why we have
minibosses that become merge request endbosses after some time spent on
reviewing merge requests.
- Finding bugs and improving code style is important, but thinking about good
design is important as well. Building abstractions and good design is what
makes it possible to hide complexity and is a leverage for the future work.
- Asking reviewee to change the design sometimes means the complete rewrite of
the contributed code. It is usually a good idea to ask other merge request
endboss before doing it, but have the courage to do it when you believe it is
important.
- There is a difference in doing things right and doing things right now.
Ideally, we should do the former, but in the real world we need the latter as
well. The good example is a security fix which should be released as soon as
possible. Asking reviewee to do the major refactoring in the merge request
that is an urgent fix should be avoided.
- Doing things well today is usually better than doing something perfectly
tomorrow. Shipping a kludge today is usually worse than doing something well
tomorrow. When you are not able to find the right balance, ask other people
about their opinion.
## Credits ## Credits
Largely based on the [thoughtbot code review guide]. Largely based on the [thoughtbot code review guide].
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment