XP(エクストリームプログラミング)

■概要

XP(エクストリームプログラミング)とはアジャイル開発の代表的な手法です。
ウォーターフォールのような計画重視の開発手法とは対極で仕様変更に対しても即座に対応を行う
柔軟性の高い開発を行います。
XPの特長として初期設定よりも開発途中の設計を重視し、ドキュメント(資料)の整備よりも
コーディングとテストを重視します。

■XPの意識すべきポイント

XPで開発を行う上で意識すべきポイントがいくつかあります。
・コミュニケーション
	クライアントや開発者同士で円滑なコミュニケーションを行い
	開発しているソフトウェアに対してのイメージを合わせる
	
・シンプルさ
	「必要かもしれない」という考えで、追加の必要があるかわからない機能を
	設計に追加するのではなく、必要最低限の機能のみ設計する

・フィードバック
	常にテストを繰り返し、その結果に対しての仕様変更、バグの修正を積極的に行っていく

・勇気
	仕様変更の対応を行っていく中で必要だと思った設計変更は大幅な変更であったとしても
	リスクを恐れず行う勇気を持つ

■XP開発のプラクティス(実践項目)

XPは実践すべき項目をプラクティスと呼んでおり、
開発者の役職毎に共同・開発・管理者・顧客の4種類に分類されます。
今回は共同と開発のプラクティスを紹介したいと思います。

●共同
	・反復
		開発を反復(設計・実装・テストを繰り返す小さなサイクル)で構成します。
		開発期間を1~2週間程度で区切り、期間ごとに設計、実装、テストを行って
		半完成状態のシステムのリリースを行います。
		それを繰り返すことで完成されたシステムを構築していきます。
		この開発期間をイテレーションと呼びます。

	・共通の用語
		開発で使用する用語集を作成し、開発者全員(クライアントを含む)で
		用語の概念を統一させます。
	
	・開けた作業空間
		コミュニケーションがとりやすく、作業に集中できる環境を作ります。
	
	・回顧(ふりかえり)
		現状の状態を把握しつつ、今までのフィードバックを
		きちんと反映することを心がけて、そのための環境、体制を作ります。

●開発
	・テスト駆動開発
		実装よりも先にテストを作成し、実装はそのテストをパスすることを目標に行います。
		テストを先に作成することで機能が明確化され、シンプルな設計が可能となります。

	・ソースコードの共同所有
		誰が作ったソースコードでも断りなく修正を行います。
		ただ、コードに対する責任も全ての全員が担います。

	・継続的インテグレーション
		単体テストを通ったコードが完成したらすぐに結合テストを行い
		問題点や改善点を見つけます。
		最低でも1日1回は結合テストを行いチェックを行う内容を最新のものにしておきます。
		自動コンパイルや自動テストを行うためのPCを準備することが推奨されています。

	・YAGNI
		You Aren't Going to Need It(必要なことだけを行う)の略で、
		これは「先を見据えていろいろな機能の実装を行い、コードを複雑化させるよりも
		必要な機能のみを実装を行うべき」という考え方です。
		必要最低限のシンプルな実装を心がけ、安定性の高い機能、コードを維持し続け、
		不安定化を招くコードを限りなくそぎ落としていきます。

	・ペアプログラミング
		コーディングを二人一組で行います。一人がコードを書いて、
		もう一人がそれをチェックしながら仕様書を確認したり、
		全体構造を考えたりするなどしてフォローします。
		作業担当者の切り替えは定期的に行います。
			
		メリット:
			・怠けにくい
				二人で作業を行っていくので怠けることが難しくなり
				作業がきちんと進む可能性が高くなります。

			・コードの品質が高まる
				コードレビューを常に行っていることになるので、
				完成した際のコードはしっかりとしたコードになる
				可能性が高いです。

			・相談できる
				細かい問題や疑問などが発生した際に二人で意見を出し合いますので、
				一人で解決する場合よりも早くて良い方法が見つかる可能性が高いです。

			・二人が理解している
				コードを書いた人間が二人はいるということになるので、
				一人しか知らないコードが存在するという状況を回避できます。

			・知識の底上げ、教育的配慮
				知恵を出し合って作業が進んでいくのでアルゴリズムや実装方法などで
				自分が知らない、気づかなかった内容を知ることができます。
				新人のプログラマとベテランプログラマを組ませることで
				良い経験をつませることができます。

		デメリット:
			・能力差に対しての配慮が必要
				能力差があるペアで組ませると低い側は恩恵を受けますが、
				高い側は恩恵を受けれるとは限りません。
				新人教育などで能力差があるペアを作る場合
				能力が高い側のプログラマに意図を伝える必要があります。

			・コーディングスタイルの衝突
				コーディングスタイルが統一されていない会社などでは
				そのスタイルの違いから衝突が起こる可能性がある

			・生産性が落ちる
				2人が1つの作業を行うので1人あたりの生産性が
				落ちる可能性がありますが、ペアの相性などにより変動する可能性が
				高いの一概に下がるともいえません。

	・リファクタリング
		プログラムの外側から見た挙動は変更せず、ソースコードの内部構造を変更します。
		基本的にテストが作成されていることが前提です。

		メリット:
			・コードの品質を上昇させる
				重複したコードを削除して関数化したり、マジックナンバーが
				使用されている箇所を定数化したりすることで
				コードの品質を向上させます。
		
			・仕組みを理解しやすくする
				ネストが多くて複雑になっていたコードやコードの意図が
				読めないコードをリファクタリングすることで、
				処理の内容が整理され意図がわかる様になります。
		
			・バグが見つかる(バグになりそうな箇所が見つかる)
				コードを整理することでたまたま見つかっていなかったバグや
				バグが発生する可能性があるコードを見つけることができます。
		
		デメリット:
			・周りの理解を得辛い
				きちんと動いている箇所に手を入れることになりますので、
				周囲から修正許可が出づらいです。
		
		リファクタリングの内容:
			・関数化
				重複しているコードや長すぎる関数を細分化して関数化します。
		
			・クラス化
				1つのクラスが大きくなりすぎている場合、
				そのクラスを分割できないか検討します。
				新しいクラスが作成できるようならクラスを分けます。
				
			・クラス、関数、変数の名前を変える
				クラス名、関数名、変数名が正確かどうかを
				検討して異なるものがあるなら変更します。
			
			・マジックナンバーを定数にする
				マジックナンバーが使用されている箇所を調べ、定数に変更します。

		リファクタリングの注意:
			・複数の変更を一度に行わない
				リファクタリングを一気に行うことは危険です。
				修正の結果に問題があった場合、大規模のロールバックを
				行わなければいけません。
				リファクタリングを行う場合、関数化が完了したり、
				クラス化が完了したらそのタイミングで
				デバッグを行う必要があります。

		リファクタリングは実装を行いながらやるのではなく、
		実装が一区切りした段階で行うなど、実装とリファクタリングの区切りを
		つけて行った方がスムーズに進行します。
		行うタイミングですが、比較的安全なタイミングは
		バグチェック前、機能追加前などの変更後に
		規模の大きいデバッグが行われるタイミングで実行すると、
		もし問題があった場合でもバグが見つかる可能性が高いので
		変更のリスクを下げることができます。