コードレビューのGoogleのオープンソースのセット（コードレビュー）この仕様は、グーグル以来の開発で最高の長期的な実務経験を表し、ほとんどすべてのプログラミング言語やプロジェクトの様々なタイプをカバーし、Googleのエンジニアリング実用的なガイドの共通セットです仕様、コレクション、Googleがオープンソースプロジェクトや他の組織がこの仕様の恩恵を受けることができるという希望を表明しました。
チームは、ワークフロータスクの枝を使用している場合はコードレビューは、また、コードレビューとして知られている、すべてのコード補完を書いて、自動テストの導入後に、コードのマージ前に、それがコードレビューを開始します。通常の目的は、この目的のために構築されているシステムの欠陥を発見し、ソフトウェア開発者自身のレベル、すべてのツールやコードレビュープロセスの全体的な品質保証を改善することです。コードは次のようにアジャイルチームがある役割を確認してください。
-
コードは、知識を共有するために見直します
-
あなたはより良いコードレビューによって行わ作品を評価することができます
-
コードレビューは、あなたが休暇を楽しむことができます
-
コードレビューを通じて新しいガイドエンジニア
コードレビューは、良いレビューを探して、数多くのチェックを行う必要があるので非常に重要です。リストのさまざまな部分のための一般的な変更は、異なる審査に慎重に検討しています。ペアプログラミング、およびあなたのチームメイトは、高品質なコードレビューを実施することができる場合はもちろん、その後、一般的にレビューされていると考えることができるコードを記述します。また、我々はまた、顔の審査に直面することができ、レビューアは、開発者の質問をします。
Googleのプロジェクトの説明によると、二つの側面のベストプラクティスを表す2つの別々の文書のためのコードレビュー仕様：
以下のように、文書で使用される用語の数のいくつかでは：
- CL：バージョン管理を意味し、「変更リスト（チェンジ）」を表すか、または変更されたコードの独立した審査に提出されました。他の組織では、多くの場合、「変更」または「パッチ」と呼ばれます
- LGTM：意味する「私の意見では良い（私によさそうだ）」、コードレビューで承認CL時のことを言いました
我々は二つの文書の主な内容が何であるかを見て次は、以下のとおりです。
1.コードのレビューガイド - どのようにコードレビュー
コードレビューガイドは、完全なドキュメントされていましたが、著者は読者が読む必要があるかもしれ6つの部分に分割されます。
ガイド--cl承認コードレビューガイドラインの2.CL著者
最高の体験を含めCL-メーカーガイドコードレビューの一部の開発者、およびこれらの経験は、より高速な評価を完了するために、より高品質のお手伝いをすることができます。
Googleのビューでは、目的は、全体的なコードレビューコード健康のGoogleのコードベースレベルそのようにすることです。標準のコードレビューとして以下のルールをグーグル社：
一般的には、一度CLでも不完全CL場合、査読もリストを承認する傾向があるべきで、コードの全体的な健康を向上させることができます。これは、すべての原則ガイドの高度なコードレビューです。また、CLのレビューアがコードが良いデザインを行うにしても、いくつかの機能を追加する必要がない場合、たとえば、審査に合格すべきではない、いくつかの制限があります。
「完璧な」コード、唯一のより良いコードのようなものはありません。査読は、CLの完璧すぎるの各小部分の事前承認を必要とすべきではありません。その代わり、評価は開発を継続するために前方に提案された変更の必要性と重要性を比較検討する必要があります。査読の要件ではなく、完全なコードを追求するよりも、改善を続けています。それは、システムの保守性、読みやすさと分かりやすさを向上させることができれば、それは完璧で、数日または数週間の更新を延期できませんので、CL全体として、そしてません。
査読は、常により良いパフォーマンスの実践に自分のリードを表現するためにいくつかのコメントを残す必要があります。コードの作者が内容はごくわずかである知っているように、これらの慣行は非常に重要でない場合は、我々は接頭辞「NIT」を追加する必要があります。
レビューガイド
コードレビューは言語に関係なく、フレームワークや一般的なソフトウェアの設計ガイドラインの、開発者は開発経験の数を教えるために非常に重要な機能を有しています。常に開発者は、いくつかの新しい知識を学ぶのを助けるためにいくつかのコメントを残して、システムコードの知識の重要な部分の共有は、健康状態を改善することです。もちろん、校閲者のコメント単に教育の場合、および標準的な要件のために、その後、まだ接頭辞「NIT：」を追加する必要があり、あまり重要でありません。
審査基準
技術的な事実やデータは、ビューと個人的なスタイルに優先権を与えます。
コードスタイルでは、Googleのコードスタイルガイドは、最も権威の参考資料です。スタイルガイドは、習慣は個人的なスタイルの問題で任意のコードではないですが、私たちは、基本的なスタイルと、Googleのスタイルガイドが同じであることを確認する必要があります。
ソフトウェアの設計、ほとんど純粋にスタイルの問題、あるいは純粋に個人的な習慣。多くのスタイルは、準指標は、彼らは単にビューの個々のポイントによって決定されていないいくつかの基本的な質問に基づいています。また、場合、コード作成者は、その後、校閲は作者のスタイルを受け入れるべきデータや基本的なエンジニアリングの原則により、いくつかの点で同等に有効であることが判明しました。それ以外の場合は、選択または好みはソフトウェア設計の標準原則に依存します。
他の適用可能な規則が存在しない場合は、コードの全体的な健康に影響を与えずに、レビューアは、作者の好みは、現在のコードベースと一致している尋ねることができます。
競合を解決します
コードレビューでは、いずれかの紛争あれば、最初のステップは、プロジェクトの指針CLに基づいて合意に達するために、開発者や校閲する必要があります。コンセンサスが非常に困難である場合には、開発者やレビューアはレビューコメントを介して通信するだけでなく、顔に顔を伝える必要があります。あなたはまだ議論する会議を解決できない場合は、その後、彼らは会議を拡大する、我々は最終的な合意に達するために、コードの保守担当者、プロジェクトマネージャや他の開発者と交換することができます。
あなたはこの仕様書のGoogleのコードレビューを把握したい場合は、プロジェクトを表示することができます。次のアドレスで：
https://github.com/google/eng-practices
出典：人間のほとんど