エクストリーム・プログラミング
エクストリーム・プログラミングでは、最もシンプルな解説策から始めることを推奨している。機能は、後から追加できる。 このアプローチと従来のシステム開発手法との違いは、明日、来週、または来月のニーズではなく、今日のニーズに合わせた設計とコーディングに焦点を当てていることだ。 これは、「実際に必要となるまでは追加しない」(YAGNI)アプローチとして要約されることがある。 XPの支持者は、これが、システムの変更に明日より多くの努力を必要とすることがあるという欠点を認めている; 彼らの主張は、関係が生まれる前に変更される可能性のある将来の要件に投資しないという利点によって、これは十分に補償されるということだ。 将来の不確実な要件を考慮してコーディングや設計をすることは、必要ではないかもしれないものにリソースを費やすリスクを意味し、重要な機能を遅らせてしまう可能性がある。 「コミュニケーション」の価値に関連して、設計とコーディングのシンプルさは、コミュニケーションの質を向上させるはずである。 非常にシンプルなコードによるシンプルな設計は、チーム内のほとんどのプログラマーが簡単に理解できる。
↑ "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006
1 2 UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003.
1 2 USFCA-edu-601-lecture Extreme Programming.
↑ “Manifesto for Agile Software Development”. Agilemanifesto.org (2001年). 2019年3月26日閲覧。
1 2 3 4 5 6 7 8 9 10 11 12 13 Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001
1 2 3 Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6.