PHPマスター|コードレビューの重要性

キーテイクアウト

• コードレビューは、初期開発段階で見落とされている間違いを見つけて修正することを目的としたコンピューターソースコードの体系的な調査であり、全体的なソフトウェアの品質と開発者のスキルを向上させることを目的としています。ペアプログラミング、非公式のウォークスルー、正式な検査など、さまざまな形式で行うことができます。 コードレビューは、コードの欠陥の数を減らすだけでなく、コラボレーションを増やし、チームの構築を支援し、開発者の「兄弟愛」を改善し、チームまたは部門全体でベストプラクティスとスキルの改善を伝播します。
コードレビューのベストプラクティスには、一般的な間違いを知り、積極的に戦うこと、平等またはより大きなスキルのある人によるコードレビュー、明確なマイルストーンのあるコードのレビュー、メトリックの収集、バグを見つけることが良い社会的側面に留意することが含まれます。 、悪くない。
この記事は、コードレビューをネガティブまたは時間の無駄と見なさないことの重要性を強調していますが、日常のワークフローの改善として強調されています。あなたのチームが今日それを使用していない場合、それを提案してください、あらゆる種類のコードレビューはなしよりも優れているので、それを提案します。

すべての開発者は、平凡な間違いの痛みを知っています。ここでの間違った属性、そこにあるスペルのあるプロパティ、誤って複製されたコードラインが、あなたがいた16時間のハッカソンのために見逃したコードの行です。誤ってそこに置いたオープニングPHPタグの前にシンプルな$でさえも、Infernal JavaベースのIDEがウォームアップして再配置する前に入力を始めたために誤ってそこに置いた$でさえ、疲れて気を散らされている場合は何時間も頭を掻きます。 。あなたがあなたがしたことを見るために新鮮な目を持っていたら、確かにこれらの間違いは簡単に避けることができますか？ ウィキペディアは次のようにコードレビューを定義しています。

コードレビューは、コンピューターソースコードの体系的な試験（多くの場合、ピアレビューとして知られています）です。これは、初期開発段階で見落とされている間違いを見つけて修正することを目的としており、ソフトウェアの全体的な品質と開発者のスキルの両方を改善することを目的としています。レビューは、ペアプログラミング、非公式のウォークスルー、正式な検査などのさまざまな形式で行われます。 この定義は得られるのと同じくらい正確です。さらに多くのレイマンの用語では、コードレビューとは、他の誰かにコードを見て、見逃した間違いを見つけるという行為です。

コードレビューの種類

ウィキペディアの定義が示唆するように、欠陥のコードを確認するにはさまざまな方法があります。それらのいくつかの簡単な破壊です：

OTS（肩越しの）レビュー - これは、小さなチームが通常コードレビューを処理する方法です。開発者は、かなりの量のコードを書き、別の開発者に電話してそれを見てみましょう。他の開発者はそこに座っていますが、最初の開発者は彼が何をしたかをラインごとに説明します。この物語を通して、元の開発者は彼自身の間違いのいくつかに気づき、それらを修正し、OTS開発者は他の人に気づき、それらを最初に指摘します。また、特定の問題に対する解決策に関する意見を共有しています。これは、レビュープロセスが完了した後に元の開発者が時々やり直すことがあり、もう一度レビューを求めます。これは、開発者がリモートである場合、スクリーン共有ソフトウェアと音声チャットで簡単に実行できます。
• ツールアシストレビュー - コードレビューを支援するために、オンラインとオフラインの両方のさまざまなツールがあります。提供されているさまざまなツールの詳細な見方はこの記事の範囲外ですが、有料バージョン（Atlassian Crucible、CodeCollaborator）、無料バージョン（レビューボード）、またはソロ開発者の場合、The The The The The The The The The The The The The The The The The The The The The The Scoperizeと言うことができます。コミュニティバージョン（スタック交換コードレビュー）。使用されているツールに関係なく、それぞれがほぼ同じ目的を果たします。ソースコードの最新の変更を取得し、レビューが必要であるとフラグを立てます。ピア - それは平等またはより大きなスキルの開発者を意味し、コードをレビューし、レビューされたとフラグを立てたり、発見されたエラーを提案したり、提案をしたり、プロセスを終了したり、元の開発者に送り返したりすることでプロセスを終了または再現します。また、多くの人気のあるIDがコードレビュープラグインを持っていることに注意することも重要です。
ペアプログラミング - 非常にダイナミックなタイプのコードレビューであるペアプログラミングは、2人の開発者にとってホットシートの「ゲーム」です。数百行のコードの後、または所定のマイルストーンに達した後、彼らは短い休憩を取り、場所を切り替えます。今ではコーディングしていた人は、以前に観察された人がコードしている間に観察しています。これは、バグを回避し、全体的なコードの品質を改善するのに非常に効果的ですが、人材の2倍の費用がかかります。多くの企業はそのようなリスクの準備ができておらず、残念ながら「2つのマシンの2人の人が1つのマシンで2人以上の作業を行っている」以外に考えることができません。最良の結果をもたらすのはまさにこのタイプのレビューです。バグは完全に回避されるだけでなく、2人の開発者が直接協力して、進行中に遭遇する問題の解決策に関するアイデアを共有します。また、このタイプのレビューが慣れていないチームで実装するのが非常に難しいことも何の価値もありません。それは主に若いチームで機能します。

