コードレビューチェックリスト✅

もちろん、ホールを歩いている間、我々はコードをチェックしません.はい、これはステージです.あのカップにはコーヒーさえありません.
コードレビューは、オンボードのチームメンバーのための最も効果的な教育ツール、新しい開発者を驚かせ、製品や技術の専門家になることです.
しかし、あなたがそれを通して微風をするならば、それは効果的でありません.
コードレビューは、あなたがおそらく快適であるよりも長い時間の良い量を取る必要があります.評論家は、何が変化しているのか、なぜ、どのように解決されたかを理解すべきです.一旦これらが理解されるならば、校閲者は効果的に仕事を批評することができます.
私のチームでは、速度以上の品質を優先します.皮肉にも、我々はしばしば速度を優先させるチームより速く届けることを終えます — とバグが大幅に少ない.

Code Review takes a significant amount of time invested up front, but it creates a shared knowledge that eliminates tons of basic mistakes down the line. Ultimately this saves tons of time and effort for everyone.

以下はこれらのチームのコードチェックリストです.

✅ 元の問題を理解する

機能、バグ、または強化が、なぜ我々が最初にこの仕事をしているかを理解するかどうか.

仕事のチケットをレビューして、要件を理解する

更なる説明が必要なら、開発者か記者に話をする

質問に答えてください:「この仕事が解決する問題は何ですか?」

✅ ローカル問題を複製する

git pull develop
npm start

PRが分岐した枝を取り、物理的に問題を起こすのを見てください.
あなたが問題が何であるかについて見ることができるとき、あなたはより効果的に適切な解決を診断することができます.

✅ 必要な修正または機能を理解する

あなたがこれまでに見たことに基づいて、あなたはどんな解決策を決定するでしょうか?いくつかのオプションを考えてみてください.

この問題を解決するためにコードのどの領域が必要か?

UXの観点から、要件を実際に問題を解決する最良の方法で提案されたソリューションですか?

✅ PRを直接調べる( devのアプローチを理解し、構文エラーをチェックする)

今、我々はコードを見始めます.リポジトリ(github、bitbucketなど)のコードの差分を確認してください.これは、“前と後”何が変更されているのを見る最も簡単な方法であり、作品の主要な作品です.

全体的なアプローチは良いものですか?それは複雑すぎるか?それはコードの適切な領域で働いていますか?

もしそうならば、基本的な間違いがありますか?構文エラー、不完全に名前を付けられたか誤字変数、外来コメント、書式設定問題、またはタイポ?

最も重要なのは、このコードがどのように機能するかについてのすべてを理解していますか?あなたが理解していない何かがある場合は、コメントを明確化を求める追加する必要があります!これはいずれかの開発者はあなたに新しいツールを教えるか、またはb)彼らは彼らのコードが明確ではないと認識し、クリーンである必要があるのを助ける.

✅ PRブランチでローカルで遊ぶ

# on root branch
git pull
git checkout the-pr-branch
npm start

コードをプルダウンし、アクションのソリューションを参照してくださいどのように作品が一緒にリンクされている方法と相互作用のコードで動作を探る.

もう一度機能を壊してみてください.

いくつかのコードを変更し、どのように物事を変更を参照してください.

クリーンアップを必要とするコンソールやIDEにエラーが残っているかどうかを確認してください

これらは、コードが期待通りに動作することを確認するためのすべてのステップです.

✅ ユニットテストが効果的にすべての相互作用をテストしているかどうかを確認する

すべてのCodeBaseは単体テストを行うべきであり、それらのテストはすべての関数が「通常の」入力と「異常な」入力の両方で期待通りに動作していることをチェックするべきです.
実際にテストしていると思うすべてのテストですか?コードカバレッジツールJest or SonarQube あなたが本当にすべてをテストしている場合は実装しやすく、あなたを伝えることができます — 私は個人的に80 %のカバレッジレベルが好きです.
それぞれのテストについて

出力が正しい値であるかどうかを調べます.関数が不正な値を優雅に扱います.

関数の内部のすべてのロジックが有効にテストされていることを確認します.何か機能の中でテストするのは難しいですか?それはおそらく別々の機能に引き出されて、別々にテストされる必要があります.

すべての単体テストが通過していることを確認し、テストスイートで奇数/不要エラーをスローしない.

コードカバレッジレベルが設定したカバレッジしきい値を下回っていないことを確認します.それがあるならば、レポートが弱い報道を特定するより多くの/より良いテストを加えてください.

✅ あなたがフィードバックを与えたとき、変更が押されるとき、もう一度それをしてください

あなたは1つのPRを見直しました、そして、それは多分しばらくかかりました.グッド!しかし、それはここで終わりません.
開発者が新しいコミットをプッシュするときにあなたや他の(修正と改善)のフィードバックに対処するには、戻って、もう一度テストする必要があります.小さなものが変更されると、それはアプリケーションの他の分野に大きな影響を与えることができます.チェックリストをもう一度実行します.

The code in a PR should always be considered “ready for production”, never accept “I can fix that later”. It should always be reviewed expecting a high quality of delivery.

🤔 結論

このプロセスはしばらくかかり、意図的に集中している.それは良いことだ!
次の手順に従います.

バグが少なくなる

開発者は製品についてより深く理解し、それをより速く学ぶ

“再レビュー”の量を減らす — 効果的に行う — DEVSは、他のPRSの互いの間違いから学びます.これは劇的にPRSは“レビューで過ごす時間をスピードアップ”

チームは一定の改善とピアメンターシップの文化を開発する

それらは最終的にすべてのソフトウェア開発チームのゴールです.したがって、場所でより良いPRレビュー練習を入れて、最初の重い荷を受け入れて、劇的に改善するあなたのチームの品質を見てください!
ポールはエンジニアリングマネージャーですSkookum , 元UI/UXデザイナー、コロラド州のスノーボーダーとゴルファー、そして明らかにdev blogger . 私についてきてください.Github , またはどこでも深い雪を見つけることができます.
必要な製品やチームを構築するヘルプ?私はyaとチャットします.