一人の開発者のためのエクストリームプログラミング[終了]

私は過去2週間、小規模で営利目的のマルチプレイヤーアーケードゲームのために、いくつかの基本的な極端なプログラミングコンセプトを扱ってきました。1週間かけてユーザーストーリーを作成し、リリース計画を作成するための要件を決定しました。また、思いついた最初の反復計画のコーディングと適用に1週間費やしました。私は、1人の開発者にとって明らかに便利な概念のいくつかを特定しました。

• 継続的インテグレーション
• 早期に機能を追加しない
• テスト駆動開発
• システムのメタファーを選択
• 単一の統合ポイントを使用する
• すべてのバグをテストする
• 常にリファクタリング
• 持続可能なペースを設定する
• シンプルさ
• 頻繁なリリース

特に、単一の開発者プロジェクトでの作業に適したものがないとしたら、私は興味がありますか？

また、シンプルさとテスト駆動開発の考えを踏まえると、この観点から、確立された機能豊富な既製のプラットフォームを使用する方が良いでしょうか？

それとも、可能であれば、絶えずリファクタリングし、機能を早期に追加しないなどのルールで提示される問題に遭遇しないように、ゼロから作業する必要がありますか？

究極的には、エクストリームプログラミングは、ビジネス価値の向上につながる一連の実践と方法論に関するものです。私が見つけたこれの最高のイラストはhttp://c2.com/cgi/wiki?ExtremeProgrammingEnablingChartからのものです

青色の部分はすべてXP のコアの一部です。

青色の領域内にあるものを有効にするのに役立ち、全体としてXPの一部ですが、クリティカルではない、その外側にある部分があります。私は個人的にはXPの実践者ではないことに注意してください。さまざまな人々がXPではないと言っているXPに「ほぼ」従う人々をかなり批判しました。XPの教義の側面を少し脇に置いて、私たちが持っているものを見てみましょう。

何よりもまず、お客様からのプロセスへの取り組みが重要であることを認識してください。XPの主要なコンポーネントは、顧客の関与です。これは、リリース計画、小規模なリリース、オフサイトの顧客評価など、多​​くの場所に現れます。これらは、XPで単独の開発者として成功するために顧客が購読する必要があるものです。代わりに設計、開発期間、そしてテストなどを求められた場合、あなたは彼らからさらに進んでいくという約束はありません。

XPは計画がないという意味ではありません。これには、計画がその一部であるいくつかのポイントがあります-優先順位付け、ユーザーストーリー推定、反復計画、およびタスク定義です。あなたはこれに関する1人の開発者ですが、これらはあなたが提供する際に顧客と協力する必要があるものです。

コードの共同所有権やペアプログラミングなどのポイントは、複数の要素が関係するものです。コーディング標準などの決定ははるかに簡単ですが、それに従う必要がないという意味ではありません。集団的なコードの所有権は依然として適用されます-所有権は次の開発者でもあるということだけです-あなたとあなただけのためのコードを書かないでください。これは、ペアプログラミングによって有効化される「コードがすべての意図を明らかにする」とある程度矛盾していることに注意してください。保守可能なコードを書いていることを確認する担当者がいないため、コードのドキュメントも重要です。

これらの警告以外に、XP設計原則の多くが依然として適用されます。テストファーストデザイン、継続的インテグレーション、顧客とのミーティング、リファクタリング、YAGNI、スパイクソリューションなど。これらの呼び出しは単独で行うことができます。

ソロXPは通常のXPと同じかそれ以上の規律を持っていることを理解してください。XPは、それを具体化しようとするベストプラクティスへの厳密な順守を維持することを人々に要求するという点で、高度な規律の方法論と見なされることがよくあります。コーチや他の人がその分野をサポートする必要がない場合は、XPに類似した慣習の寄せ集めに陥る可能性があります。

関連読書：

• XPのテーマのバリエーション（Martin Fowler）
• エクストリームプログラミング（c2でさまざま）
• 1つのエクストリームプログラミング（c2でさまざま）

最初のc2リンクから引用を引き出したい：

著名なPerl言語の著名なマッドサイエンティストであるDamian Conwayは、Extreme Programmingは実際には誤った名称であると信じています。それは、プログラマーが教えられているが、ほぼ確実に無視している優れたプログラミング実践の多くを具体化しているので、それは本当に超保守的なプログラミングと呼ばれるべきだったと信じています