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
Jérome Perrin
gitlab-ce
Commits
85c4aa4a
Commit
85c4aa4a
authored
Dec 01, 2016
by
Grzegorz Bizon
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Copy-edit text about right balance in code reviews
[ci skip]
parent
5b052605
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
10 additions
and
10 deletions
+10
-10
doc/development/code_review.md
doc/development/code_review.md
+10
-10
No files found.
doc/development/code_review.md
View file @
85c4aa4a
...
...
@@ -76,25 +76,25 @@ experience, refactors the existing code). Then:
## The right balance
One of the most difficult things during
the
code review is finding the right
One of the most difficult things during 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
-
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.
makes it possible to hide complexity and
makes future changes easier
.
-
Asking
the reviewee to change the design sometimes means the complete rewrite
of the contributed code. It's usually a good idea to ask another 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.
well.
A
good example is a security fix which should be released as soon as
possible. Asking
the 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
...
...
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