システムの様々な開発手法

前回の開発手法は伝統的なものだ。
今も無視することはない。
しかしコンピュータの多岐に渡りコンパクト、少数になり現場ではスピード感が求められる。
そこで
新しい開発手法を紹介する。

# RAD（Rapid Application Development）
短期間で開発することを重要視した開発手法。
エンドユーザーと開発者による少人数構成のチームをくみ、開発支援ツールを活用する。

プロトタイプを作ってそれを評価する。それを繰り返すことで完成度が上がっていく。
しかし何回も評価していては時間がかかる。
なので開発時間を設ける。それを```タイムボックス```という。

評価する時点で固まっていない要求については開発することはない。

# アジャイルとXP（eXtreme Programming)
スパラルモデルの派生型でより早い反復単位で開発を行う。
これによって迅速に開発する手法を```アジャイル```という。
一つの機能を開発した後はソフトウェアをリリースする。

アジャイルの型の代表的な開発手法がXPだ。
少人数の開発に適用しやすい。
変更を許容する柔軟性が実現されている。
## 気づき
一つ一つの開発するから柔軟のなのかな。

## XPの５つの価値
### コミュニケーション
プロジェクトが失敗する原因の多くはコミュニケーション不足です。エクストリームプログラミングでは```開発チーム内だけでなく、顧客とのコミュニケーションも重視```します。
### シンプル
最初の設計を```極力シンプル```にします。基本的な機能だけを盛り込み、そのほかの機能が必要になれば、その都度対応します。
### フィードバック
ソフトウェア開発において、不要な機能を盛り込むのは大きな無駄となります。顧客からのフィードバックを得て、```必要な機能を洗い出す```ことが大切です。
### 勇気
最初に綿密な計画を立てないという特性上、```途中で大胆な変更が求められる```場合があります。
### 尊重
チームで開発する以上、```ほかのメンバーを尊重する```姿勢は欠かせません。
出典 https://it-trend.jp/development_tools/article/32-0023

# XPのプラクティス（実践）
## 開発プラクティス
開発プラクティスは、プログラマーなどの```開発チームを対象```としたプラクティスです。19つのプラクティスに分けられますが、それを大きな括りで分類して紹介します。

### テスト後に実装を行う「テスト駆動開発」
プログラムの実装よりも```テストコードを先に作成```することです。それにより、```求められる機能が洗い出され```、シンプルな設計が実現します。

テストの通過を目標に開発を行えば、仕様変更などによる```開発途中のブレを最小限に抑えられる```でしょう。なお、テストは```ユニットテスト```と```受け入れテスト```からなり、どちらのテストも自動化が望ましいです。

### ２人１組で行う「ペアプログラミング」
```２人１組```でプログラミングを行うことです。１人がコードを記述し、もう１人はそれを```確認・補佐```します。

記述しながら確認を行うと、細々とした```問題をその場で解決```できるメリットがあります。また、記述されたコードを把握している人物が２人いるので、その後の```問題発生時にも迅速な対応が可能```になるでしょう。

### 内部構造を整える「リファクタリング」
完成した```コードをわかりやすく書き換える```ことです。外部の動作を変えずに、内部構造だけを変更します。同じ動作をするコードでも、わかりやすいものに変換されるので、```メンテナンス性の向上や不具合の発生頻度の低下```が期待できます。

### 必要なコードだけを記述する「YAGNI」
YANGIは「You Aren't Going to Need It」の略で```「今必要なことだけをする」```という意味です。つまり、```必要なコードのみを記述```することを意味します。

開発時には、後に必要になるであろう機能を考慮して、あれこれと盛り込みたくなるでしょう。しかし、そうした思惑は外れる場合が多く、結果として無駄になります。```今必要とされるコードの記述に注力することが大切```です。

### ソースコードの共同所有
断りなく、```チーム内の誰もが修正を行う```ことができる。
```チーム全体が全てのコードに対して責任を負う```。
    出典 https://gihyo.jp/book/2020/978-4-297-11781-8

### 継続的インテグレーション
単体テストを終えたプログラムは、```すぐに結合して結合テストを行う```。
    出典 https://gihyo.jp/book/2020/978-4-297-11781-8

#### プラクティス
* テスト主導型の開発
* ペア・プログラミング
* リファクタリング
* 集団的な所有権
* 継続的インテグレーション
* YAGNI

# 管理者プラクティス
管理者プラクティスは、管理者を対象としたプラクティスです。開発が適切に進行しているのか把握し、チームで共有する必要があります。

特に、```チームの負荷が大きすぎないか常に確認```することが求められます。エクストリームプログラミングは短期間で集中して作業を行う方法であるため、過度な労働は避けなければなりません。
### プラクティス
* 責任の受け入れ
* 援護
* 四半期ごとの見直し
* ミラー
* 持続可能なペース

# 顧客プラクティス
顧客プラクティスは、その名のとおり顧客を対象としたプラクティスです。
 
エクストリームプログラミングでは、```顧客も開発に携わるチームメンバーとして扱います```。ビジネス的な視点から必要な機能を考え、```開発の優先順位を付けるのが顧客の役割```です。

具体的には、```要求機能のコンセプトを短い文章にしたストーリーの作成やリリース計画を立案```します。また、イテレーションごとに開発チームとともに受け入れテストを行い、```求めた機能が実現しているか確認```します。

#### プラクティス
* ストーリーの作成
* リリース計画
* 受け入れテスト
* 頻繁なリリース

出典　https://it-trend.jp/development_tools/article/32-0023#chapter-3

# 共通のプラクティス
関係者全員に関わる実践内容
### プラクティス
* 反復
* 共通の用語
* オープンな作業空間
* 回顧

出典 https://tracpath.com/works/devops/xp_extreme_programming/
出典 https://www.alobridge.com/blog/1112

# リバースエンジニアリング
```既存のソフトウェアの動作を解析```することで、プログラムの仕様やソースコードを導き出すこと

## 目的
```既にあるソフトウェアを再利用```することで新規開発を手助けすること。

### 気づき
分析するんだな。

## フォワードエンジニアリング
リバースエンジニアリングで得られた仕様をもとに```新しいソフトウェアを開発```する手法。

### 注意点
元となる```ソフトウェア権利者の許可なく```これを行い、新規ソフトウェアを開発・販売すると、```知的財産権の侵害```に当たる可能性があるため注意が必要。

# マッシュアップ
```公開されている複数のサービスを組み合わせる```ことで新しいサービスを作り出す手法のこと。