『レガシーソフトウェア改善ガイド』の感想
はじめに
以下の本を読了したので感想をまとめます。
初版が2016年11月なので、約8年前に出版された本です。Xで以下のコメントを頂いて、恥ずかしながら未履修であったことに気づいて急いでポチって読んだものです。
（邦題が微妙な）「レガシーソフトウェア改善ガイド」ではリエンジニアリングの選択肢を3つ挙げていて（①リファクタリング②リアーキテクティング③ビッグリライト）、そのメタファーに沿えば 「スモールリライト」と考えても良いと思ったのでした。でもまあ、「設計変更」といえばそうですね
— Kent Ishizawa (@agnozingdays) December 18, 2024
ちなみに同じ翔泳社から『レガシーコード改善ガイド』というタイトルの書籍もありまして、非常に紛らわしいです（著者は別の人）。タイトルどうにかなりませんでしたかね？ なおこちらの『レガシーコード改善ガイド』は、かの有名な「テストのないコードはレガシーコード」という格言（？）の出典です。
本の構成
目次構成は以下のとおりです。
第1部 はじめに
第1章：レガシープロジェクトの難題を理解する
第2章：スタート地点を見つける
第2部 コードベース改良のためのリファクタリング
第3章：リファクタリングの準備
第4章：リファクタリング
第5章：リアーキテクティング
第6章：ビッグ・リライト
第3部 リファクタリングの先へ― プロジェクトのワークフローと基盤を改善する
第7章：開発環境を自動化する
第8章：テスト、ステージング、製品環境の自動化
第9章：レガシーソフトウェアの開発／ビルド／デプロイを刷新する
第10章：レガシーコードを書くのはやめよう！
第1部ではレガシーソフトウェアとは何で、どのような課題を抱えているのかを説き、それに立ち向かい改善するためには恐れとフラストレーションを克服する必要があると主張します。そのためには調査的なリファクタリングやデータ収集が有効であることを示します。
第2部ではリファクタリングを取り扱います。
必要な準備をし、候補を選定した上でリファクタリングかリライトかの意思決定を行います（第3章）。この本の原題は "Re-Engineering Legacy Software" ですが、リエンジニアリングをリファクタリング（第4章）、リアーキテクティング（第5章）、ビッグ・リライト（第6章）に分けてそれぞれの章で解説しています。
第3部は主に自動化の話が展開されます。VagrantやAnsibleを使って開発環境構築の自動化（第7章）から始めて、各環境のプロビジョニングの自動化（第8章）、デプロイの自動化（第9章）といった流れで進みます。第10章は総まとめです。
感想
この本を読んだきっかけは、以下のポストです。
リファクタリングとリアーキテクティングの中間のやつをリファクタリングと呼ぶのはよろしくないと思うのだが、何がしっくりくるだろう。リデザイン？
— yonekubo / アーキテクトの教科書 (@tyonekubo) December 17, 2024
リファクタリングの定義が「ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業」であることは多くの方が認識していると思います。しかし実態としては、この定義に当てはまらない作業がリファクタリングと呼称されることもあり、エンジニア間で認識が揃っているとは言い難いでしょう。
このモヤモヤ感を解消すべく、Kentさんに教えてもらったこの本を読んだのですが、結論を言うとだいぶスッキリしました。
第4章の本文と図から一部を引用します。
モジュール全体に対する大規模なリファクタリングを計画しているのなら、そのリファクタリングによって、そのモジュールのテストすべてが破綻することを考慮した準備が必要だ。リファクタリングを生き延びるには、それより高いレベルのテストが必要である。一般に、あなたのリファクタリングによって影響されるであろうコードよりも、モジュール構成で1 段高いレベルに、必ずテストが準備されるようにすべきだ。
ソフトウェアは入れ子構造をしており、各々の構成要素は粒度は異なりますが何らかの振る舞いをそのクライアントに提供します。つまり、固定する振る舞いのサイズによって、リファクタリングのサイズ感は異なります。
極端な話をすると、UIを変更せずにエンドユーザーに対する振る舞いを固定し、バックエンドの構造を大幅に変更したらどうでしょう？ 定義上はそれもリファクタリングですが、そう捉える人は少ないでしょう。この本でも、そのようなリエンジニアリングはリアーキテクティングとして分類しています。
マーチン・ファウラー氏の書籍『リファクタリング』でカタログ化されたリファクタリングテクニックは、図4-10で言うとユニット単位のものが多いです。ジョシュア・ケリーエブスキー氏の書籍『パターン指向リファクタリング入門』ではデザインパターンを適用したリファクタリング手法がまとめられており、図4-11で言うとモジュール単位のものがメインとなります。
それより上のコンポーネント単位（私個人的にはモジュール＞コンポーネントという捉え方がしっくりくるのですが、この辺は明確な定義が存在しないので図4-10に従います）となると、リファクタリングのサイズはかなり大きくなります。
対応するテストは結合テストです。テストピラミッドを意識したテスト戦略を取る場合、結合テストはユニットテストに比べてカバレッジ範囲が低くなります。つまり振る舞いの細部、バリエーションは（ユニットテストでカバーされている前提で）網羅されていません。
作業前後に振る舞いが変わっていないことをテストコードによって担保するというのがリファクタリングの前提事項です。そう考えると、コンポーネントという大きなものを改修するにしては、セーフティネットとしてのテストの信頼性が低くなってしまいます。
気軽に「リファクタリングしょう」という意思決定が難しいものを、通常の（？）リファクタリングと一緒に扱ってしまうことが私の抱いていたモヤモヤ感の正体だと認識しました。
あえて名前を付けるなら「再設計（リデザイン）」でしょうか。とはいえ一般認識としてはこれも含めて「リファクタリング」で通っているので、名前付けというよりも、リファクタリングサイズを意識することが重要ではないかと感じます。
本の感想というか、リファクタリングに関する散文となってしまいました。個人的には、第3部の内容を薄くして、その分第2部でもっと詳細に踏み込んでもらえたらと感じました。しかしながら、リファクタリングやリアーキテクティングという概念について解像度を上げたい、という方にはぜひお薦めしたい技術書だと思います。
ところで設計の抽象度や入れ子構造の話は、拙書『アーキテクトの教科書』の第2章で、テスト戦略やテスト対象の振る舞いの単位については第5章で述べているので参考にしてください。
いいなと思ったら応援しよう！
