最初に何をすべきか：テストまたはコードレビュー？
私はプログラミングパターンとライフサイクルのプログラミングに非常に慣れていないので、コードレビューやテストなど、別の人が何を行う必要があるのでしょうか。
一方から、それが機能するかどうか誰もチェックしていないのに、なぜコードをレビューする必要があるのでしょうか？テスト前にレビューを行うと、他からいくつかのエラーが早期に見つかることがあります。
推奨されるアプローチとその理由は？
最初に開発者のユニットテスト、次にコードレビュー、次にQAテストがその方法です。場合によっては、ユニットテストの前にコードレビューが行われることもありますが、通常はコードレビュー担当者が本当に困惑していて、それが彼または彼女ができる唯一の場合です。
私たちの標準は、製品がQAに進む前にコードレビューを行うことです。その理由は、製品のテストと検証が完了すると、リファクタリングを行ったり、コードの内部を変更したりするインセンティブが少なくなるためです。その後、すべてを再テストする必要があります。ほとんどの場合、ユニットテストも行います。
理想的には、アジャイルの世界では、両方:)
テスト駆動開発は、実際のコードを記述する前に単体テストの開発を促進する方法です。これにより、コードで仕様を取得し、テストに合格するテストを記述できます。その後、さまざまな異なるコンポーネントがすべて適合していることを確認する自動化された統合テストは、アプリケーションの機能が期待どおりに機能することをさらに確実にするための良いことです。
コードレビューに関しては、ペアプログラミングは、実際にコードを書いているときに、コードを見落とす別の気にさせる便利な方法です。ただし、これは必ずしも実用的なアプローチではありません。私の現在の会社では、コードは開発者の個人用マシンでテストされた後、共有開発サーバーにデプロイされる前にレビューされます。
コードレビューは、すでに機能しているものを「磨き」、コードが望ましい品質レベルを持ち、会社が定義したコードガイドラインに適合していることを確認するために行われます。
コードレビューは、古いコードをリファクタリングして改善する将来の一般的な最適化アクティビティの一部としても発生する可能性があります。
チェックインを行う前にコードレビューを練習する場合、コードレビューは2つのテスト段階に分類されます。まず開発者がコードをテストし、ピアがコードレビューを行い、チェックインします。その後、後で専用のテスターがさらに徹底的にテストを行います。統合テスト。
最初にテストします。最後にテストします。テスト、テスト、テスト。
コードのレビューは簡単です。しかし難しい-人格が関与するか、意見が異なる場合、苦痛なプロセスになる可能性があります。
テストは非常に明確です。機能するか機能しないかのどちらかです。だからテスト、テスト、テスト！そして、可能であればコードレビュー。
まず、開発するコードの自動テストを記述します。テストを確認して、すべての既知の要件がテストされていることを確認します。コードを記述します。何度でも確認してください。
手動テストが必要な場合は、コードを確認することが重要ですbefore手動テストが実行されます。そうしないと、手動テストを再実行する必要があるため、コードレビューで提案された設計の改善は拒否されます。
Capers-Jonesは、ソフトウェア開発プロセスの結果として得られる効率と品質を他の誰よりも研究および測定しており、欠陥除去活動の 次のシーケンス を推奨しています。
- 設計検査
- コード検査
- 単体テスト
- 新しい機能テスト
- 回帰テスト
- 性能試験
- システムテスト
- 外部ベータテスト
テストの前にコードインスペクションを実施する理由の1つは、レビューでコード自体だけでなく、コードのテスト容易性も考慮できるようにするためです。
卵と鶏のどちらが最初ですか？
状況によって異なります。
あなたが新しく、あなたが何をしているのかわからない場合は、必ず同僚に少しだけ助けを求めてください。これは非公式ですが、非常に深刻で価値のあるコードレビューです。
一般的に私はあなたが最初にあなた自身の汚い仕事をすることをお勧めしますが、あなたがコードを解決し、適切な場所でよくコメントしたことを確認してください（すなわち、明白なものではなくトリッキーなビット）最小限の一般的なケースといくつかの制限ケースまたは例外でテストされています）。それからあなたはそれをあなたの仲間に持っていきます。
コードのレビューを早すぎると、同僚の時間を大幅に浪費することになります。それをレビューするのが遅すぎると、あなたの時間はひどい無駄に終わる可能性があります。最高の効率を得るには、適切なバランスを見つける必要があります。したがって、最初にいくつかのテストが行われ、次にレビューが行われ、さらに多くのテストが行われます。潜在的には、複雑さと反復に応じて、さまざまな目的と目的に応じて、いくつかのコードレビューを行う可能性があります。
あなたがより多くのレビューをしていると確信が低くなります（初期の学習段階にあるとき、これは正常です）。あなたもレビューが多いほど確信が持てます（自分自身を確信しすぎていることは決して良いことではありません。つまり、一般的にチームプレイヤーとしてはそれほど良くなく、他の人をトラブルに巻き込む可能性があるため、コードを理解できるようにする必要があります。と他の人が使用します）。レビューの間隔を空けることができるのは、真ん中にいるときです。
私の2セントだけ。
私の最後の仕事では、製品ライフサイクルのさまざまな段階で行う3種類のコードレビューがありました。最初のタイプはサニティーレビューと呼ばれ、開発者がユニットテストを行う前に発生しました。実際、サニティーレビューは機能が完了する前でも実施されていました。チームメンバーのペアが座って、開発プロセスと同じように、コードのランダムなセクションをいくつか見て、開発が順調に進んでいて、巨大なものになってしまうことはないという考えでした。機能を統合する準備ができたらTDWTFエントリ。これは主に、追加のガイダンスを必要とする人々（ジュニア開発者、新入社員、および他のチームメンバーほど馴染みのない作業に割り当てられた人々）のために行われ、通常は悪質な問題のみを取り上げた短い会議に留まりました。
次に、ユニットレビューがありました。これらは通常3人の開発者によって行われ、ユニット/機能がテストされ、メインツリーにマージする準備ができたときに行われます。これは最も骨の折れるレビューであり、かなり詳細になります。コードの元の作成者、コードをマージする前にコードをサインオフしなければならなかったツリーメンテナー、元の開発者のバックアップとして選択された3番目の開発者がいるため、3人の開発者がいました。 （コードのセクションが完成すると、他の1人のチームメンバーに完全な知識が伝わるはずなので、コードベースのどの部分にも完全に慣れているチームには常に少なくとも2人がいました）。
最後に、プロジェクトのレビューがありました。これはチーム全体を含み、約1週間かかり、QAと製品の発売後に行われました。目標は、最後のリリースサイクル全体で全員が座り、コードベース全体に対するすべての変更をウォークスルーすることでした。アーキテクチャの変更、落とし穴について話し、次のバージョンのプロジェクトの開発を開始する前に、リファクタリングと修正が必要なものを決定します。