コードレビューはしばしば認知的に重く、非決定主義的に感じる:それに従う道が多すぎる、曖昧さが多すぎる、意見が多すぎる。 しかし、レビューの価値を最大限に高める方法は、レビュー者を枯渇させたり、チームを無限の議論に閉じ込めたりすることなくできますか? 私は健康的で持続可能なレビュープロセスを略称に分類しました: ビジネスロジックやエッジケースから信頼性や読み取りに至るまで、真に重要なことを優先する一方で、主観的な意見をコントロールする方法はこちらです。 PERFECT コードレビューとは? コードレビューは、コードが定義された要件を満たしているかを確認するプロセスであり、別の開発者、著者自身、または自動ツールの助けを借りて行うことができます。 これらの要件は、ビジネスまたは技術的なニーズによって定義されます。製品またはカスタムソフトウェア開発では、常に最終的にビジネス目標によって駆動されます。そのような要件には、コードの品質、重要な問題の予防、より速い開発サイクル、チームの成長、その他の要因が含まれます。 たとえば、完全にクリーンなコードを書く開発者の個人的な欲求は、単独では、コードレビューの正当な理由ではありませんが、クリーンなコードが生産バグを減らし、ソフトウェアの全体的な品質を向上させたり、チームの動機づけと維持可能性に良い影響を与えることが示された場合、クリーンなコードは個人的な好みよりもビジネス上の必要性に変わります。 コードレビューは本当に必要ですか? コードレビューは、開発者の作業時間の20～30%までかかることがありますので、コードのレビューとレビューを待つ両方を含め、このコストはより構造化されたコードレビュープロセスを導入することで削減できます。 理想的には、コードレビューに費やした時間と努力とそれが提供するビジネス価値の間の妥協を分析し、優先的にメトリクスを用いて、結果として得られた改善がそのコストを正当化するかどうかを決定する必要があります。 短い答えは、ほぼいつも たとえ軽いが構造化されたレビューでさえ、通常は費用が少なく、重要な価値を提供するので、ほとんどのプロジェクトで使用するのが合理的であるが、もしコードレビューが「貨物のカルト」に変わる場合、レビューが公式に存在する場合、承認は実際の議論なしに起こり、実際の問題は回避されない場合、あなたは単にこの形でピアツーピアレビューを必要としない。 yes コードレビュープロセスがコミュニケーションの問題を暴露するか、配信を大幅に遅らせる場合、チームはそれを完全に放棄する誘惑を受ける可能性がありますが、これは短期的な緩和をもたらす可能性がありますが、長期的な結果は通常陰性です。 完璧なコードレビューの原則 これらの原則は、すべての重要な側面をカバーする理想的なコードレビュープロセスを説明します。それらは一般的で標準化されたアプローチを表し、特定のプロジェクトの文脈に適応することができます。 覚えやすくするために、私はアクリムを使用します。 それぞれの文字が原則の最初の文字に匹敵する。 PERFECT   重要な: レビュー家は常に、彼らがコードの一部を嫌っているだけで、それはコードが悪いという意味ではありませんということを覚えておくべきです。 あなたがコメントする何かを持っている場合は、何が間違っているか、そしてなぜ、具体的な議論であなたのフィードバックをサポートし、少なくとも高いレベルで代替案を提案してください。 重要な: 1.目的 ✔️ Code solves the task. コードが任意のタスクを解決しない場合、それは価値を持たず、おそらくまったく合併すべきではありません。 レビュー者にとって、最初のステップは、タスクが何であるか、そしてコードが何を生成するかを理解することです。 タスクがクリアしたら、レビュー者はコードが実際に解決していることを確認する必要があります. 有用なテクニックは、解決策にどのようにアプローチし、実装されたコードと比較するかを概ね述べることです. いずれにしても、問題と解決策の両方が明確に理解されなければなりません. これがなければ、レビューの値はゼロに近づきます. コードがどれほどクリーンか、読みやすいかに関係なく、意図されたタスクを解決しないと意味がありません。 2.エッジケース ✔️ Edge cases are handled. ビジネスと技術の両方のコーナーケースを識別し、コードが正しく処理していることを確認してください。これには、予期せぬ入力、異常な計算結果、要求または条件の省略、限界値、タイプ制限、無効性などが含まれます。 生産バグの大部分は、見落とされたエッジケースによって引き起こされ、少なくとも別の人がそれらのいくつかを特定する場合、生産問題の可能性は劇的に減少することができます。 注目すべきエッジケースの興味深いタイプの1つは「不可能なケース」であるが、これらは本質的に危険であるが、コードの現在の状態では到達できないように見える状況である。例えば、オプションから値にアクセスするか、あるいはその存在を明示的にチェックすることなくタイプする。これはコードの現在の状態で安全であるかもしれないが、将来の変化、特に既存の仮定の完全な認識なしで行われた変化がこの論理にどのように影響を与えるかを予測するのはしばしば困難である。実践では、そのようなケースは蓄積する傾向がある。単一のインスタンスが問題を引き起こさない一方で、それらのより大きな数は全体的なリスクを大幅に増加させる。良い実践は、言語機能を意図したように使用 3.信頼性 ✔️ Code does not have performance and security issues. ビジネス関連のプロジェクトやミッションの重要なプロジェクトには、性能とセキュリティの厳格な要件が必要です。プロジェクトがお金や人間の安全に直接関連していない場合でも、プロジェクトがどのように再利用されるか、他のシステムに統合されるか、あるいは時間の経過とともに進化するかを予測することはしばしば困難です。このため、コードが少なくとも基本的なパフォーマンスとセキュリティの期待を満たしているかを常に確認するのが良いです。 信頼性の観点から、コードレビューは、通常、エラー、不安全な行動、またはパフォーマンスの低下が最も発生する可能性のある領域に焦点を当てます。これには、時間とメモリの複雑さ(期待されるデータ量、実行時間、メモリの使用に適した)、入力と出力の検証、認証ストレージ、破損した統合、キャッシュの無効化、および類似の懸念が含まれます。 4.形式 ✔️ Code aligns with design principles. この調節は、コードの表示を標準化し、他の開発者と将来の原作者の両方にとって読みやすく理解するのに役立ちます その結果、新しい変更、デバッグ、長期的なメンテナンスのコストが大幅に削減されます。 ビジネスの正確さ、パフォーマンス、またはセキュリティとは異なり、デザインの質問はより主観的である傾向があります。このため、明確な議論と共有された合意は、レビュー中に非建設的な議論や紛争を最小限に抑えるために不可欠です。 SOLID、KISS、DRYなど、適用可能な多くの既知の原則があります。それらのうちのいくつかは主観的であり、他はより具体的な基準とガイドラインを提供します。しかし、具体的な原則に関係なく、ほとんどのデザインの議論は結局、一貫性と結合を管理することに終わります。 あなたのプロジェクトの文脈で、その他の設計原則をこのコアアイデアの例や具体的な解釈として扱います。 High Cohesion / Low Coupling 5.証拠 ✔️ Tests and CI pipelines pass. テストにより、デバッグ、リファクタリング、および新しい変更の導入が容易になり、生産バグの数を減らし、全体的な安定性を向上させます。 もしテスト、ビルドパイプライン、またはその他の自動化されたチェックが存在する場合、それらは通過しなければなりません。そうでなければ、破損したパイプラインの修正は、コードの再レビューを必要とする重大な変更を導入する可能性があるため、コードの全体のレビューが価値を失う可能性があります。さらに、テストまたはパイプラインが永久に破損または無視されている場合、それは通常、これらのパイプラインがもはや積極的に使用されていない、時代遅れの行動を含んでおり、利益よりも混乱を引き起こす可能性があります。 書面テストの周りに合意が成立した場合、変更はテストによって適切にカバーされるべきである。これらのテストはまた、生産コードと同じ原則を用いて見直す必要がある。 少なくとも、それらは意図された論理を検証し、合意された構造と規約に従い、受け入れられるパフォーマンスを持たなければならない。 理想的には、生産コードはテストのみのために書かれた特別な論理を含まないべきである。 6. 明確性 ✔️ Code clearly communicates its intent. さまざまな人々は、コードを読む方法と理解方法、背景、経験レベルが異なります。結果として、コードの明確さはしばしば主観的であり、誰もが同様に理解しやすいコードを書くことは困難です。それでも、私たちはコードの意図をできるだけ明確にするよう努めなければなりません。理想的には、コードはすべての行を読み取ることなく理解可能でなければなりません - それは直線で読み取ることが可能でなければなりません。 明確な合意はここで役立ちます. They can include conventions for naming, file structure (a good criterion is the ability to find things without searching), block length, nesting, statement order, documentation, use of comments, and others. これらは、名前付けのための合意、ファイル構造(良い基準は、検索することなく物件を見つける能力)、ブロック長さ、巣立つこと、声明の順序、文書、コメントの使用などが含まれます。 客観的な基準が合意されず、コードが明示的に不明確である場合、私は、個人的にいくつかの選択に同意しない場合でも、これらの決定を著者に残すことを好む。 7位 味 ✔️ Personal preferences are noted but do not block changes. それぞれのレビュー者は、独自の開発習慣と個人的な好みをもたらします。チームが書かれたレビューの合意を減らすほど、意見の高いレビューコメントが表示される傾向があります。そのようなコメントはレビュープロセスを遅らせ、不要な摩擦を生み出し、最終的にコードの不一致につながります。 同時に、これらのコメントの多くはまだ意味を持っており、実際の問題を指摘することができます。それらは完全に無視されるべきではありません。しかし、明確な期待を定めることは重要です:レビュー者のコメントが明確な推論と建設的な提案によって支持されていない場合、著者はそれに取り組まないことを選択することができます。貴重な意見は後で再検討され、共有合意に変えられます。何かが合意となると、それは完全に客観的でなければなりません - それは単にチームの機能の一部になります。 実際に働く方法 How to Make It Actually Work 適切なコードレビューの原則を知り、一貫してそれらに従うことは非常に異なることであるが、すべてのチームに効く普遍的なレシピはないが、いくつかの基本的で効果的な勧告を提供することができる。 主な目標は、コードレビューを開発者から過剰なリソースを排出する認識的に要求的な活動ではなく、明確でルーチンなプロセスにすることです。 
 
 
 
 
 
 
 
 
 
 
 Establish written review conventions. These should include the principles described above, their concrete implementation in the context of your project, and any other aspects you want reviewers to pay attention to. 
 
 
 Keep conventions up to date and actionable. All criteria should be usable during review at any moment. Whenever you notice a recurring review pattern (comment → discussion → fix), turn it into a convention. 
 
 
 Require self-review before peer review. Everyone should perform self-review using the same conventions before sending code for review by others. This saves time for all participants and helps reviewers build experience and efficiency over time. 
 
 
 Integrate code review into the development process. Define clear rules for selecting reviewers, the number of reviewers, how comments are written and resolved, how updates are communicated, approval rules, review status visibility, and review SLAs. There should be a clear answer to common questions around code review, instead of uncertainty, anxiety, and unnecessary stress. 
 
 Automate everything that can be automated. 
 
 
 Stop approving with "LGTM". "LGTM" (Looks Good To Me) often signals that the reviewer did not fully understand the changes and simply wants to move on. While reviewers are not responsible for the final outcome of approved code, such approvals reduce the value of the review itself. 
 
 
 Practice code review whenever possible. Code review is a skill that improves through deliberate practice. The more experience reviewers gain, the less effort reviews require and the more effective they become. This can be supported through attention to structure, constructive feedback, short workshops, and other focused practices. 本当に全ての原則が必要なのか? これらの原則をすべて実践的に使用するつもりはないとしても、それらを理解することはまだ有用です。それらは、技術的なビジョンを形成し、知的議論をサポートし、異なるアプローチが意味があるときに明確にすることによって、コードレビュープロセスに構造をもたらすのに役立ちます。 前述したように、コードレビューは単一のテクニックではなく、実践の範囲です。上記の原則は、一般的にコードレビューの利点を最大化するのに役立ちます。しかし、特定のプロジェクトでは、いくつかのアプローチは、それらが提供する価値よりも多くの努力を必要とする場合があります。

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

More About Me

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

忙しいチームのための持続可能なコードレビュープロセス(PERFECT)

About Author

コメント

ラベル

この記事は

Related Stories

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

ユニークなエコシステムを支えるビットコインUTXOのモデル

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

ユニークなエコシステムを支えるビットコインUTXOのモデル

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps