レガシーコードからの脱却

―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

[cover photo]
TOPICS
Business/Essay
発行年月日
PRINT LENGTH
300
ISBN
978-4-87311-886-4
原書
Beyond Legacy Code
FORMAT
Print PDF EPUB
Ebook
3,190円
Ebookを購入する
Print
3,190円

レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。このようなコードの保守と管理には多大な労力がつぎ込まれることになります。しかも一度作ってしまったレガシーコードの質を上げるには、初めから質の高いコードを作るよりも膨大なコストがかかります。
本書では、ソフトウェア開発において、初めからレガシーコードを作りださないためのプラクティスを9つ挙げて解説します。プロダクトオーナーは目的を語り、やり方は開発者に任せること、小さなバッチで開発を進めること、継続的に統合すること、チームメンバーで協力することなど、日々の開発に取り入れる考え方と具体的な実践について各章で分かりやすく解説します。
信頼性や拡張性が高いソフトウェアをリリースしたい開発者、運用管理者、マネージャに必携の一冊です。

正誤表

ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正が施されている場合がありますので、書籍最終ページの奥付でお手持ちの書籍の刷版、刷り年月日をご確認の上、ご利用ください。

正誤表


第2刷までの正誤表
2019年10月28日更新

・p.78 5行目
【誤】注目するすることに
【正】注目することに

・p.121 7行目
【誤】コンサルタントして
【正】コンサルタントとして

・p.125 15行目
【元】アリスター・コーバーンとローリー・ウィリアムの論文「The Costs and Benefits of Pair Programming(ペアプログラミングのコストと利益)」によると、2人のプログラマーが一緒に働いているからといって、1人の仕事を2人でやっているわけではない。チームの全体の生産性が50%低下するわけではないのだ。
【新】アリスター・コーバーンとローリー・ウィリアムの論文「The Costs and Benefits of Pair Programming(ペアプログラミングのコストと利益)」では、ペアプログラミングによってチームの生産性が半分になるわけではないことを報告している。1人分の仕事を2人でやっているわけではないからだ。

・p.137 9行目
【誤】満足した気分に味わえる
【正】満足した気分を味わえる

・p.146 17行目
【誤】壊れた結果が帰ってくる
【正】壊れた結果が返ってくる

・P.172 下から5行目
【誤】ブログを書いたりトレーニングを教えたりするには、
【正】ブログを書いたりトレーニングで教えたりするには、

・P.179 下から6行目
【誤】合格するのに十分はコードを書くことで機能を作る
【正】合格するのに十分なコードを書くことで機能を作る

・P.238 1行目
【元】作り直すより安い場合
【新】作り直すより安いとき

目次

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

第Ⅰ部 レガシーコード危機

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 本章のふりかえり

14章 レガシーコードからの学び
    14.1 もっと良く速く安く
    14.2 不要な出費はしない
    14.3 まっすぐで狭いところを歩く
    14.4 ソフトウェア職のスキルを高める
    14.5 アジャイルの向こうへ
    14.6 理解を体現する
    14.7 成長する勇気

参考文献
索引