diff options
author | Grzegorz Bizon <grzesiek.bizon@gmail.com> | 2016-12-01 09:34:15 +0100 |
---|---|---|
committer | Grzegorz Bizon <grzesiek.bizon@gmail.com> | 2016-12-01 10:42:35 +0100 |
commit | 85c4aa4a6725407a90f8b313488584f193e1b55a (patch) | |
tree | 89c958290c09fb4e88c5129add085da99abf0a5d | |
parent | 5b052605b7eb7281f88040962e530ac80bbe3774 (diff) | |
download | gitlab-ce-85c4aa4a6725407a90f8b313488584f193e1b55a.tar.gz |
Copy-edit text about right balance in code reviewsdoc/extend-code-review-guidelines
[ci skip]
-rw-r--r-- | doc/development/code_review.md | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 709cefcb5c6..52ee633c43a 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -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 |