5

私は、チームメイトに TDD を採用するよう説得しようとしているチームに所属しています (以前のチームで TDD が機能し、セットアップが似ているのを見てきたため)。また、私の個人的な信念は、TDD とペア プログラミングの両方を組み合わせて行うと、少なくとも最初のうちは本当に役立つということです。そうすれば、(TDD の) 経験の浅い 2 人の開発者が互いに助け合い、どのような種類のテストを作成するかを議論し、うまく進めることができます。

一方、私のマネージャーは、チームに 2 つの新しい開発プラクティスを同時に導入すると、両方とも失敗する可能性が高いと感じています。だから、彼はもう少し保守的になりたいと思っています。

これらの両方が補完的であり、直交していないことを彼に納得させるにはどうすればよいでしょうか。それとも私は間違っていますか?

4

10 に答える 10

13

TDD で自分が何をしているのかを知らない人が増えることが助けになるかどうかはわかりません。それはすぐに、主題をグーグルで検索するか、TDDとは何か/そうでないかについて議論することになります。

チームの誰かに特定のテクニックのエバンジェリストになってもらい (誰かが TDD について読んだり、ペア プログラミングについて読んだり)、その人たちにそれらのことを宣伝して試してもらったりする方がよいと思います。はい、両方が同時に発生する可能性がありますが、プロジェクト チーム全体で使用する必要はありません。チームの少人数のグループでペア プログラミングを行い、その経験を報告することができます。

于 2009-05-19T13:17:24.477 に答える
9

ペアプログラミングは、特に 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 に基づいています。

  1. テストを書きます。テスト駆動開発では、それぞれの新しいストーリー カードはテストを書くことから始まります。このテストは、機能が実装される前に記述されているため、失敗します。テストを作成するには、開発者は機能の仕様と要件を明確に理解する必要があります。これは、要件がいつ満たされたかを指定する受け入れ基準を含むストーリー カードによって達成される場合があります。これは、不変条件、または既存のテストの変更を意味する場合もあります。これは、テスト駆動開発と、コードを書いた後に単体テストを書くことを区別する特徴です。これにより、開発者は、コードを書く前に要件に集中できるようになります。これは、微妙ではありますが重要な違いです。
  2. すべてのテストを実行し、新しいテストが失敗するかどうかを確認します。これにより、テスト ハーネスが正しく機能していること、および新しいコードを必要とせずに新しいテストが誤って合格しないことが検証されます。新しいテストも、予想される理由で失敗するはずです。このステップは、テスト自体を否定的にテストします。つまり、新しいテストが常にパスする可能性を除外し、したがって価値がないことを示します。
  3. コードを書きます。次のステップは、テストに合格するコードを書くことです。この段階で書かれた新しいコードは完璧ではなく、たとえば、洗練されていない方法でテストに合格する可能性があります。後のステップで改善され、磨き上げられるため、これは許容されます。記述されたコードは、テストに合格することのみを目的として設計されていることが重要です。それ以上の(したがってテストされていない)機能は、どの段階でも予測して「許可」するべきではありません。
  4. 自動テストを実行して、成功することを確認します。すべてのテスト ケースに合格した場合、プログラマーはコードがテストされたすべての要件を満たしていると確信できます。これは、サイクルの最終ステップを開始するのに適したポイントです。
  5. コードをリファクタリングします。これで、必要に応じてコードをクリーンアップできます。テスト ケースを再実行することで、開発者は、リファクタリングによって既存の機能が損なわれていないことを確信できます。重複を取り除くという概念は、ソフトウェア設計の重要な側面です。ただし、この場合、ステップ 3 でテストに合格するために、テスト コードと製品コードの間の重複を削除することにも適用されます。たとえば、両方で繰り返されたマジック ナンバーや文字列などです。

繰り返す

別の新しいテストから始めて、このサイクルを繰り返して機能を前進させます。ステップのサイズは、開発者が好きなだけ小さくすることも、自信があれば大きくすることもできます。テストを満たすために書かれたコードがすぐに満足できない場合は、ステップサイズが大きすぎた可能性があり、代わりにテスト可能な小さなステップを使用する必要があります。外部ライブラリを使用する場合、ライブラリにバグがある、またはライブラリのすべてのニーズに対応するのに十分な機能が完成していないと信じる何らかの理由がない限り、ライブラリ自体を効果的にテストするだけの小さなインクリメントを作成しないことが重要です。メインプログラムを書いています。

