まず、コードレビューのメリット
コードレビューのメリットを十分に認識しているコードレビューをしたい、エンジニアが参加することを許可しなければなりません
1、相互学習、お互いの成果
専門家は、またはCURDベースのビジネス開発チームに建築家チーム集まったかどうかは、私たちの技術力は、経験が異なっています。
コードレビューすることで、同じ機能を実現するために、経験豊富なエンジニアが、経験の浅いエンジニアを最適化するために合理的な提案を提供することができます。経験の浅いエンジニアがすぐに学ぶための技術の使用に関連するベストプラクティスの高品質なコードを読み取ることができます。あなたはかなりの技術力ならば、お互いシンクタンクをリフレッシュすることがあります。
あなたはリンゴを持っていると私は、我々はまだリンゴを持って、お互いに交換する、リンゴを持っています。私はお互いに交流し、アイデアを持っているが、あなたのアイデアを持って、我々は2つのアイデア、またはそれ以上を持っています。
図2に示すように、知識共有、自動相互支援
何のコードレビューは、その後、知識のアーキテクチャは、プロジェクトに関与していない場合は、チームのほとんどでは、サービスのアーキテクチャとマイクロアーキテクチャのサービスチームの特に使用は、通常、開発者は、複数のサービス/プロジェクト（プロジェクト）に責任がある、またはビジネス知識、それは文書のみの機能、プロジェクトの実施プロセスの出力スキーマ文書だけでなく、コアプロセスに存在します。
ドキュメントは、エンジニアが状況その他のサービス/プロジェクトを理解し、彼らは別のエンジニアによって書かれたコードを維持したいんときに、他のエンジニアは通常、これらの文書を読むためのイニシアチブを取ることはありません、文書の完全性は、多くの場合、書類との良好な初期の結果ではないことができますマッチコードの実装は落ちるでしょう。
コードレビューのプロセスは、コードのロジックは、提出者の説明を読んで、コードの実装が記述と一致して確認することです。この時、レビューはドキュメントを読まなければならない、知識の普及が優れている、それは基本的に一人だけが、プロジェクトの状況を理解していないようです。
3、統一されたスタイルは、品質を向上させます
あなたは、コードの品質等級についてのポイントを与える場合、それは次のようになります。
コンパイルすることができます - >正しく機能 - >によって試験することができる - >読みやすい - >維持しやすいです。だから、コードのコードレビューで簡単にこのレベルまで、少なくとも読み取るように。
簡単に限り、コードレビュー、このそれにリンクするだけでなく、関連の仕様がないよう、読み取り、書き込みコードにコーディングスタイルと同じスタイルでその全員の作品なので、プロジェクトをビルドするために達成するために。一方で統一されたスタイルは、我々はプロジェクトを維持するか、それがコードを読み取ることであるかように、プラクティスをコーディング、相互のに適応する必要はありませんが、レビューに加えて、基本的な基盤のコードレビューです。
コードレビューが見つかりました。必要バグではなく、アクセサリー。その上にコードスキャンツールへの低レベルの問題/バグのように、これはコードレビューの義務ではありません。
第二に、コードレビューの着陸の実施を促進するために
図1に示すように、選択したツール
コードレビューツールは、多くのことを行うために使用することができ、ここでは比較的主流のゲリット、GitLabを紹介します
- ヘリット
ヘリットは、 Googleのオープンソースコードレビューツールで、ゲリットはゲリットはゲリット自身の倉庫との同期を行うには、コードの他のGitリポジトリをサポートし、また、内蔵ベースのGitバージョン管理ツールです。操作やアクセス制御のコードレビューはすべて、ゲリットが行われ、独自の倉庫で全てです。
コードレビューのためのヘリットは、ビルドにあるコードレビュー典拠コントロールので、機能は非常に最適です。
ヘリットの開発をサポートするために必須コードレビュー、レビュー、承認コードレビュープロジェクト担当者や権限ごとに異なる設定をサポートするための3つの役割です。
あなたがデータヘリットに基づいていくつかの統計レポートをしたい場合は機能が要件を満たしていない場合は、ゲリットは直接、データベースにアクセスし、それがオープンソースであるため、Javaの開発チームは、独自のカスタムを持つことができます
要するに、関数のゲリット・コードレビューは、欠点は、おそらくUI、相互作用が古すぎると弱い管理プラットフォームである、非常に最適です。
- GitLab家族
GitLabはGitLab.comのみGitHub.comオンラインソースコード管理プラットフォームに2つ目の組み込みGitLabに基づいて構築されたGitのソースコード管理システムです。
GitLabはGitLab CE（コミュニティ版）とGitLab EE（Enterprise Editionの）二つのバージョン、比較的少し弱いが、無料でご利用に、無料の特色にするオープンソースのコミュニティ版を展開し、カスタマイズし、維持するためのポイント。Enterprise Editionは、強力ですが、料金が必要です。
GitLabは、MergeRequestレビューコードによることができるコードレビューを強制的に行うことができ、コミュニティのサポートは、レビュー二つの役割を開発し、Enterprise Editionのサポートは開発、レビュー、承認者3つの役割は、プロジェクト/グループに与えることができます異なる役割（マスター、割り当てられています権限のマージコードを制御するために、開発者）。
あなたがデータGitLabに基づいていくつかの統計レポートを実行する必要がある場合は、GitLabはあなたがカスタマイズしたい場合は、それを制限することなく、プログラミング言語、APIのカスタマイズツールを通じて行うことが推奨され、非常にフレンドリーな安らかなAPIを提供します。
ヘリットコードレビュー機能のGitLabは完全に機能していないが、CI / CDを行うには場合GitLab機能に付属のマニュアル、およびGitLab健全な経営の背景には、より良いゲリットよりであることを、コミュニティ版は、ほぼGitLabための最良の選択であります
- ヘリットVS GitLab包括的な比較
|
ツール |
アクセス制御 |
UI 交互 |
ソース管理 |
メンテナンス性 |
統計 |
支援ツール |
|---|---|---|---|---|---|---|
|
ヘリット |
⭐⭐⭐⭐⭐ |
⭐⭐ |
⭐⭐⭐ |
⭐⭐ |
⭐⭐⭐⭐ |
⭐⭐ |
|
GitLabコミュニティ版 |
⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
|
GitLabエンタープライズ版 |
⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐ |
ヘリットコードレビューの強みは有料で、より包括的、しかしGitLabのEnterprise Edition、GitLabを制御します。だから、すべてで、私はGitLabコミュニティ版をお勧めします
ベースのコードレビューチュートリアルGitLabの：https://ken.io/note/gitlab-code-review-tutorial
2、規範の発展の開発
ノールール、ノー実行。最初のルールの規範の開発です。
仕様の推奨事項が含まれます：
- エンジニアリングの実践（エンジニアリング構造、層化やネーミングなど）
- 命名規則（等インターフェース、クラス、メソッド名、変数名、）
- コードフォーマット（括弧、スペース、ライン、インデント、等）
- ノートの規範（規定必要なコメント）
- ログ仕様（必要な合理的なログ）
- これは、推奨およびコードサンプルのさまざまにはお勧めしません
チームの数が少ない、低プロジェクトの複雑ならば、自分の仕様を開発することができます。結局、チームはベストフィットです。
チームは一定の規模を持ち、かつ拡大していきます場合は、製造業者の仕様に従って開発された、または直接使用することをお勧めします。
Javaの開発マニュアル：https://github.com/alibaba/p3c undefinedGoogleコードスタイルガイド：https://zh-google-styleguide.readthedocs.io（カバー：C ++、Pythonの、など）
3、仕様の開発プロセス
- コードレビューの実施形態では、リンクを決定します
画像
コードレビューの提案は、コードレビュー、テストブランチに提出されるセルフテストコードの開発とコードを完了するために開発されたコードのテスト、前に提出されます。結局のところ、テストはコードレビューによって行われ、その後、必要なコードが変更された場合、テストの作業負荷を増加させ、さらにはプロジェクトのスケジュールに影響を与えるにバインドされている場合。また、またはプロジェクトに対するライン上の圧力、単に「後で」
フィーチャーコードレビューは、ブランチにブランチを開発する際に配置される一般的な用語でGitのワークフロー、。
- 規範的役割行動
|
役割 |
ルール |
|---|---|
|
デベロッパー |
1、提出の機能が送信きめ細かいデフォルト（メソッド/関数の独立した/モジュールユニット）、2完全でなければなりません。粗粒レビューの確認3と通信するために、事前に提出するために、メッセージが必要な変更のテーマの明確な記述であることをコミットし、リンクやファイルなどの文書化要件/設計文書を添付 |
|
レビュー |
1、自己評価が可能と遊んバックの前に開発者に理由を説明する必要はないことでコード2、レビューをマージして、単一のレビューが長い23分の2に下にあるとき、明らかに4を、入力する必要がありますを通じて反撃しない3つの理由レビューに同意しません完全な時間以内に（特別な事情、理由を説明してください） |
|
承認者 |
1は、承認は、非品質問題のリリースのために、1時間未満3に制御への長い必要性を承認、2によるフォローアップを継続する必要性を理由を指定する必要はありません |
このような規範、主に順番に：
- サイズ制御コードレビューは、コードを提出しました
- 控制单次Code Review的时间
- 提升Commit/MergeRequest描述的质量，减少沟通成本
这样，我们就可以通过细粒度高频次的方式尽可能利用工程师碎片化的时间进行Code Review，一定程度上保证Code Review的效率。
毕竟，粗粒度甚至是集中式的Code Review，时间上难以把控。发现了问题的时候，修复的成本也往往更高。
3、分享与统计
有了工具、开发规范、流程规范，就可以指引参与的工程师参与Code Review，那么我们也要对Code Review的过程以及结果进行检验，毕竟不进行检查/验收的规则，是无法达到预期效果的。
Code Review毕竟不是数学题，我们无法通过简单的计算去验证。所以我们要通过侧面验证，来帮助Code Review的执行
- 定期分享
我们是期望CodeReview可以让工程师之间互相学习的，那么对于一次Code Review通常只有参与的2-3个工程师有互相学习的机会，那么在这个过程中学到的知识，定期的分享出来，既可以加强知识的流动，又可以检查大家究竟有没有在Code Review过程中学习到知识，或者有没有认真的进行Code Review
至于分享的内容，可以是开发规范中的范例代码，也可以是规范中的正例代码，也可以是针对某个功能实现的最佳算法/最佳实践，也可以是Code Review过程中的争议代码，也可以是自己踩过的坑。
总之，Code Review之后的代码分享，不但可以加强知识的流动，还可以检验Code Review的效果。
- 数据统计
为了在一定程度上保证Code Review的效率，我们在规范里是要求参与的工程师：
- Developer控制提交Code Review的粒度，或者控制每个Commit的粒度
- Developer要准确清晰的描述所提交的代码
- Reviewer&Approver要在规定时间内完成Code Review
这些情况纯粹靠人工是无法检验的，还是需要有一定的数据统计。
如果用Gerrit，可以查询Gerrit的数据库，里面会有Code Review的信息，
如果用GitLab，可以通过WebHook或者restful API获取Code Review信息
我们可以做成报表，来展示Code Review的情况：
- 每人每周Code Review所消耗的时间
- 每人每周被Code Review所消耗的平均时间
- 超过规定时间的Code Review情况
- 代码提交描述字数过少的情况
- 等等（根据自己的需要来）
以上情况只是Code Review的侧面反馈，用来帮我们发现Code Review执行过程中可能出现的问题。不过，出现问题并不意味着Code Review的质量/效率一定受到了影响。
比如，工程师A被Code Review的耗时是团队内最高，有可能是有某次代码是周五晚上提交的CodeReviw，这单次CodeReview的耗时就会超过48小时。也有可能是对应的Reviewer是团队新人，要通过相关业务项目了解对应Project的承担的职责及代码，这是个学习的过程，自然耗时加长。
又比如工程师B提交的代码描述文字过少，可能就是中间件团队对某些基础组件进行升级，或者安全团队要求升级某个依赖的开源组件，以修复某个安全漏洞。
但是通过这种的数据，可以让Code Review的情况直观的展示出来。来发现大家执行过程中需要优化的事项， 不断帮助大家完善规则，做好执行。
三、保证Code Review质量的关键
1、工程师对研发规范的认真学习
无论Code Review的工具以及流程是怎么样的，都少不了开发规范作为支撑，毕竟我们期望Code Review达到的效果之一就是，团队中的工程师可以写出像规范中描述那样的高质量代码。
工程师对研发规范的掌握程度，决定了自己编码代码的质量，也决定了自己Review通过的代码的质量。所以，无论如何，加强对研发规范的学习和理解，都是保证Code Review质量的重中之重
2、资深工程师的认真对待
Code Review目的是帮助工程师交流和学习进步的。无论是技术能力还是编码习惯，亦或是业务知识。无论规则怎么制定，终究还是需要参与的工程师来执行，如果大家互相睁一只眼闭一只眼，互相降低要求，那么执行的效果一定会打折扣。
虽说三人行必有我师，但收益最大的一定是经验(技能/业务知识)尚浅的工程师，收益最低的一定是团队中最资深的工程师。而恰恰经验尚浅的工程师的收益大部分都要来自资深工程师的付出。
所以，一定要跟资深工程师最好沟通，让他们严格要求，不能对经验尚浅的工程师放水，以帮助他们提升编码能力以及业务知识。
这也可以减少甚至避免他们为经验尚浅的工程师的代码“善后”。
四、备注
附录
- Java开发手册：https://github.com/alibaba/p3c
- 基于GitLab的CodeReview教程：https://ken.io/note/gitlab-code-review-tutorial
- Google代码风格指南：https://zh-google-styleguide.readthedocs.io
- Jenkins+Sonar执行代码扫描：https://ken.io/note/jenkins-maven-java-sonar-integration
本文首发于我的个人博客：https://ken.io/note/how-to-do-code-review-in-a-team