『レガシーコードからの脱却』
2019/9出版
新しいねmrsekut.icon
買ってない、読んだことない
この本では最初にレガシーコードがビジネス及ぼす影響の大きさについて述べられ、レガシーコードを防ぐための多くのプラクティスの「なぜ必要なのか？」を解説しつつ幅広く紹介した内容となっています。
デザインパターン、テスト駆動開発、リファクタリングといったコーディングのパターンの紹介に加えて、チームで実践すべきアジャイル開発に関することにも多く触れられていました。ref 1章 何かが間違っている
1.1 レガシーコードとは何か？
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.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.2 コミュニケーションと協働
8.3.1 ペアリングのメリット
8.3.2 どうやってペアを組むか
8.3.3 誰とペアを組むか
8.5 スパイク、スウォーム、モブ
8.5.1 スパイク
8.5.2 スウォーミング
8.5.3 モブ
8.6 タイムボックスの中で未知を探求する
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.1 テスト駆動開発はQAの代わりではない
10.2.2 ユニットテストは万能ではない
10.3 良いテストを書く
10.3.1 テストではない
10.3.2 ふるまいの集合体
10.4 テスト駆動開発はすばやいフィードバックをもたらす
10.5 テスト駆動開発はリファクタリングをサポートする
10.6 テスト可能なコードを書く
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 本章のふりかえり
14章 レガシーコードからの学び
14.1 もっと良く速く安く
14.2 不要な出費はしない
14.3 まっすぐで狭いところを歩く
14.4 ソフトウェア職のスキルを高める
14.5 アジャイルの向こうへ
14.6 理解を体現する
14.7 成長する勇気