レガシーコードからの脱却ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

2019年11月16日

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

オライリー・ジャパン

著者：David Scott Bernstein
訳者：吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士

本書への推薦の言葉
序文
訳者まえがき
はじめに
目次

第Ⅰ部レガシーコード危機
1章何かが間違っている
1.1 レガシーコードとは何か？
1.2 滝（ウォーターフォール）に流される
1.3 一か八かの勝負
1.4 なぜウォーターフォールは機能しないのか？
1.4.1 レシピと公式
1.4.2 開発とテストの分離
1.5 「プロセス」が「忙しい仕事」になるとき
1.6 ガチガチのマネジメント
1.7 ここにドラゴンがいる
1.8 未知を見積もる
1.9 素人業界
1.10 本章のふりかえり

2章 CHAOSレポート再考
2.1 CHAOSレポート
2.1.1 成功
2.1.2 問題あり
2.1.3 失敗
2.2 スタンディッシュレポートの誤り
2.3 プロジェクトがなぜ失敗するのか
2.3.1 コードの変更
2.3.2 蔓延
2.3.3 複雑性の危機
2.4 失敗のコスト
2.4.1 ここにも10億ドル、あそこにも10億ドル
2.4.2 新しい研究、相変わらずの危機
2.5 本章のふりかえり

3章賢人による新しいアイデア
3.1 アジャイルに入門する
3.2 小さいほどよい
3.3 アジャイルを実践する
3.4 芸術と技能のバランスを保つ
3.5 アジャイルがキャズムを超える
3.6 技術的卓越性を求める
3.7 本章のふりかえり

第Ⅱ部ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
4章 9つのプラクティス
4.1 専門家が知っていること
4.2 守破離
4.3 第一原理
4.4 原則となるために
4.5 プラクティスとなるために
4.6 原則がプラクティスをガイドする
4.7 予測か対応か
4.8 「良い」ソフトウェアを定義する
4.9 9つのプラクティス
4.10 本章のふりかえり

5章プラクティス1 やり方より先に目的、理由、誰のためかを伝える
5.1 やり方は言わない
5.2 やり方を目的に転換する
5.3 プロダクトオーナーにいてもらう
5.4 ストーリーで目的、理由、誰のためかを語る
5.5 受け入れテストに明確な基準を設定する
5.6 受け入れ基準を自動化する
5.7 実践しよう
5.7.1 プロダクトオーナーのための7つの戦略
5.7.2 より良いストーリーを書くための7つの戦略
5.8 本章のふりかえり

6章プラクティス2 小さなバッチで作る
6.1 小さなウソをつく
6.2 柔軟に進める
6.3 ケイデンスがプロセスを決める
6.4 小さいことはよいこと
6.5 分割統治
6.6 フィードバックサイクルを短くする
6.7 ビルドを高速化する
6.8 フィードバックに対応する
6.9 バックログを作る
6.10 ストーリーをタスクに分解する
6.11 タイムボックスの外側を考える
6.12 スコープを管理する
6.13 実践しよう
6.13.1 ソフトウェア開発を計測する7つの戦略
6.13.2 ストーリーを分割する7つの戦略
6.14 本章のふりかえり

7章プラクティス3 継続的に統合する
7.1 プロジェクトの鼓動を確立する
7.2 完了と、完了の完了と、完了の完了の完了が違うことを知る
7.3 継続的にデプロイ可能にする
7.4 ビルドを自動化する
7.5 早期から頻繁に統合する
7.6 最初の一歩を踏み出す
7.7 実践しよう
7.7.1 アジャイルインフラストラクチャーの7つの戦略
7.7.2 リスクを減らす7つの戦略
7.8 本章のふりかえり

8章プラクティス4 協力しあう
8.1 エクストリームプログラミング
8.2 コミュニケーションと協働
8.3 ペアプログラミング
8.3.1 ペアリングのメリット
8.3.2 どうやってペアを組むか
8.3.3 誰とペアを組むか
8.4 バディプログラミング
8.5 スパイク、スウォーム、モブ
8.5.1 スパイク
8.5.2 スウォーミング
8.5.3 モブ
8.6 タイムボックスの中で未知を探求する
8.7 コードレビューとレトロスペクティブのスケジュールを立てる
8.8 学習を増やし、知識を広げる
8.9 常にメンター、メンティーであれ
8.10 実践しよう
8.10.1 ペアプログラミングの7つの戦略
8.10.2 レトロスペクティブの7つの戦略
8.11 本章のふりかえり

