私は過去2週間、小規模な営利目的のマルチプレイヤーアーケードゲームのために、いくつかの基本的な極端なプログラミングコンセプトに取り組んできました。 1週間かけてユーザーストーリーを作成し、リリース計画を作成するための要件を決定しました。私はまた、思いついた最初の反復計画のコーディングと適用に1週間費やしました。私は、1人の開発者にとって明らかに便利な概念をいくつか確認しました。
単一の開発者プロジェクトでの作業に適した可能性のある、特に何か足りないものがあるかどうか知りたいのですが。
また、シンプルさとテスト駆動開発の考え方を踏まえると、確立された機能豊富な既製のプラットフォームを使用する方が良いでしょうか?
それとも、可能であれば、絶えずリファクタリングし、機能を早期に追加しないなどのルールで提示される問題に遭遇しないように、ゼロから作業する必要がありますか?
究極的には、エクストリームプログラミングは、ビジネス価値の向上につながる一連の実践と方法論に関するものです。私が見つけたこれの最良のイラストは http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart からです。
青色の部分はすべてXPのcoreの一部です。
青色の領域内にあるものを有効にするのに役立ち、XP全体の一部ですが、それに対して重要ではありません。私は個人的にはXP実務家であり、私は「=」に続く人々のかなりの批判を次のように読みましたXPさまざまな人々がXPではないとしています。設定しましょうXP=の教義のその側面は少し脇に置いて、私たちが持っているものを見てください。
最初の、そしてほとんどのことの1つが、顧客からのプロセスへのコミットメントを持つことであることを認識してください。 XP=の主要なコンポーネントは顧客の関与です。これは、リリース計画、小規模リリース、オフサイト顧客評価などの多くのスポットに現れます。これらは、顧客がサブスクライブする必要があるものですXPでソロの開発者として成功するかどうか。代わりに設計、開発期間、そしてテストなどを求められた場合、あなたはそれらをさらに進める。
XPは計画がないという意味ではありません。これには、計画がその一部であるいくつかのポイントがあります-優先順位付け、ユーザーストーリー推定、反復計画、およびタスク定義です。あなたはこれに関して1人の開発者ですが、これらは顧客に提供する際に協力する必要があるものです。
コードの共同所有権やペアプログラミングなどのポイントは、複数の要素に関係しています。コーディング標準などの決定ははるかに簡単ですが、それに従う必要はありません。集団的なコードの所有権は依然として適用されます-所有権は次の開発者でもあるということだけです-あなたとあなただけのためのコードを書かないでください。これは、ペアプログラミングによって有効にされる「コードがすべての意図を明らかにする」とある程度矛盾していることに注意してください。保守可能なコードを書いていることを確認する担当者がいないため、コードのドキュメントも重要です。
これらの警告以外に、XP設計原則の多くは依然として適用されます。テストファースト設計、継続的インテグレーション、顧客とのミーティング、リファクタリング、YAGNI、スパイクソリューションなど-これらのコールは実行できますソロ。
ソロXPは通常のXPと同じかそれ以上の規律を必要とします。XPは 高規律方法論 と見なされることが多いので、それを具体化しようとするベストプラクティスへの厳格な遵守を維持することを人々に要求します。必要な規律をサポートするコーチまたは他の人々がいない場合、必要な規範をXPに類似した実践のホッジポッドに陥る可能性があります。
関連読書:
最初のc2リンクから引用を引き出したい:
著名なPerl言語の著名人であり、マッドサイエンティストであるDamian Conwayは、Extreme Programmingは実際には誤称であると信じています。それは、プログラマーが教えられているが、ほぼ確実に無視している優れたプログラミング実践の多くを具体化しているので、それは本当に超保守的なプログラミングと呼ばれるべきだったと信じています