「レガシーソフトウェア改善ガイド」の感想

概要

レガシーなアプリケーションの改善についてヒントを得るため、読んでみました。 今の開発に使えるものがあればなーと。

https://images-na.ssl-images-amazon.com/images/I/516AmcmQGPL._SX397_BO1,204,203,200_.jpg

https://www.amazon.co.jp/dp/B01MSLAFPT/

全体的な感想

面白い。 レガシーソフトウェアの改善について、3部構成で気持ち・コード・環境の観点からアプローチを記載している。 それぞれの章だけでも、取り入れたら面白そう。

調査的リファクタリング・各種自動化はすぐにでも取り掛かった方が良いと思った。

気になった章の感想

4章 リファクタリング

コードベースで改善方法とアンチパターンが記載されている。 自分たちのモジュールで見かけたものあったりした。 ミュータブル・イミュータブルの話も出てくるが、PHPはまだイミュータブルがない…。

ユニットテストについて書いてある一方で、カバレッジユニットテストを信じすぎることについて、釘も刺している。

6章 ビッグ・リライト

レガシーアプリケーションを1から書き換える話。 開発手法から、機能追加を交えて折衝することが記載されている。

後半はDBをどうしていくかという話。 自分たちは、テーブル構造の最適化まで手を付けられていないので参考になった。

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

レガシーソフトウェアの環境を新しくしていく話。 ビルドツールを知見があるものに置き換え、CIツールで簡単にデプロイできるようにする。

ビルドやデプロイに心理的な負担を減らすことで、レガシー化を防ぐというアプローチ。 ※章の最初でレガシーソフトウェアは、デプロイ回数が少ないという話題がある。

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

自分が今書いているコードがレガシーにならないようにしようという話。 今までの統括的な内容となっている。

総評

全体として、リファクタリングが容易では無いこと・ビッグリライトやリプレイスは得策ではない事が記載されている。 恐らくビッグリライトやリプレイスという選択を取らなければ行けない時点で、状況は良くないということなのだろう。

10章でも書かれているが、継続的に修正し、自分たちのコードが腐らないようにすることが重要なのだろう。