余談ですが、1970年代にマイケル・ファガンによって最初に導入され、研究された正式なタイプのレビューもあります（この方法はファガン検査としても知られています）。正式な検査は、小さなチームではめったに使用されず、非常に精神的に強烈で高価なため、ほとんど数百万ドルの製品に関連しています。プロジェクターと一緒に座って一緒にコードをレビューする数人（最大6人）が含まれます。各参加者には役割（読者、モデレーター、レビュー担当者など）が割り当てられ、チームがあらゆる種類のバグまたは欠陥に気付いた場合、すべてが重大度、実際のコードライン、原因、原因まで、すべてが詳細に詳述されています。効果、このバグの予測コストでさえ、顧客に届きます。これは、最も専門的なタイプのコードレビューですが、開発者にとって最も落胆するものであり、そのため、広く採用されていません。研究では、他のコードレビューの方法が、多くの人々を長い間結び付ける必要なく、正しく使用する場合と同じように効果的であることが示されています。 コードレビューのベストプラクティス

コードレビューを実装することが決定されると、おそらく克服すべきハードルがいくつかあります。経営陣は、余分な時間のレビューがかかる正当化を見ないかもしれませんし、一部のプログラマーは、レビューが作成するために一生懸命働いたコードに対する個人的な攻撃であると考えるかもしれません。コードレビューが実装されているときに留意するために、いくつかのヒントを紹介します。

1. あなたのよくある間違いを知って、積極的に彼らと戦ってください。作業するとき、すべての開発者は、彼がどんなに深く「ゾーン」であっても、一般的にエラーを持っています。私たち一人一人がこの小さな不具合を持っています。これらのスリップアップに注意してください。入力をフィルタリングするのを忘れました…もう一度？方法をコメントするのを忘れました…もう一度？そのようなリストを使用すると、開発者はレビューを求める前に積極的にこれらの間違いを追い詰めることができます。これはエゴ効果として知られています。あなたのコードがレビューされようとしていることを知っています。レビュアーが「ああ、再び入力をフィルタリングするのを忘れていました！」と言っているのを聞きたくありません。あなたはロックスター、忍者、他の人に「すごい、それは実際には素晴らしい解決策だ」と言う人になりたいです。エゴ効果は、他の人がそれを見る機会さえある前に、あなたのコードを改善するためにあなたを駆り立てるものです。
2. ピアコードレビューとは、平等またはそれ以上のスキルのある人によってレビューされることを意味します。常識とするべきであるように、ジュニアがシニアのコードをレビューする場合、コードレビューは機能しません。ジュニアは、通常の矛盾、標準の違反、タイプミス、または入力フィルタリングのようなエラーにさえ気付くかもしれませんが、通常、より大きな問題を特定することはできません。これには、多くの場合、チームのスキルによる階層の定義がまだ存在していない場合が必要です。明確なマイルストーンを備えたコードが少ないことは、より良いレビューを意味します。コードは、個人のマイルストーンに到達した後にのみレビューする必要があり、これらのマイルストーンは小さく、頻繁に発生する必要があります。オブジェクト指向プログラミングでは、これは特に重要ですが、特に実行可能です。すでにレビューされているアダプターに結び付けられるインターフェイスを拡張する新しいコンポーネントを完成させましたか？最後に、1週間部門を悩ませている特定の方法で問題を修正しましたか？素晴らしい！コンポーネントごとにコンポーネントを使用し、一度に最大700〜800行のコード（コメントを含む）に保持することが、絶対的な最も効率的なレビュープロセスを生成するものです。レビューが短く、簡潔で独立したコードを保管し、アイデアがまだ新鮮である間に終了した後、できるだけ早くレビューを行います。覚えておいてください - 時間は高価なので、それをあまり取りすぎないでください！この「セクションレビュー」を実行するには、1時間だけで十分なはずです。
3. メトリックを収集します。これは、ツールアシストやフォーマルなどのより構造化されたタイプのコードレビューを使用している場合でも簡単ですが、OTSでも実行できます。特定の数のコードと時間単位の数字と時間を通して見つけたバグとスリップアップの数と種類に注意してください。このデータを開発者間で集約し、誰が最も助けを必要としているのか、誰が最も多くの基準を侵害し、コードレビューを行うことで実際に会社を節約した金額を簡単に見つけてください。まもなく、コードレビューの有用性を実際に定量化することができ、その場合にのみ、会社の全員が積極的に興味をそそられるようになります。これは通常、レビューの最も難しい部分です。手動統計の忍耐力を持っている開発者はほとんどいないため、採用すると有益になる可能性があります。
社会的側面に注意してください - バグを見つけるのは良いことではなく、悪くはありません！バグを見つけるのは良いことではなく、悪いことではないことを覚えておくことが不可欠です。間違いを犯した開発者を非難したり、非公式にしたりしないでください。人々にコードレビューに適応させてもらいます - 仲間にそれを受け入れるのを助けてください。コードレビューは役に立つだけでなく、楽しいこともあります。より多くの時間とより難しいタスクは、より多くのバグに匹敵することを忘れないでください。バグの数は、開発者のスキルを示していないことを忘れないでください！マネージャーまたはチームリーダーの場合は、コードレビューがネガティブまたは時間の無駄だと見なされないことを確認してください。彼らが会社によって施行されているルールとしてそれを見ていないことを確認してください。可能な場合は、コードレビューの個人的なアプローチに努めてください。ツールを使用している場合は、OTSでも使用してください。相互のブレーンストーミングの個人的なアプローチと問題に対する潜在的な解決策の非公式の議論は、あなたの友人としてコードレビューを受け入れる過程で非常に貴重です。

