諺に通り、愛は、憎しみに理由はありません、もちろん、コードレビューに理由もなく！
まず、目的
- 一貫性のあるコーディングスタイルのチームを確認してください
- 他人を与えるために独自のコードは、コード潜在意識の規制、および論理的な厳密さに注意を払うために、開発プロセスの必要性を参照してください。
- 潜在的なリスクを息苦しい、プロジェクトの品質を確保
- 彼らは、セルフテストの完了後に機能しますが、しかし必然的に境界点の一部を残し、またはいくつかの点限界で考えることもできます。
- 相互強化
- その他には、コードを学ぶマスターは厳格な、シンプルでエレガントなコードを書くと、そのかすに、自分のコントロール、Quqiエッセンスを作る方法です参照してください！
- 便利なクロスメンテナンス
- クロスコードレビューのプロセスを通じて、ポストクロスを始めるために多くの時間を費やすことなく、維持促進するために、さまざまなサービスについて学びます。
第二に、どのように実行しますか
- ペア
- グループとしては、2人以上で
- そして、オンラインレビュープロセス
- すべての項目のマスターが保護に設定され、セットはブランチの展開としてマージチェックは、すべての議論のために解決しなければならない設定はありません1、、のためのブランチをプッシュする許可されています
- あなたは開発のdevのブランチを作成し、同じことが、誰のためにプッシュすることができ、マージチェックがすべてのディスカッション、支店などの開発ブランチのために解決しなければならないセット保護に設定されている場合
- コメントが解決された後のdevのブランチにマージリクエストを入れて、自分の名前で個人最高の支店、必要な見直しコードは、コードレビューの人々は、この時点で（なし疑問符まで、非準拠のコード編集コメント、コードのコードを確認しますブランチ）は、マージが可能になります
- ライン後の試験問題ありません後のdevの枝、MRは、プロジェクトを完了するために、実際にラインに今、masterブランチを言及します
- 集合的な
- 集団週は週コードを確認しますが、コアコードのすべてのレビューは、コードをまとめて週に3人の学生を検討することが期待されます。
- 好ましくは、複雑なビジネスのフローチャートで、自分自身のモジュールを説明します
- Gitのフック - 事前にコミット
- すべてのGitはコミット統一コーディング標準検出ツールとしてESLintを使用して、新しいプロジェクトが、提出するだけ準拠したために、コードに準拠するかどうかを決定します
第三に、セルフテストチェックリスト
セルフテスト機能の前に言った後に完了していることを、しかし定義されていないものと正確なカットが、あなたはおそらく次の側面からカットすることができます：
- ルーチン検査
- 場合は、コードを実行することができますか？
- コンソールかどうかの重要なエラーが発生しましたか？
- コードは、需要の所望の効果を達成していませんか？
- コードのロジックは、理解しやすいのですか？コードは、コンプライアンスのために書かれましたか？の構成要素としてどうか？
- ホイールを作成する何の重複はありませんか？
- コードのコメントの大部分を削除しますか？（コメントコードが利用可能である場合、それはGitのに削除コメントコードを提出することはないだろうし、それにロールバックできるようにするには、コメントに提出されたコードを削除します）
- 排泄のライフサイクルでのタイマーかどうか？単一のボタンをクリックするかどうかを制御しますか？
- セキュリティーチェック
- 他人の導入（内部または他の外部機関）の依存関係、リスクは利用できず、アップグレード機能が存在する有力利用できませんか？
- 画像リンク、アプリページに埋め込まれたアプリケーションを含む、HTTPSを使用して、すべての要求は、HTTPSプロトコルのリンクを提供するかどうか、いますか？
- コードは、コメント、またはコピーに敏感な言葉を含めるかどうか？
- ドキュメント検査
- 準拠した注釈はありますか？正確な記述かどうかの注意事項？メソッドのパラメータまたは用語が説明されているかどうか？
- サードパーティ製のライブラリは、サウンドファイルを使用していますか？
- このReadme文書は、仕様が書かれていますか？プロジェクトの正確な記述はありますか？
- パフォーマンスチェック
- ページのロードが3秒を超えた？以上3Sの理由は何ですか？何優しいヒントはありませんか？
- コードは、ロジックと演算性能に大きな影響を及ぼしませんか？
- コンポーネントレベルの制御？通信のコンポーネントは正常ですか？シンプルなネストされたページかどうか？
第四に、採点基準
30点、24点以上のマスターコードをマージする許可されているスコア、最適化後24未満MRの言及が必要です。
- 需要
- 9-10：明確な構造を投影し、合理的なアセンブリコードのロジック厳格な、徹底的な機能
- 6-8ポイント：無論理的誤り、漏れのない機能
- 0-5：コード論理エラー、不作為機能
- コード
- 9-10点：コードが簡単かつ合理的なコメントは、独立したモジュール
- 6-8：適度な結合モジュール、コードは比較的簡単です
-0-5ポイント：高い結合モジュール、コードのコメントは、コードの書き込み複雑な、非標準の命名明確ではありません
- 可読性
- 9-10：厳格なコードの仕様は、コードのロジックは、明確な注意事項を理解しやすいです
- 6-8：ロジックコードは失読症、漠然としたコメントは存在します
- 0-5：混沌の複雑なロジックのコードは、非常にクラッシュ理解します