![[PukiWiki]](image/sandbox.gif "[PukiWiki]")
- バックアップ一覧
- ソース を表示
- 清原研修/11 は削除されています。
- 1 (2007-09-20 (木) 18:17:53)
- 2 (2007-09-20 (木) 19:55:46)
- 3 (2007-09-26 (水) 14:44:33)
目次 †
XPまとめ †
| カテゴリー | XPまとめ |
| 優先順位 | 至急 |
| イテレーション | イテレーション1 |
| 状態 | 未着手 |
| 完了予定日 | |
| 工数 | |
| 対応者 | 清原 |
主な開発手法 †
- エクストリーム・プログラミング(eXtreme Programming)の略
- アジャイルソフトウェア開発の代表的な開発手法
- ケント・ベックが主唱者
- ドキュメントよりも実際に動くソースコードを重視
- ウォーターフォールモデル
- 滝が上から下に落ちる様子に例え要件定義、分析、設計、実装、テストの各工程を計画された順序に従って行う。基本的に工程の後戻りはしない
- ソフトウェア開発手法の中で最も計画重視
ウォーターフォールモデルとの比較 †
| ウォーターフォール | XP | |
| 開発規模 | 大規模な開発に向き | 比較的小規模な開発に向き |
| 変更への柔軟性 | 一度終えた工程には戻らないという性質上、途中での仕様変更には弱い | 開発中は状況変化がある事が前提の為、比較的変更には強い |
| テスト | モジュールの完成後に単体テスト、全てのモジュールの完成後に結合テスト。あとにまとめて試験する為予想外なバグの修正が困難 | テスト駆動開発。コードに対して何度もテストを行うので品質が保証される |
| リリース | 完全に開発されたテスト済みの機能をリリースする | 利用可能なシステムを早期に構築し、継続的に改良を行ってゆくことを強調する |
4つの価値 †
XPでは原理となる4つの価値が存在する。
- コミュニケーション 「」
- シンプル 「シンプルな設計」「シンプルなコミュニケーション」
- フィードバック 「的確に状態を把握し、対処」
- 勇気 「コードを捨て去り、書き直す勇気」
これら4つの価値は各プラクティスに影響を与え、XPの全ての基準、指針。
プラクティス †
- 短期リリース
- 高品質なシステムを開発するにはユーザのフィードバックが必要。
- システム要件を満たしているか性格に判断できるのはシステムをリリースし実際に稼動するシステムを体験した時
- 従来の「ユーザ要件の不一致」、｢実装トラブルのトラブル｣、｢変更要求に対する要求｣を解決するために短期リリースを実践する。
- シンプル設計
- 余分な機能により複雑さが増す
- 複雑な設計は変更に弱い
- ｢システム内に重複したコードがない｣、｢システムは最小限のクラス、メソッドからなる｣といった特徴を持ち合わせtあ設計を目指す
- ペアプログラミング：
- プログラミングや設計のノウハウを教えるのは難しい
- プログラムの品質を保ち続ける事は難しい
- 一方がコーディングしている間、もう一方が入力しているコードに不適切なコードがないかチェックする。
- お互いの能力を向上しあいながらプログラミングを行う事が出来る。
- リファクタリング
- プログラムを理解しやすくなる
- バグを予防する
- メンテナンスがしやすくなる
- 対象コードが｢シンプル設計｣になるまで繰り返す
- 改良したらテストを行い動作内容に変化が無い事を確認
- コード共同所有
- コードは個人ではなくチーム全員の所有物。誰でもいつでも修正出来る
- 他の人が変更を加えている場合にりようしていると、整合性が取れなくなる場合がある→常時結合によりリスクを軽減できる
- 常時結合
- 最後にまとめて結合すると不具合の発見、修正に時間が掛かる。最後にしか動作可能なシステムが存在しない。
- 常に最新の状態に保つ
- ユーザは実装の進歩状況を随時確認できる
- テスト駆動開発
- 従来：｢実装｣→「テストを考える｣→｢テスト｣の流れ。システムの品質を保証するはずのテストが後回し＝低品質のシステムが開発される。
- XPのテスト手順：｢テストを考える｣→｢テストを作成｣→｢テストをテスト｣→｢実装｣→｢テスト｣の繰り返し
- ｢どのような機能があるか｣の質問にはテストに100％パスした機能についてだけ答えればよいので正確に進歩状況を伝えることが出来る。
- テストでコードの品質を保証する
- テストコードのないプログラムは製品コードと呼べない
