最初に何をすべきか：テストまたはコードレビュー？

私はプログラミングパターンとライフサイクルのプログラミングにまったく不慣れであり、最初に何をすべきか、コードレビューまたはテスト、それらは別々の人によって行われるのではないかと考えていましたか？

一方では、それが機能するかどうか誰もチェックしなかったのに、なぜコードをレビューするのが面倒ですか？一方、テストの前にレビューを行うと、いくつかのエラーが早期に発見されます。

推奨されるアプローチとその理由は？

開発者のユニットテスト、コードレビュー、QAテストの順に行います。コードレビューはユニットテストの前に行われることもありますが、通常はコードレビュー担当者が本当に困惑しているときにのみ行われ、それが彼または彼女ができる唯一の時間です。

私たちの標準は、製品がQAに移行する前にコードレビューを行うことです。その理由は、製品のテストと検証が完了すると、リファクタリングを行ったり、コード内部を変更したりするインセンティブが少なくなるためです。その後、すべてを再テストする必要があります。ほとんどの場合、ユニットテストも行うことに注意してください。

理想的には、アジャイルの世界では、両方:)

テスト駆動開発とは、実際のコードを記述する前に単体テストの開発を促進する方法です。これにより、コードで仕様をキャプチャし、テストに合格するテストを記述できます。それに続いて、さまざまなコンポーネントがすべて適合することを確認する自動化された統合テストは、アプリケーションの機能が期待されるものと一致することをさらに確認するのに適しています。

コードレビューに関しては、ペアプログラミングは、実際にコードを書いているときにコードを見落とす別の心を持たせる便利な方法です。ただし、それは必ずしも実用的なアプローチではありません。現在の会社での動作方法は、開発者の個人用マシンでテストされた後、共有開発サーバーにデプロイされる前にコードがレビューされることです。

コードが目的の品質レベルを持ち、会社が定義したコードガイドラインを満たしていることを保証するために、既に機能しているものを「研磨」するためにコードレビューが行われます。

コードレビューは、古いコードをリファクタリングおよび改善する将来の一般的な最適化アクティビティの一部としても発生する可能性があります。

チェックインを行う前にコードレビューを練習する場合、コードレビューは2つのテスト段階に分類されます。開発者として最初にコードをテストし、同僚がコードレビューを行い、チェックインします。統合テスト。

最初にテストします。最後にテストします。テスト、テスト、テスト。

コードレビューは便利です。しかし、難しい-パーソナリティが関与したり意見が異なる場合、痛みを伴うプロセスになります。

テストは非常に明確です。動作するか動作しないかのどちらかです。テスト、テスト、テスト！可能であれば、コードをレビューします。

私の最後の仕事では、製品ライフサイクルのさまざまな段階で行う3種類のコードレビューがありました。最初のタイプはサニティレビューと呼ばれ、開発者がユニットテストを行う前に発生します。実際、機能が完了する前でもサニティレビューが行われました。アイデアは、チームメンバーが座って、開発プロセスと同じようにコードのいくつかのランダムセクションを調べて、開発が順調に進み、巨大なものにならないようにすることでした機能を統合する準備ができた後のTDWTFエントリ。これは主に、追加のガイダンスが必要な人（ジュニア開発者、新入社員、他のチームメンバーよりもなじみのない作業に割り当てられた人）に対して行われ、一般にひどい問題だけを扱った短い会議を続けました。

次に、ユニットのレビューがありました。これらは通常3人の開発者で行われ、ユニット/機能がテストされ、メインツリーにマージされる準備ができたときに行われます。これは最も綿密なレビューであり、かなり詳細になります。コードの元の作成者、コードをマージする前にコードをサインオフする必要があるツリーメンテナー、および元の開発者のバックアップとして選択された3人目の開発者がいたため、このために3人の開発者がいました。 （コードのセクションが完成すると、アイデアは他のチームメンバー全員に完全に知識が伝達されるはずです。そのため、チームには常にコードベースのあらゆる部分に完全に満足している少なくとも2人がいました）。

最後に、プロジェクトのレビューがありました。これにはチーム全体が含まれ、約1週間かかり、QAと製品の発売後に行われました。目標は、誰もが最後のリリースサイクルでコードベース全体に加えられたすべての変更を確認することでした。プロジェクトの次のバージョンで開発を開始する前に、アーキテクチャの変更、落とし穴について話し、リファクタリングと修正が必要なものを決定します。

最初に、開発するコードの自動テストを作成します。テストを確認して、すべての既知の要件がテストされていることを確認します。コードを書きます。必要に応じて何度でも確認します。

手動テストが必要な場合は、手動テストを行う前にコードを確認することが重要です。そうしないと、手動テストを再実行する必要があるため、コードレビューで提案された設計の改善は拒否されます。

卵と鶏肉のどちらが先ですか？
場合によります。

新しくて何をするのかわからない場合は、ぜひピアに少し助けてください。これは非公式ですが、非常に深刻で価値のあるコードレビューです。

一般的に、最初に独自の汚い作業を行うことをお勧めしますが、適切な場所（つまり、明白なものではなくトリッキーなビット）で十分にコメントを付けて、コードをアイロンアウトしてください。非常に最小限の一般的なケースといくつかの制限のケースまたは例外でテストされています）。それからあなたはそれをあなたの仲間に持って行きます。

コードのレビューが早すぎると、同僚の時間をひどく無駄にしてしまう可能性があります。レビューを遅すぎると、ひどい時間の無駄になってしまいます。最高の効率を得るには、適切なバランスを見つける必要があります。そのため、いくつかのテストが最初に行われ、次にレビュー、さらにテストが行​​われます。複雑さと反復に応じて、目的と焦点が異なる複数のコードレビューが行われる可能性があります。

あなたがより不確かであるほど、より多くのレビューがあります（あなたが初期の学習段階にいるとき、これは正常です）。あなたがより多くのレビューを持っていると、より多くのレビューもあります（あなた自身をあまりにも確信することは決して良いことではありません、それはあなたが一般的にチームプレイヤーとしてそれほど良くなく、他の人をトラブルに巻き込む可能性があることを意味します、あなたのコードが理解できることを確認する必要があります他のユーザーが使用します）。レビューの途中にある場合があります。

私の2セントだけ。

結果として生じるソフトウェア開発プロセスの効率と品質を他の誰よりも研究し測定したケイパーズ・ジョーンズは、 以下の一連の欠陥除去活動をます。

• 設計検査
• コード検査
• 単体テスト
• 新しい機能テスト
• 回帰テスト
• 性能試験
• システムテスト
• 外部ベータテスト

テストの前にコード検査を実施する理由の1つは、レビューがコード自体だけでなく、コードのテスト容易性も考慮することができるようにするためです。