私はここ数年、TDD と (一部の) XP を実践してきましたが、それを採用する前の私のキャリアで抱えていた問題の多くが、それによって解決されることがわかりました。非常に多くの頭痛の種が取り除かれたことで、私のコーディングへの愛情が復活しました。問題は、これらのプラクティスを利用している .NET (現在のスタック) プロジェクトを見つけるのが難しいことです。
SO コミュニティに対する私の質問は次のとおりです。どのコミュニティ (言語および/またはフレームワーク) が、tdd、(実際にはすべての xDD の) xp、ci などのアジャイル プラクティスを最も取り入れていると思いますか?
この質問をするためには、測定手段を定義する必要があります。特定のコミュニティ/スタックに対して次のように定義します。
(アジャイル方法論を採用している現在のプロジェクトの数) / (現在のプロジェクトの数)
明らかに、おそらく存在しないデータがなければ、これを判断することは不可能です...私は人々の認識を探しているだけです
コミュニティによってこれが人々に関するものである場合、コミュニティとは実際には他に何があるのか 、ここにいくつかのグループがあります。
アジャイル プロジェクト リーダーシップ ネットワークの名前には、アジャイル アプローチを採用するという意味があります。
Alt.Netは、さまざまなアジャイル プラクティスを導入してさまざまな結果を得ることができるグループとして印象に残ります。
ただし、アジャイルは通常、特定のテクノロジーよりもプロセスに関するものです。あなたの質問が、アジャイルを使用している企業が採用しているテクノロジーとフレームワークに関するものである場合、それは私にとって疑わしい価値を持つまったく別のワックスのボールです. 私の近くのアルバータ州カルガリーにあるアジャイルを採用している企業は、他の企業とは大きく異なる可能性があります。たとえば、インドのバンガロール、英国のロンドン、シリコンバレー、ニューヨーク州ニューヨーク、ワシントン州シアトルのどの企業がいくつかの場所を提供するかなどです。オフィスがある大都市の近くにいる場合、アジャイルを行うThoughtworksのような会社を意味しない限り、通常は何人かの開発者が働いています。
もう 1 つの考え方は、一部のテクノロジが、ここで物事を曇らせる可能性があるさまざまなサブコミュニティまたはサイズをどのように持つかを検討することです。たとえば、多くの Java および .Net 開発者はアジャイルを採用し、多くの開発者はそれを嫌っています。うまく機能するウォーターフォール手法を採用している企業がある場合、なぜアジャイルに切り替える必要があるのでしょうか? 同時に、いくつかのテクノロジーはコミュニティが非常に小さいため、まったく異なる観点から見られる場合があります。また、これらの新しく出現したテクノロジーを使用する人々がどれほどうまく組織化されているかということも考えられます。
うまくいけば、誰かがこのブレインダンプを面白いと思ってくれます... ;)
私は、Rails と Django の両方の陣営に足を踏み入れています。私が見たところ、Rails 関係者は実際にテストを行っています。彼らはブログでテストについて話し、カンファレンスでテストについて話し、アプリの非 Rails 部分をテストするためのいくつかの興味深いテスト ツール (ScrewUnit など) をスピンオフします。Rails コミュニティに参加してテストをしないというのは、本当につらいことです。
Django コミュニティは、テストの面で遅れをとっています。Django にはテスト用の基本的なサポートが付属していますが、それを探す必要があります。現在の Django の本はどれも、テストに関する脚注を提供する以上のことはしていません。また、Django コミュニティ メンバーによる実質的な「テスト方法」のブログを目にすることはめったにありません。最初の DjangoCon ではテストに関する話はありませんでした。
反対に、Rails のユーザーは、monkeypatching と gem のバージョンの競合 (または競合する monkeypatching を行う gem やプラグイン) が原因で混乱する可能性がはるかに高いため、自動テストが不可欠です。私が見た Django プロジェクトは、同じトラブルに巻き込まれるのがより困難であるため、スケートをすることができました。
他のアジャイル プラクティスについては、日常的に多くのプロジェクトの内部をのぞき見ることができずに語ることは困難です。
これらのワークフローが特定の言語に結び付けられているとは思いませんし、どの言語もこれらのワークフローに必ずしも適しているとは思いません。これからの逸脱は、主に文化的なものです。
たとえば、正規の Rails プロジェクト スケルトンは、テストの作成や TDD の使用に対する障壁が非常に低いですが、NUnit を取得して TDD .NET プロジェクトを作成することを妨げるものは何もありません。
以下に、調査に関心のある .NET ツールをいくつか示します。
単体テスト:
継続的インテグレーション：
私のやや限られた経験から、Ruby/Rail コミュニティがテストの最先端を押し進めていることがわかりました。新しいテクノロジーを導入し、TDD と BDD の概念をほとんどのものに一般的に統合します。一方、PHP はいくぶん行き当たりばったりです。宗教的に使用するグループもあれば、まったく使用しないように見えるグループもあります。PHP のツールセットは、Ruby および Rails コミュニティほど堅牢で奥が深いようには見えません。
YMMV。