コード監査基準
監査のコア目的は、継続的な改善のコードGoogleのコードの開発プロセスは、健康を確保するために維持することができることを保証することです。すべてのコードレビューのプロセスやツールは、この目標を確実にするために設計されています。
この目標を達成するために、我々は、トレードオフの多くを行います。
まず、研究者は、個人的なミッションにすることができなければならない改善を行うために。あなたは、コードの改善を提出していない、とすることを決して場合は、製品を向上させることができません。以下のためのコード投稿者あれば同様に、任意の提出が設定されている非常に高いしきい値の変化もまた、熱意を改善提出し、将来的に開発者に影響を与えます。
別の観点からは、言った、コードレビューの責任は変化（CL）の各リストことを確実にするためである1コンテンツではなく、品質へのリードが悪化し続けて時間をかけてより、グローバルにコードの品質を確保することができます。これは、コードが実際に明確なスケジュールの圧力の下でチームがそれぞれの目標を達成できるようにするには、いくつかのショートカットを取る場合は特に、蓄積によって引き起こされる健康問題の非常に小さい程度であるため、コードの全体的な品質を弱め、実際にはより困難です。
コードの監査のための監査役は、彼らの権利と責任を持っています。彼らは、コードが一貫性のあるベースラインスタイル、保守性、およびに言及した記事の他のコンテンツであることを確認する必要があり、「何がコードレビューを確認してください。」
だから、私たちはコードを確認することを期待すると、次の標準的なルールが含まれています。
通常の状況下では、監査は、それはまだ完璧ではない場合でも、いくつかの品質の向上である必要があり、システム全体のコードの変更のリストを確認する必要があります。
導くためにコードレビュールールでは、これが最も重要な原則です。
もちろん、この規則には多くの制限があります。例えば、それは良いデザインと品質監査のコードを直接拒否することができていても、システムの特性が参加することを許可されていない変更のリストが含まれています。
非常に重要な概念であり、「完璧な」コードが存在しない、だけがあるでしょう、より良いですコード。レビュアーが提出を受け入れる前に要求されるべきではない、すべての少し詳細に研磨された変更のリストを提出する必要があります。監査勧告は継続的に改善するために、システム内の重要な変更との間のバランスを確認する必要があります。代わりに注意を払う必要があります完璧な、審査を必要とするのである継続的な改善。変更点のリストは、保守性、可読性、わかりやすさのための全体的なシステムを改善している必要がありません「完璧ではない」ので、しかし、数日または数週間を拒否されたとき。
監査は、自由に改善のアドバイスのための領域にコメントを残すことができたはずですが、これは非常に重要ではない場合、あなたは、このような目の前のように、接頭辞を追加することができ、「NIT：」これは、提出者は、それは彼らが無視することができるということだけ知っていることができます小さな最適化のポイント。
注：このドキュメントでは、言い訳をするために、コードの健康状態の悪化に提出していない、とだけ一定の経済状況下では、あなたがそうすることを検討してください。
メンタリング
コードレビューアは非常に重要な役割は、言語、フレームワーク、またはソフトウェア設計の共通ルールについての新しい知識の開発を導くためにある必要があります。開発者が何か新しいことを学ぶのを助けるためにいくつかのコメントを残すことができますことは常に良いことです。知識を共有することで、コードの品質を向上させるために良いことです。あなたはあなたのコメントではなく、この文書に記載された基準よりも、目的で純粋に教育されている場合は、追加してくださいことを覚えておく必要があり、「NITを：」プレフィックスまたはこれらの変更の迅速な提出は、リストの変更を強制する必要はありません。
原則
- プロフェッショナル現実とデータ否定意見と個人的な好み。
- スタイルの問題については、「スタイルガイドは、」絶対的な権威です。言及していないスタイルガイドで（スペースなど）のビューのいずれかの純粋なスタイルのポイントは個人的な好みです。提出者のスタイルを受け取るために、事前に合意していない場合は、スタイルのこの部分はまた、標準化されなければなりません。
- ソフトウェア設計の側面は、純粋に個人的な好みやスタイルの問題はほとんど不可能であろう。これらは建設の基本原則に基づいており、それはこれらの原則ではなく、個人的な意見に大きく依存している必要があります。時には、いくつかの限られた選択肢があります。提出者は、これらのプラクティスは、同様の（またはエンジニアリングの原則に基づいて、実際のデータによる）であることを証明できる場合は、レビューアが優先提出を受けるべきです。そうでない場合は、ソフトウェア設計の標準ルールに依存。
- 該当する他のルールが存在しない場合は、レビューアは限りコンテンツの変更は、システムの健全性に影響を与えないように、一貫性のある既存のコードベースで提出することが必要とされるべきです。
競合を解決します
矛盾に直面してコードレビューは、最初のステップは、常に、このような「変更提出者ガイド」およびなど、原則的には、この文書および他の文書に基づいて合意開発者や校閲、あるべき「監査ガイド。」
それは合意に達することは困難である場合には、通信や音声通信に直面する提出者と校閲者の顔は、コードレビューコメントを通じて紛争を解決するのではなく、非常に必要です。（しかし、結果は参照の将来容易にするため、変更申請のコメントの形で記録し議論できることを覚えておいてください）
上記の方法は、競合を解決しない場合は、一般的なアプローチは、問題をアップグレードすることです。アップグレードの方法は、通常、チームミーティング、参加し、最終的な決定を下すために、メンテナや経営者の見解を相談するために必要な技術的なリーダーシップによって開始されます。提出者とレビューアは提出アイドルに合意することはできませんしないでください。
次の通知：コードレビュー、我々は何のためになるはずです。
概要：
Googleのコードレビューは、我々は第一原理を確立しなければならないので上のスタイル、ソフトウェアの設計やコーディング、原則です。保健システムのコードの範囲ではなく、個人的な嗜好を決定またはフレームワークのいくつかの種類を使用するためにこれらの原則に基づいています。
レビュアーが提出を拒否する権利を持っていますが、責任の健全度を高め、維持するためにシステムの改善を抱え。自分の判断を製造するための様々な企業の原則に精通している、そして、彼らの意見が分かれている必要と推奨 2つのレベル。
競合に直面したとき、それは提出者またはレビューアの特定の局面の責任ではなく、両側を主張するべきではありませんあなたが判断する上司や外部を要求し、互いにアップグレードの問題を説得できない場合、他の側を説得しようとする必要があります。
：内部では、すべての文字が非常に重要な原則持つコード、コードの愛のための本当の敬意を。そして、ちょうど単にランダムな監査を提出し、ちょうど合併により、タスクをだますません。これは、サポートにチームの文化と健康に依存します。
CL：「チェンジ」の頭文字が変化を指しているが、完全な自己完結型のバージョン管理を提出したり、コードレビューに提出します。他の組織では（非共有改革）の変化（変化する）またはパッチ（パッチ）と呼ばれます。↩