レガシーソフトウェア改善ガイド

単なる延命策ではない、進化させるという発想!

コードがレガシーになるのはなぜでしょう。その要因を特定し、
コードベースの品質を上げるためには、なにをすればいいのでしょう。

本書はこれらの古くて新しい質問に真摯に答えてくれるでしょう。

単純な (でも難解な) クラスやメソッドレベルのリファクタリングから、
モジュールあるいはコンポーネント全体を視野に入れた、広い範囲のリファクタリング。
また、最終手段としてのリライトに関するノウハウ (機能低下の予防方法や回避方法、
各種データのスムーズな移行など) を示します。

また、単に手を動かすだけではなく、いつもソフトウェアをフレッシュにしておくべく、
自動化のための方法論や、そのインフラストラクチャの作り方を詳解します。

「動いているものは触るな」が鉄則のソフトウェアを、それでも要請に応じて
よりレスポンシビリティの高い、そして新機能を盛り込まれた、
メンテナンスしやすいソフトウェアへと進化させるためのノウハウを学んでください。

【目次】
第 1 部: はじめに
第 1 章: レガシープロジェクトの難題を理解する
第 2 章: スタート地点を見つける

第 2 部コードベース改良のためのリファクタリング
第 3 章: リファクタリングの準備
第 4 章: リファクタリング
第 5 章: リアーキテクティング
第 6 章: ビッグ・リライト

第 3 部リファクタリングの先へー プロジェクトのワークフローと基盤を改善する
第 7 章: 開発環境を自動化する
第 8 章: テスト、ステージング、製品環境の自動化
第 9 章: レガシーソフトウェアの開発 / ビルド / デプロイを刷新する
第 10 章: レガシーコードを書くのはやめよう!

第 1 部: はじめに
第 1 章: レガシープロジェクトの難題を理解する
第 2 章: スタート地点を見つける

第 2 部コードベース改良のためのリファクタリング
第 3 章: リファクタリングの準備
第 4 章: リファクタリング
第 5 章: リアーキテクティング
第 6 章: ビッグ・リライト

第 3 部リファクタリングの先へー プロジェクトのワークフローと基盤を改善する
第 7 章: 開発環境を自動化する
第 8 章: テスト、ステージング、製品環境の自動化
第 9 章: レガシーソフトウェアの開発 / ビルド / デプロイを刷新する
第 10 章: レガシーコードを書くのはやめよう!

テストも資料も乏しく、書いた人も残っていないコードベースを引き継いだとき、どこから手を付け、どこまで直し、いつ作り直しに踏み切るかを考えるための実践書が『レガシーソフトウェア改善ガイド』です。著者はクリス・バーチャル (Chris Birchall)、訳者は吉川 邦夫で、翔泳社の Object Oriented SELECTION の 1 冊として 2016 年 11 月に刊行されました。副題は「複合型アプリケーション時代に即した開発・保守技法」、原書名は Re-Engineering Legacy Software です。版元の紹介文は、コードがレガシーになる要因を特定し、コードベースの品質を上げるために何をすればよいかという問いに答える本と説明しています。

3 部 10 章の構成、リファクタリングからビッグ・リライトまで

目次は 3 部 10 章です。第 1 部「はじめに」は、第 1 章「レガシープロジェクトの難題を理解する」と第 2 章「スタート地点を見つける」で、取り組みの前提を整えます。第 2 部「コードベース改良のためのリファクタリング」は、第 3 章「リファクタリングの準備」、第 4 章「リファクタリング」、第 5 章「リアーキテクティング」、第 6 章「ビッグ・リライト」と、手を入れる範囲が段階的に広がる並びです。版元の紹介文も、クラスやメソッドの単位のリファクタリングから、モジュールやコンポーネント全体を視野に入れた広い範囲のリファクタリングへ進み、最終手段としてのリライトについては機能低下の予防と回避、各種データのスムーズな移行といったノウハウを示すと説明しています。第 3 部は「リファクタリングの先へ」に続けて、プロジェクトのワークフローと基盤を改善する、と題された部で、第 7 章で開発環境の自動化、第 8 章でテスト、ステージング、製品環境の自動化、第 9 章でレガシーソフトウェアの開発、ビルド、デプロイの刷新を扱い、第 10 章「レガシーコードを書くのはやめよう!」で締めくくられます。

直すか作り直すか、判断を支える技術背景

レガシーなソフトウェアに向き合うときの難しさは、コードの読みにくさそのものよりも、変更の影響範囲が見えないことにあります。外から見た振る舞いを変えずに内部の構造を整える リファクタリング は、影響を局所に閉じ込めながら少しずつ前進できる一方、モジュールの境界そのものが問題になっている場合には、構造をまたいだ組み替えが必要になります。さらに全面的な作り直しは、既存の機能を漏れなく再現し、蓄積されたデータを移すという別種の危険を抱えます。本書の第 2 部が、リファクタリングからリアーキテクティング、ビッグ・リライトへと範囲を広げる順で並んでいるのは、この費用と危険の違いを踏まえて、小さな手段から順に検討するための並びと読めます。積み上がった 技術的負債 をどの単位で返していくかを考える材料になるはずです。

開発基盤の自動化まで含めて改善したいチームに

第 3 部が開発環境や本番に至る環境の自動化を扱う点も見逃せません。手作業で組まれた環境は再現が難しく、変更を試すたびに環境の差に悩まされるため、コードを直しても安全に届けられない状態が続きます。環境の構成をコードとして管理する Infrastructure as Code の考え方や、ビルドとデプロイの自動化を取り入れると、改善を小さく繰り返せる土台ができます。版元の紹介文が、自動化の方法論とそのインフラストラクチャの作り方を詳解すると述べているのは、この部分にあたります。一方で、扱う題材は 2016 年の刊行時点の開発環境を前提としており、個々のツールの使い方は、手元で使う版の公式資料で確かめ直す必要があります。また本書はクラス単位の手技から開発基盤までを広く扱う構成のため、テストのないコードに 1 行ずつ安全に手を入れる技法を集中的に学びたい人は、目的に合う本を 設計とアーキテクチャの本の選び方 などで比べてから選ぶと回り道を減らせます。

古いシステムの保守を任され、全部を作り直したい気持ちと、止められない現実の板挟みになっている開発リーダーやエンジニアにとって、本書は打てる手を小さい順に並べて見せてくれる一冊です。コードの整理から構造の組み替え、作り直しの判断、開発基盤の自動化までを一続きで考えたいチームが、改善の進め方について共通の言葉を持つための土台として選ぶ価値があります。