コードレビューの大原則
コードレビューを行う主な目的は、全体的なコード品質を着実に改善するためである。 そのためには、相反する２つの立場のバランスを上手く取る必要がある。
まず、開発者は自分が引き受けたことを全うしながらもコードを発展させる必要がある。あなたがコードを改善しない限り、コードは決して良くならない。一方、既存のコードに対してレビュアーがあまりにも厳しく防御し、変化を一切受け入れないと、他の開発者はコードを改善しようとするやりがいを失ってしまう。
それにもかかわらず、レビュアーは、コード品質が徐々に低くならないようにする責任がある。時間が迫っている状況でその場しのぎで問題を解決する事例が少しずつ積み重ねられると、コードの品質が低くなる。したがって、レビュアーはオーナシップと責任をもって、コードの一貫性、メンテナンス性、コードレビューでのポイントなどをモニタリングする必要がある。
こうして我々は、コードレビューの大原則を以下のように立てることになった。
CLが完璧ではなくても全体的なコード品質を向上させる状態に達した場合、レビュアーはそのCLを承認するようにする。
もちろん例外もある。レビュアーが追加したくない機能なら、コードの構造がいくら優れていても拒否できる。覚えておくべきことは、完璧なコードを作成しようとするのではなく、より良いコードを追求しなければならないということだ。完璧さの代わりに継続的な改善（continuous improvement）を目指していく。したがって、完璧ではなくても、CLがコードのメンテナンス性と読みやすさを向上させたら、承認は数日遅れてはいけない。
注意：コード品質を悪化させるＣＬを承認する行為は、いかなる場合においても正当化することができない。緊急事態の場合にのみ許可される。
メンタリング
開発者はコードレビューを通して、言語、フレームワーク、ソフトウェアデザインに関する新しい知識を学ぶ。知識と経験を分かち合うとコード品質はますます良くなる。あなたの意見が教育的な内容であれば、必ず「Nit：「（訳注：nitpickの略語。些細なこと) 接頭語を付けて必須にコードを修正する必要はないと明らかにしておく。
小原則
- 常に、技術的な事実を個人的な見方や好みよりも優先する。
- コードのスタイルについては、スタイルガイドに絶対に従う。定められたガイドがなければ作成者に従う。
- ソフトウェア設計に関する件は、絶対にスタイルや個人の好みに基づいて決定しない。
- 定めた規則がない時は、既存のコードと一貫性を維持するようにする。
意見の対立を解消する
レビュアーと作成者の意見が異なる場合は、この文書に記載されている方法と原則に基づき、できるだけ合意するように努力する。コメント交換だけで合意が難しい場合は、直接会ったり、テレビ会議などを通じて話し合う。会話内容は、将来の開発者のために必ずコメントとして残す。それでも合意がなければ、チーム単位の議論をしたり、TLもしくは元作者の意見を聞いたり、エンジニアリングマネージャーに助けを求める。合意ができないからといって、絶対CLを放置してはいけない。