Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Léo-Paul Géneau
gitlab-ce
Commits
5b052605
Commit
5b052605
authored
Nov 30, 2016
by
Grzegorz Bizon
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Extend code review docs with chapter about the right balance
parent
09806605
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
27 additions
and
1 deletion
+27
-1
doc/development/code_review.md
doc/development/code_review.md
+27
-1
No files found.
doc/development/code_review.md
View file @
5b052605
...
...
@@ -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
"LGTM :thumbsup:", or "Just a couple things to address."
-
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
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
Largely based on the [thoughtbot code review guide].
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment