コードレビューとは何ですか
ソフトウェアのソースコードの体系的検査では、ソフトウェアのソースコードの品質問題、構造、および他の脆弱性を見つけます。
PS：コードレビュー≈コード査察≥コードウォークスルー（コードレビュー）
コードは同等の非公式のコードレビューをウォークスルー。
コードレビューを実行する方法
1.コードの静的解析ツールを使用してください。
コードの静的解析ツールは、独自のコードレビューコードを補完します。
ESlint例に。
このプロセスは：（1）ESlintキットを搭載しました。
（2）開発チームのリーダーと共同開発しESlint設定ファイルのメンバーとこのファイルを共有します。
併用ESlintプロファイルの確定（3）ESlintプロファイル、チームリーダーおよびメンバーの後、本明細書のコードに厳密に従っています。
PS：コード静的解析ツールは、開発者がコードレビューの効率を向上させるためにコードレビュープロジェクトの相互検査の開発に必要なチームメンバーを減らすためにネイティブのエンコーディングで、コードの予備的な見直しを行うのに役立ちます。
2.バージョン管理（クロスチェック）。
軽量なコードレビューツールに付属しているバージョン管理ツールを使用して、コストと学習の効率を考えると最良の選択です。
リクエストGitHubの例をプルします。
プロセス：（1）GitHubの上で良いmatserメインブランチを作成し、複数の分岐、複数の特徴サブブランチを備えています。リーダーのMatserメインブランチ、読み書き可能な機能のサブブランチを書き込み可能な読み出し専用のブランチをしませ備えています。（一般的にコードレビューMatser、機能ブランチのメインブランチは、機能コードは、子枝を検討する必要がありません）
（2）各部材のヘッド装置を作動符号化モジュールは、各部材は、次に、プル要求機能サブブランチを押し、符号化、およびコードを送信しています。
（3）チームリーダーやメンバーが提出されたソースコードの軽量コードレビュー機能サブブランチこと。
ソース（4）チームリーダーやメンバーのサブブランチが疑わしい行動のコードレビューを提出した特色、および既知の問題を解決するためにソースコードを変更する機能の枝の責任あるメンバーに助言します。
（5）チームリーダーやメンバーがコードレビューを通じて提出機能のサブブランチのソースを確認した後に、機能ブランチにサブブランチを担当するチームリーダーを備えています。
（6）次に、それぞれの符号化ブランチ補完機能、及び主枝Matserにマージします。
（7）パブリッシングソフトウェアの前に、正式なコードレビューを実施します。（このプロセスは、場合に応じて参照するに痛い、あまりにも多くのコードです。）
PS：コードレビューは、次の3点に注意してください。
（1）コードレビューではなく、ブラウザのコードです。（漢字で書かれた本のコピーで働く元小学校の先生を思い出す「読みを。」）
（2）部品コードは、審査のない多くのことを検討します。（専門家の大半は、実際の状況に合わせて、言っています。）
（3）コードが相互検査はなく、1つのチェックすることができます。（3行は私の先生、でもセージ孔子ことなく、謙虚に他の誰かに頼む必要があります。）
（4）行動詳細なコメント、質問やフィードバックの最適化の推奨のコードを疑問視しています。（常に行う方法を他の人に伝えるために行われていない間違っを選択しないでください、必ずしもすべての非常にスマートな、1は理解するであろう、それは推奨は言う最適化することが推奨されます。）
PS：提案されたプロジェクトの機能モジュールの軽量非公式のコードレビューが完了した後、または開発の効率に影響する可能性があるが、開発者は、フォーカスされていない開発作業を考えて中断しました。
コードレビュープロジェクト
プロジェクトが決定する復興プロジェクトを、検討することであるので、私のブログでの後期のポイントは、サプリメント「リファクタリングを探る」します。。。
長所と短所のコードレビュー
利点：コード品質を改善し、チームのコミュニケーションや知識の共有を促進し、コードの潜在的な脆弱性を識別します。
短所：関係に影響を与え、作業負荷を増加させました。
要約：コードレビューは、良い方法ですが、必ずしもすべての開発チームとソフトウェア製品のため。
短いライフサイクルソフトウェアプロジェクトや開発チームの経験不足は、コードレビューのために推奨されません。
コードレビューはかろうじて満足していない、推奨を推奨します。