Automation - The Practice of Cloud System Administration - page 268

would not let just anyone edit their load balancer configurations. However, if they are kept
in VCS and require approval by someone in the load balancer team, the process of load
balancer updates becomes self-service. Given a good “how to” document, anyone can edit
theconfigfileandsubmittheproposedchangetotheloadbalancerteam,whocheckitover
and then submit the change to activate it.
There are other reasons to use a code review system:
• Better written code. Code review is not just a style check; it is a time to deeply
consider the code and suggest better algorithms and techniques.
• Bidirectional learning. Whether the reviewer or reviewee is more experienced,
both improve their skill and learn from each other.
• Prevent bugs. A second set of eyes catches more bugs.
• Prevent outages. Using a CRS for configuration files catches problems before
they hit production.
• Enforce a style guide. Code reviewers can give feedback on style violations so
they can be fixed.
The time spent on a code review should be proportional to the importance of a file. If a
change is temporary and has a small influence on the overall system, the review should be
thorough but not overly so. If the file is in the core of an important system with many de-
pendencies, more thought should go into the review.
Membersofahealthyteamacceptcriticismwell.However,thereisatricktodoingcode
reviews without being mean, orbeing perceived asmean (which isjust asimportant): criti-
cize the code, not the person. For example, “This algorithm is slow and should be replaced
withafasterone”isneutral.“Youshouldn'tusethisalgorithm”isblamingtheperson.This
subtle kind of blame undermines team cohesion. The ability for team members to give cri-
ticismwithoutbeingcriticalshouldberole-modeledbymanagersandsubtlypolicedbyall.
Not doing so risks poisoning the team. Managers who do not follow this advice shouldn't
act surprised when members of their team unfairly criticize each other in other forums.
12.7.7 Writing Just Enough Code
Writejustenoughcodetosatisfytherequirementsofthefeatureortofixthebug.Nomore.
No less.
Writing too little code means the feature request is not satisfied. Alternatively, we may
have written code that is so terse that it is difficult to understand. Writing too much code
creates a maintenance burden, creates more bugs, and wastes time.
Writing too much code is an easy trap to fall into. We may write code that is more flex-
ible, or more configurable, than we currently require, or we may add features that we think