9章プラクティス5 「CLEAN」コードを作る
9.1 高品質のコードは凝集性が高い
9.2 高品質のコードは疎結合である
9.3 高品質のコードはカプセル化されている
9.4 高品質のコードは断定的である
9.5 高品質なコードは冗長でない
9.6 コード品質が私たちを導いてくれる
9.7 明日のベロシティのために今日品質を上げる
9.8 実践しよう
9.8.1 コード品質を上げる7つの戦略
9.8.2 保守しやすいコードを書く7つの戦略
9.9 本章のふりかえり

10章プラクティス6 まずテストを書く
10.1 テストと呼ばれるもの
10.1.1 受け入れテスト = 顧客テスト
10.1.2 ユニットテスト = 開発者によるテスト
10.1.3 それ以外のテスト = QAテスト
10.2 QA
10.2.1 テスト駆動開発はQAの代わりではない
10.2.2 ユニットテストは万能ではない
10.3 良いテストを書く
10.3.1 テストではない
10.3.2 ふるまいの集合体
10.4 テスト駆動開発はすばやいフィードバックをもたらす
10.5 テスト駆動開発はリファクタリングをサポートする
10.6 テスト可能なコードを書く
10.7 テスト駆動開発は失敗することがある
10.8 テスト駆動開発をチームに広める
10.9 テストに感染する
10.10 実践しよう
10.10.1 優れた受け入れテストのための7つの戦略
10.10.2 優れたユニットテストのための7つの戦略
10.11 本章のふりかえり

11章プラクティス7 テストでふるまいを明示する
11.1 レッド/グリーン/リファクタ
11.2 テストファーストの例
11.2.1 テストを書く
11.2.2 コードをスタブアウトする
11.2.3 ふるまいの実装
11.3 制約を導入する
11.3.1 テストを書いてコードをスタブアウトする
11.3.2 ふるまいの実装
11.4 作ったもの
11.5 テストは仕様だ
11.6 完全であれ
11.7 テストを一意にする
11.8 コードをテストでカバーする
11.9 バグにはテストがない
11.10 モックを使ったワークフローテスト
11.11 セーフティネットを作る
11.12 実践しよう
11.12.1 テストを仕様として使うための7つの戦略
11.12.2 バグを修正する7つの戦略
11.13 本章のふりかえり

12章プラクティス8 設計は最後に行う
12.1 変更しやすさへの障害
12.2 持続可能な開発
12.3 コーディング対クリーニング
12.4 ソフトウェアは書かれる回数より読まれる回数のほうが多い
12.5 意図によるプログラミング
12.6 循環複雑度を減らす
12.7 生成と利用を分離する
12.8 創発する設計
12.9 実践しよう
12.9.1 創発設計をマスターする7つの戦略
12.9.2 コードをクリーンにする7つの戦略
12.10 本章のふりかえり

13章プラクティス9 レガシーコードをリファクタリングする
13.1 投資か負債か？
13.2 怠け者になる
13.3 コードの変更が必要なとき
13.3.1 既存コードへのテストの追加
13.3.2 良い習慣を身に付けるために悪いコードをリファクタリングする
13.3.3 不可避なことを先送りする
13.4 リファクタリングのテクニック
13.4.1 ピンニングテスト
13.4.2 依存性の注入
13.4.3 ストラングラーパターン
13.4.4 抽象化によるブランチ
13.5 変化に対応するためのリファクタリング
13.6 オープン・クローズドにリファクタリングする
13.7 リファクタリングで変更しやすさを確保する
13.8 2回めは適切にやる
13.9 実践しよう
13.9.1 リファクタリングから価値を得るための7つの戦略
13.9.2 いつリファクタリングを行うかについての7つの戦略
13.10 本章のふりかえり