レガシーソフトウェア改善ガイドの読書サマリ

1. こういう事態を避けるためには、更新するアプリケーション間で通知を送る必要がある

2. 目次

2.1. 第1部 はじめに

2.1.1. 1章 レガシープロジェクトの難題を理解する

2.1.1.1. 1.1 レガシープロジェクトの定義

2.1.1.1.1. まえがき

2.1.1.1.2. レガシープロジェクトの性質

2.1.1.2. 1.2 レガシーコード

2.1.1.2.1. テストされていない/テストできないコード

2.1.1.2.2. 柔軟性のないコード

2.1.1.2.3. 技術的負債を抱え込んでいるコード

2.1.1.3. 1.3 レガシー基盤

2.1.1.3.1. 開発環境

2.1.1.3.2. 過去の依存関係

2.1.1.3.3. 複数の異なる環境

2.1.1.4. 1.4 レガシーカルチャー

2.1.1.4.1. 変化が怖い

2.1.1.4.2. 知識の孤立

2.1.2. 第2章 スタート地点をみつける

2.1.2.1. 2.1 恐れとフラストレーションを乗り越える

2.1.2.1.1. 曖昧な品質改善目標よりやる気を起こせる

2.1.2.1.2. 恐れ

2.1.2.1.3. 調査的リファクタリングをやること

2.1.2.1.4. 身近な援助

2.1.2.1.5. 仕様化テスト

2.1.2.1.6. フラストレーション

2.1.2.2. 2.2 ソフトウェアについて有益なデータを集める

2.1.2.2.1. バグとコーディング規約に対する違反

2.1.2.2.2. レガシーソフトウェアの計測値を集める理由

2.1.2.2.3. まずは何を計測するかを決める必要がる

2.1.2.3. 2.3 FindBugs, PMD, CheckStyleで検査する

2.1.2.3.1. レガシーコードベースのリファクタリングのとっかかり

2.1.2.3.2. 静的解析ツールを遣うのが絶好のスタート

2.1.2.3.3. おすすめの適用順序

2.1.2.3.4. あなたのIDEでFindBugsを実行する

2.1.2.3.5. PMDとCheckstyle

2.1.2.4. 2.4 Jenkinsによる継続的インスペクション

2.1.2.4.1. IDEだけではなくCIから確認できるようにする

2.2. 第2部 コードベース改良のためのリファクタリング

2.2.1. 第3章 リファクタリングの準備

2.2.1.1. まえがき

2.2.1.1.1. 組織の目標を念頭におくべき

2.2.1.1.2. リファクタかリライト(書き直し)か

2.2.1.2. 3.1 チームのコンセンサスを培(つちか)う

2.2.1.2.1. チームプレイ

2.2.1.2.2. チーム全員から、達成ゴールと計画に対して、同意を得る必要がある

2.2.1.2.3. 伝統主義者と急進主義者の中庸が適切

2.2.1.2.4. 伝統主義者

2.2.1.2.5. 急進主義者

2.2.1.2.6. 大切なのはコミュニケーション

2.2.1.3. 3.2 組織から承認を得る

2.2.1.3.1. 正式な仕事にしよう

2.2.1.3.2. プランB: 秘密の20%プロジェクト

2.2.1.4. 3.3 候補を選ぶ(価値と難易度とリスクによる分類)

2.2.1.4.1. すべてのリファクタリングが平等ではない

2.2.1.4.2. 推奨カテゴリ (図3-2)

2.2.1.5. 3.4 決断の時(リファクタか、リライトか)

2.2.1.5.1. まえがき

2.2.1.5.2. リライトへの反論

2.2.1.5.3. 書き直しのメリット

2.2.1.5.4. 書き直しに必要な条件

2.2.1.5.5. 第3の道: インクリメンタルな書き直し

2.2.2. 第4章 リファクタリング

2.2.2.1. 4.1 規律のあるリファクタリング

2.2.2.1.1. 規律がなければ

2.2.2.1.2. 「マクベス症候群」を予防する

2.2.2.1.3. リファクタリングを、他の作業から分離する

2.2.2.1.4. IDEを頼りにする

2.2.2.1.5. VCSを頼りにする

2.2.2.1.6. ミカドメソッド

2.2.2.2. 4.2 レガシーコードの一般的な特徴とリファクタリング

2.2.2.2.1. 失効コード

2.2.2.2.2. コメントアウトされたコード

2.2.2.2.3. 死んでいるコード

2.2.2.2.4. ゾンビコード

2.2.2.2.5. 期限切れのコード

2.2.2.2.6. だめなテスト

2.2.2.2.7. ヌルの使いすぎ

2.2.2.2.8. 不必要な「ミュータブル」状態

2.2.2.2.9. 複雑怪奇なビジネスロジック

2.2.2.2.10. ビューレイヤーの複雑さ

2.2.2.3. 4.3 レガーコードをテストする

2.2.2.3.1. テストできないコードをテストする

2.2.2.3.2. ユニットテストなしのリグレッションテスト

2.2.2.3.3. ユニットテストは「銀の弾丸」ではない

2.2.2.3.4. カバレージ過敏症に注意

2.2.2.3.5. すべてのテストを自動化しよう