結論

特に慣れていない昔ながらのチームでは、コードレビューを実装するのが非常に難しい場合があります。しかし、完了すると、コードの欠陥の数を減らすだけでなく、コラボレーションを増やし、チームの構築を支援し、開発者間の「兄弟愛」を改善し、チームまたは部門全体でベストプラクティスとスキルの改善を広めます。あらゆる種類のコードレビューは何よりも優れているため、チームが今日それを使用していない場合は、提案してください。それは助けることができます。あなたがソロ開発者の場合は、コードをレビューするための親族の精神を見つけてください - オンラインに進み、社交し、開発サークルを拡大し、チームアップしてください。他の開発者を競争と見なしたり、コードレビューで敵として見たりしないでください。コードレビューをしている兄弟のような他の人を最​​前線の武器として見てください。 Fotoliaを介した画像 コードレビューに関するよくある質問

ソフトウェア開発におけるコードレビューの重要性は何ですか？

コードレビューは、ミス、バグ、または潜在的な改善について、開発者の開発者のコ​​ードをチェックすることを含むソフトウェア開発における重要なプロセスです。コードの品質の高い基準を維持し、コードが他の人が読みやすく理解できるようにするのに役立ち、チーム間で知識の共有を促進します。コードレビューは、開発プロセスの早い段階でバグをキャッチして修正するのにも役立ち、後の段階でバグ修正のコストと時間を短縮します。 >コードレビューを実施するためのいくつかのベストプラクティスには、コードのコンテキストを理解すること、コーディングスタイルではなくコードのロジックと構造に焦点を当て、建設的なフィードバックを提供し、レビュープロセスを急いでいないことが含まれます。また、レビュープロセスに適切な人を巻き込むことも重要です。通常、コードベースとレビュー中の特定の機能に精通している人を巻き込むことも重要です。コードレビューをより効果的にするには、コードが自明で、十分に文書化されており、チームのコーディング基準に従うことを確認する必要があります。また、変更を簡単に確認できる小さな管理可能なチャンクに分解する必要があります。さらに、コードレビューツールを使用すると、レビュープロセスを合理化し、コードレビューで避けるべき一般的な間違いは何ですか？コードを徹底的にレビューしないでください。コードのロジックと構造ではなく、コーディングスタイルに集中しすぎて、建設的なフィードバックを提供したり、レビュープロセスを急いでください。また、レビュープロセスに適切な人を巻き込まないことも間違いです。

PHPの良いコードレビューツールは何ですか？

PHP_CODESNIFFER、PHP MESS検出器、Sonarqubeなど、PHPのコードレビューツールがいくつかあります。これらのツールは、コードレビュープロセスを自動化し、共通のコーディングエラーをキャッチし、コーディング標準を実施するのに役立ちます。

レビューのためにコードを準備するにはどうすればよいですか？それがきれいで、十分に文書化されており、チームのコーディング基準に従っていることを確認してください。また、変更を簡単に確認できる小さな管理可能なチャンクに分解する必要があります。さらに、レビュアーがコードのコンテキストを理解できるように、変更の明確で簡潔な要約を提供する必要があります。コードレビューでは、人ではなくコードに焦点を当てる必要があります。あなたのコメントを具体的かつ明確にし、改善のための提案を提供します。また、フィードバックに敬意を表して専門的であることも重要です。

コードレビューでフィードバックを処理するにはどうすればよいですか？

コードレビューでフィードバックを受け取るときは、心を開いておくことが重要です。個人的にフィードバックを受け取らないでください。フィードバックをコーディングスキルを学び、改善する機会として考えてください。コメントに同意しない場合は、レビュアーと話し合って彼らの視点を理解してください。

コードレビューを実施する頻度はどれくらいですか？プロジェクト。ただし、通常、週に1回、またはすべての主要な機能やバグ修正など、コードレビューを定期的に実施することをお勧めします。定期的なコードレビューは、開発プロセスの早い段階でバグをキャッチして修正するのに役立ちます。

コードレビューはチームのコラボレーションを改善できますか？彼らはチーム間で知識の共有を促進し、コードベース全体で一貫したコーディングスタイルを維持し、集合的なコード所有権の文化を作成するのに役立ちます。コードレビューは、ジュニア開発者が経験豊富なチームメンバーから学ぶ機会も提供します。

以上がPHPマスター|コードレビューの重要性の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。