レガシーソフトウェア改善ガイドを読んだ

(グラレコやってみました)

「レガシーソフトウェア改善ガイド」を読んだ。青いレガシーコード改善ガイドと似ているけれど、内容は別物。

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

レガシープロジェクトとは何か？という問いかけから、実際にどのようにレガシープロジェクトを改善していったらよいかが具体的に示されている。 レガシーコードに直面し、リファクタを試みたことがある人にとっては、新たな発見は正直ないかもしれない。あるある！という同感するシーンがいっぱい出て来るかも。自分はいっぱいあった。

はじめに

レガシープロジェクトの改善を始めるにあたって、まずはそのアプリケーションを計測するところからと書かれている。計測をすることで、どこをリファクタリングすべきか、どのようにリファクタリングすべきかが見えてくると。
いけてないコードを発見すると、そこをすぐにリファクタしたくなるけれど、それがそのプロジェクトにとってどれくらい価値のあるリファクタリングなのかを把握しておかないといけない。じゃないと自己満なリファクタリングになってしまう。

計測できるものはなんでも計測しておくと、それがリファクタリングの新たな発見につながると説明している。計測にはツールを使ったり、Jenkinsなどに任せて自動で定期的に計測する仕組みを作ることをオススメしてる。

レアシーソフトウェアの改善を始める

リファクタリング、リアーキテクティング、ビッグ・リライトの3つの方法を挙げて説明している。

リファクタリングについては、とにかくテストを書いて、かつ自動で実行させるようにしておこうと。リファクタの基本だね。

アーキテクチャについては、モノリス的なアーキテクチャ、FE+BE、SOA、マイクロサービスの4つのアーキテクチャを例に挙げている。それぞれのメリット、デメリットがわかりやすく書かれている。
コードやサービスを疎結合にするほど、スケーリングがしやすくなり、他のサービスに影響を及ばさない(ように正しく設計されていればの話)ため、開発がしやすくなる。ただし、各サービスで情報が孤立したり、設計やプログラミング言語が各サービスによってバラバラになっていく可能性があるため、ガイドラインを定めたり、情報共有の方法を決めておかないといけない。

そしてビッグ・リライト。レガシーコードを見つけた時によく上がる「作り直した方が早い」説。どうしようもない時の最後の手段とすべきで、もしやるのであればどうしたらリスクを低くリライトしていくかを具体的な手順が示されてるので、読んでおくと良さそう。

プロジェクトのワークフローと基盤の改善

どのようにプロジェクトを保守していくか、が具体的に書かれている。環境改善に悩んでいる人には役立つ内容かと思う。

まとめ

レガシーコードを書くのをやめよう！…と最後にまとめられているけれど、同時に自分が今書いているコードもいずれ誰かのレガシーコードになるということを忘れてはいけないとも書かれている。後に自分が書いたコードを改修する誰かのために、わかりやすい仕組み作りをする努力をし続けないといけないなあ。