2.2.2.3.6. ユーザーに助けてもらおう

2.2.3. 第5章 リアーキティング

2.2.3.1. 5.1 リアーキティングとは何か？

2.2.3.1.1. メソッドやクラスよりも高いレベルで行うリファクタリング

2.2.3.1.2. 1アプリケーションを複数のコンポーネントモジュールに分割する理由

2.2.3.2. 5.2 モノリス的なアプリケーションを複数のモジュールに分割

2.2.3.2.1. 背景

2.2.3.2.2. ケーススタディ:ログ管理アプリケーション

2.2.3.2.3. スタート地点

2.2.3.2.4. 背景

2.2.3.2.5. プロジェクトの目標

2.2.3.2.6. モジュールとインターフェイスを定義する

2.2.3.2.7. ビルドスクリプトと、依存関係の管理

2.2.3.2.8. モジュール分割の苦労

2.2.3.2.9. Guiceで依存関係を注入

2.2.3.2.10. Gradleに移行

2.2.3.2.11. 結論

2.2.3.3. 5.3 Webアプリケ-ションを複数のサービスに分散する

2.2.3.3.1. 複数のサービスに分割するケース

2.2.3.3.2. 再びOrinoco.comを例として

2.2.3.3.3. アーキテクチャを選択する

2.2.3.3.4. 比較表

2.2.3.3.5. アーキテクチャを、どうするか(Orinoco.comの場合)

2.2.4. 第6章 ビッグリライト

2.2.4.1. まえがき

2.2.4.1.1. 大いなるリライトを選択するなら、ほかの選択肢をすべて試した後のことだ思いたい

2.2.4.1.2. レガシーを書き直すときの鳥肌

2.2.4.2. 6.1 プロジェクトの範囲を決める

2.2.4.2.1. プロジェクトの目標は何か

2.2.4.2.2. プロジェクトの範囲を文書化する

2.2.4.3. 6.2 過去から学ぶこと

2.2.4.3.1. 現在の実装をどの程度まで新しい実装の仕様として扱うべきか？

2.2.4.3.2. 「実装を続けるには、もっと仕様を明確にする必要がある」と気づいた時に重要となる

2.2.4.3.3. World of RuneQuest

2.2.4.3.4. 低いレベルの実装詳細と、高いレベルのソフトウェア設計およびアーキテクチャとを、区別することも重要

2.2.4.4. 6.3 データベースをどうするか

2.2.4.4.1. 既存のDBを共有する

2.2.4.4.2. DBを制御できる日のために計画を立てる

2.2.4.4.3. データベースを新規作成する

2.3. （WIP)　第3部 リファクタリングの先へ

2.3.1. 第7章 開発環境を自動化する

2.3.1.1. 7.1 「仕事を始める日」

2.3.1.1.1. UADの開発環境をセットアップする

2.3.1.1.2. 何がいけないのか

2.3.1.1.3. 粗末なドキュメンテーション

2.3.1.1.4. 自動化の欠如

2.3.1.1.5. 外部リソースへの依存

2.3.1.2. 7.2 優れたREADMEの価値

2.3.1.2.1. 効果

2.3.1.2.2. ソースコードと同じリポジトリにあるのでレビュー対象に含まれる

2.3.1.2.3. 条件

2.3.1.3. 7.3 Vargrant と Ansibleで開発環境作りを自動化する

2.3.1.3.1. Vagrantの紹介

2.3.1.3.2. VagrantをUADプロジェクト用に設定する

2.3.1.3.3. Ansibleでプロビジョニングを自動化する

2.3.1.3.4. さらにロールを追加する

2.3.1.3.5. 外部データベースへの依存性を排除する

2.3.1.3.6. 「仕事を始める日」（テイク2）

2.3.1.4. まとめ

2.3.1.4.1. READMEはリポジトリで最も重要なファイルだ

2.3.1.4.2. 新たに参加するメンバーが仕事にかかりやすいようにすれば、効率もあがる

2.3.1.4.3. プロビジョニングの効率化のためにツールを使う

2.3.1.4.4. 共有されている開発DBやその他の外部リソースに対する依存製は排除しよう

2.3.2. 第8章 テスト、ステージング、製品環境の自動化

2.3.2.1. 8.1 インフラストラクチャ自動化のメリット

2.3.2.2. 8.2 自動化を他の環境に拡張する

2.3.2.3. 8.3 クラウドへ！

2.3.3. 第9章 レガシーソフトウェアの開発/ビルド/デプロイを刷新する

2.3.3.1. 9.1 レガシーソフトウェアの開発/ビルド/デプロイにおける困難

2.3.3.2. 9.2 ツールチェインを更新する

2.3.3.3. 9.3 JenkinsによるCIの自動化

2.3.3.4. 9.4 リリースとデプロイを自動化する

2.3.4. 第10章 レガシーコードを書くのはやめよう！

2.3.4.1. 10.1 ソースコードがすべてではない

2.3.4.2. 10.2 情報はフリーになりたがらない

2.3.4.3. 10.3 われらの仕事は終わらない

2.3.4.4. 10.4 すべてを自動化せよ

2.3.4.5. 10.5 小さいのが美しい