ペアプログラミングは、特に TDD の新しいプラクティスを学ぶときに効果的です。
したがって、妥協して両方を持つことができます。これをアジャイルな方法で段階的に行います。まずはペアプログラミング。2つのうちのほうが簡単です。ペアプログラミング後のすべてのプラクティスは、習得がはるかに簡単になり、チームによってより迅速かつ一貫して採用されるようになります。ペア プログラミングは、最初に採用されるべきではないにしても、最初に採用されるべきエンジニアリング プラクティスの 1 つです。効果的に行うようにしてください。以下に、ペアプログラミングの方法を説明します。
ペア プログラミングは、開発チームがソフトウェアを開発する際に使用できる最も強力なプラクティスの 1 つです。ペアリングは、2 人の開発者が 1 台のコンピューターとキーボードを使用してストーリー カードを積極的に作成することで発生します。管理者は、ペアプログラミングを使用するとプログラミングコストが 2 倍になるのではないかと心配しています。一見すると、2 人の開発者が同じタスクで協力するように求められていると彼らが考える理由は理解できます。ただし、実際には、この開発手法を使用するアジャイル チームは、初期開発コストのわずかな増加 (ユタ大学の調査によると 15%) が、欠陥の減少、テストの短縮と低コスト化によって相殺される以上のものであることを発見しました。生産サポートの必要性を減らします。
プログラマーをペアにして一緒に作業させると生産性が向上するというのは直感に反するように思えるかもしれませんが、この手法が実際に機能する理由はいくつかあります (「2 つの頭は 1 つよりも優れている」という古いことわざを思い出してください)。その理由は次のとおりです。
- 品質の向上 -- ペアリングによりコード レビューが促進されます。多くの間違いは、入力中に発見されます。ペア プログラミングとは、コードの品質に専念し、常にバグを特定して修正するために協力している 2 人の人物による継続的なコード レビューを意味します。ユタ大学が行った調査によると、コードで見つかった欠陥の最終的な数は、ペアで書かれたコードで平均 15% 減少しました。
- 「立ち往生」する時間が減る -- プログラミングは難しい。多くの場合、開発者は解決策を見つけるのに苦労し、「立ち往生」するよりも多くの時間を費やします。アイデアをブレインストーミングし、必要に応じて助けを求めることに同意するパートナーを持つことで、解決策を見つけるために立ち往生する非生産的な時間を減らすことができます。
- 気晴らしに費やされる時間が減る -- 開発者は、パートナーと一緒に仕事をしているとき、個人的な電話や Web サーフィン、休暇中の電子メールに時間を費やす可能性が低くなります。
- 2 つの視点が問題に適用される -- 経験のレベルが異なり、問題解決のスタイルが異なり、補助的なスキルが異なると、問題をより迅速に解決できる可能性が高くなります。ユタ大学が行った調査では、ペアで作成されたソフトウェアの全体的な設計が改善され、コードの長さが短くなったことも明らかになりました。
- 未知への恐怖が減る -- 他の開発者とペアを組むと、一人で作業するよりも、問題に取り組みやすく、新しい技術を理解しようとするのも容易になる。また、時間が経つにつれて、アプリケーション全体の理解が深まります。最終的に、このプロジェクトは、ペアリングの結果として、システムの各部分を理解する複数の人に行き着きます。
- 範囲内に構築する可能性が低い -- 開発者は、要件で扱われていない機能を喜んで追加することがよくあります。ペアで作業する場合、2 番目の開発者はパートナーを仕事に留める可能性が高くなります。
- チーム ダイナミクスの改善 -- ペア アプローチのおかげで、人々は協力することを学びます。彼らはより頻繁に話し、より良い情報の流れを体験します。その結果、チームのダイナミクスが向上します。実際、最高のチーム ビルディング エクスペリエンスは、協力して顧客が興奮するソフトウェアを作成することであることがわかりました。誰もが成功するチームの一員であることを好みます。
- サイロ化された知識の排除 – ドメインの知識、コードまたはプラクティスの知識は、チームと開発者のペアを通じてローテーションベースで迅速に伝達されます。
チームがペアリングに慣れたら、TDD に取り組みます。説明は次のとおりです。
テスト駆動開発 (TDD) は、短期間の開発で構成されるソフトウェア開発エンジニアリング手法であり、最初に目的の改善または新しい機能をカバーする新しいテスト ケースを作成し、次にテストに合格するために必要な製品コードを実装し、最後にソフトウェアは、変更に対応するためにリファクタリングされます。実際の開発前にテストを利用できるため、変更後の迅速なフィードバックが保証されます。実践者は、テスト駆動開発は単なるテスト方法ではなく、ソフトウェアを設計する方法であると強調しています。テスト駆動開発は強力なプラクティスであり、ライフ サイクルの後半で発見される欠陥の削減に大きく貢献します。新しいチームは、経験豊富な TDD プラクティショナーとペアを組むか、TDD コーチングを受けることを強くお勧めします。
テスト駆動型開発では、コード自体の各側面の前に、コードの要件を定義する自動化された単体テストを作成する必要があります。これらのテストには、真または偽のアサーションが含まれています。テストを実行すると、コードが進化してリファクタリングされるときに、正しい動作を迅速に確認できます。xUnit の概念に基づくテスト フレームワークは、一連の自動化されたテスト ケースを作成および実行するためのメカニズムを提供します。テスト駆動開発サイクル: 次のシーケンスは、多くの人が現代的な形での概念に関する標準的なソース テキストと見なしている本、Test-Driven Development by Example に基づいています。
- テストを書きます。テスト駆動開発では、それぞれの新しいストーリー カードはテストを書くことから始まります。このテストは、機能が実装される前に記述されているため、失敗します。テストを作成するには、開発者は機能の仕様と要件を明確に理解する必要があります。これは、要件がいつ満たされたかを指定する受け入れ基準を含むストーリー カードによって達成される場合があります。これは、不変条件、または既存のテストの変更を意味する場合もあります。これは、テスト駆動開発と、コードを書いた後に単体テストを書くことを区別する特徴です。これにより、開発者は、コードを書く前に要件に集中できるようになります。これは、微妙ではありますが重要な違いです。
- すべてのテストを実行し、新しいテストが失敗するかどうかを確認します。これにより、テスト ハーネスが正しく機能していること、および新しいコードを必要とせずに新しいテストが誤って合格しないことが検証されます。新しいテストも、予想される理由で失敗するはずです。このステップは、テスト自体を否定的にテストします。つまり、新しいテストが常にパスする可能性を除外し、したがって価値がないことを示します。
- コードを書きます。次のステップは、テストに合格するコードを書くことです。この段階で書かれた新しいコードは完璧ではなく、たとえば、洗練されていない方法でテストに合格する可能性があります。後のステップで改善され、磨き上げられるため、これは許容されます。記述されたコードは、テストに合格することのみを目的として設計されていることが重要です。それ以上の(したがってテストされていない)機能は、どの段階でも予測して「許可」するべきではありません。
- 自動テストを実行して、成功することを確認します。すべてのテスト ケースに合格した場合、プログラマーはコードがテストされたすべての要件を満たしていると確信できます。これは、サイクルの最終ステップを開始するのに適したポイントです。
- コードをリファクタリングします。これで、必要に応じてコードをクリーンアップできます。テスト ケースを再実行することで、開発者は、リファクタリングによって既存の機能が損なわれていないことを確信できます。重複を取り除くという概念は、ソフトウェア設計の重要な側面です。ただし、この場合、ステップ 3 でテストに合格するために、テスト コードと製品コードの間の重複を削除することにも適用されます。たとえば、両方で繰り返されたマジック ナンバーや文字列などです。
繰り返す
別の新しいテストから始めて、このサイクルを繰り返して機能を前進させます。ステップのサイズは、開発者が好きなだけ小さくすることも、自信があれば大きくすることもできます。テストを満たすために書かれたコードがすぐに満足できない場合は、ステップサイズが大きすぎた可能性があり、代わりにテスト可能な小さなステップを使用する必要があります。外部ライブラリを使用する場合、ライブラリにバグがある、またはライブラリのすべてのニーズに対応するのに十分な機能が完成していないと信じる何らかの理由がない限り、ライブラリ自体を効果的にテストするだけの小さなインクリメントを作成しないことが重要です。メインプログラムを書いています。
開発スタイル テスト駆動開発の使用にはさまざまな側面があります。たとえば、"Keep It Simple, Stupid" (KISS) や "You Ain't Gonna Need It" (YAGNI) の原則などがあります。テストに合格するために必要なコードだけを書くことに集中することで、他の方法で実現されることが多いよりも、デザインをよりクリーンで明確にすることができます。テスト駆動開発では、プログラマーは最初にテスト ケースに失敗する必要があります。アイデアは、テストが実際に機能し、エラーをキャッチできることを確認することです。これが表示されると、通常のサイクルが開始されます。これは、赤/緑/リファクタリングとして知られる「テスト駆動開発マントラ」という造語で、赤は失敗を意味し、緑は合格を意味します。テスト駆動開発では、失敗したテストケースを追加してパスし、リファクタリングするという手順を常に繰り返します。