開発スタイル テスト駆動開発の使用にはさまざまな側面があります。たとえば、"Keep It Simple, Stupid" (KISS) や "You Ain't Gonna Need It" (YAGNI) の原則などがあります。テストに合格するために必要なコードだけを書くことに集中することで、他の方法で実現されることが多いよりも、デザインをよりクリーンで明確にすることができます。テスト駆動開発では、プログラマーは最初にテスト ケースに失敗する必要があります。アイデアは、テストが実際に機能し、エラーをキャッチできることを確認することです。これが表示されると、通常のサイクルが開始されます。これは、赤/緑/リファクタリングとして知られる「テスト駆動開発マントラ」という造語で、赤は失敗を意味し、緑は合格を意味します。テスト駆動開発では、失敗したテストケースを追加してパスし、リファクタリングするという手順を常に繰り返します。

于 2009-05-22T16:11:57.493 に答える
2

新しいことを学ぶときにペアプログラミングが非常に役立つというあなたの意見は間違いありません。私はあなたが両方を行うことを強く推し進める必要があることに同意します。

おそらく、上司に説明する最善の方法は、これら 2 つの新しいことを同時に導入するよう求めていることを示唆しないことです。代わりに、TDD の実装を開始する最も効率的な方法は、まだ作業を完了している間に「TDD 調査チーム」として 2 人の開発者を取り、協力して適切なツールをセットアップすることであると感じていることを提案してください。テクニックをテストし、環境に適用するために何をする必要があるかを理解します。それが機能するようになり、少し経験のある 2 人ができたら、彼らを分割して、別の開発者と数日間座って、その別の開発者に新しい技術について理解してもらいます。すべての開発者が TDD を習得するまで繰り返します。

于 2009-05-19T13:15:55.680 に答える
1

あなたは納得していません。両方が一緒に機能すると思う理由を彼に伝え、おそらくこれを確認するデータを提示して、彼に判断させてください. それが良い考えだと皆に納得させる必要があるのなら、誰もそれをうまく受け入れないだろうと私は確信しています. 自然な反対。

于 2009-05-19T13:14:59.597 に答える
1

個人的には、経験者と未経験者のペアプログラミングが最も効果的であることがわかりました。

つまり、均等にスキルを合わせようとするのではなく、プログラマーのスキル/経験の違いを目指します。

経験豊富な人は、説明と思考の構築を強いられることから、より多くのことを得ることができますが、経験の浅い人は、アイデアを跳ね返し、「ベストプラクティス」を習得する機会を得ます.

TDDに関しては、私は大ファンです。ここでも exp は、テストのポイントを実際に引き出すのに役立つため、経験の浅い人に役立ちます。つまり、絶対にすべてをテストしたくないということです...それは焦点を追加します。多くの場合、人々は何を達成しようとしているのかに焦点を当てずにテストを書いています。

単体テストは不可欠です...結局のところ、一部のスタッフは2年後にはそこにいません。機能を検証するものが何もない場合、既存のコードをどのように変更できますか?

于 2009-05-19T13:58:43.690 に答える
0

まあ、管理者によっては、これらのプラクティスが相互に依存しているという XP 文献のいくつかの議論を指摘することができます。たとえば、しっかりした単体テストがない場合は、容赦なくリファクタリングしないでください。

ペアリングは、新しい困難な問題に対する共同作業と同様に、TDD を理解することのみを目的としており、「すべての製品開発がペアで行われる」というわけではないという点で、漸進的にアプローチすることをお勧めします。

于 2009-05-19T13:17:34.850 に答える
0

1 つの方法でもう 1 つの方法を使用する必要はありませんが、両方を少しずつ導入する「こっそり」方法があります。

利用可能な xUnit フレームワークの 1 つを使用して TDD を実装するという目標から始めます。相性の良い同僚を見つけて、1 日 1 時間ほどあなたと一緒に仕事をしてくれるかどうか尋ねてください。「ショーン、私はこの新しいツールを試しています。正しく行っているかどうかを確認するのを手伝ってくれませんか?」本当にうまくいきます。

ショーンと数日過ごした後、スーザンと繰り返し...

于 2009-05-19T13:21:28.117 に答える
0

とにかくやってください。マネージャーがあなたのペアリングを見つけたら、「コード レビュー」という魔法の言葉を言ってください
前提: 明らかに、ペアは十分に訓練/集中されており、セッションの最後に動作するコードを生成する必要があります

于 2009-05-19T13:25:48.733 に答える