はじめに
こちらのアドベントカレンダー用の記事です。
レガシーコードを無くしていくにはどうすれば良いか、基本的な部分を書いていきます。
※ 「レガシーコード改善ガイド」とかを読まれている方には物足りない内容になるかと思います。
レガシーコードとは？
テストがないコードだったり、複雑だったり、古い技術を使ってたり。
さまざまな定義がありますが、ざっくりと「イけてないコード」みたいなニュアンスで使われることが多いように思います。
レガシーコードを無くせるのか？
結論から言えば、「無くすことはできない」と言えます。
レガシーコードについて書かれた本で「できる」と書かれているものはないはずです。
なぜなら、レガシー化はコードを書いた瞬間から始まっており、たとえその時美しく完璧なコードであっても、いずれは古くなり、レガシーと呼ばれてしまうからです。
では、どうすれば良いかというと、「継続的に修正し続けられる環境を整備すること」です。
本記事では、レガシーコードをテーマにしていますが、レガシーシステムや開発手法など、技術的負債全般に共通して言える部分です。
具体的にはどうすれば良いか
では、具体的にどうすれば良いのか？
いくつか代表的なアプローチを紹介します。
テストの整備
最も基本的で、重要な部分です。
自動テストをしっかり整備することで、安心してリファクタリングや機能追加ができる環境を作ります。
テストがない状態では、コードを変更するたびに動作が壊れるリスクが生じます。
CIで自動実行できる仕組みを作っておくことも重要です。
適切なモジュール化
アーキテクチャでのアプローチモジュール化、プロジェクトの分割を適切に行うことで、部品単位でのリプレースがしやすくなります。
設計時に意識しておくことが必要ですね。
継続的に改善できる文化の定着
たとえば、スクラムで開発しているのであれば、「Sprintで実施するタスクの 20% は改善作業に費やす」などのルールを作って、継続的に改善ができる環境をつくります。
（裁量がない場合、ここが最も難しい部分ではあります。技術的負債が与える影響などを持ち出して責任者を説得していきましょう...）
番外編：マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャの考え方も、レガシー化が避けられない現実を前提としています。
例えば、あるサービスが古くなったとしても、その部分だけを置き換えることでシステム全体のレガシー化を避けることができます。そのために、サービス単位を小さくしておくことがポイントとなります。（「4日でつくり直せるくらいのサイズ」というのが１つの目安）
さいごに
レガシーコードを完全に無くすことはできませんが、残し続けてしまうと、開発のパフォーマンスやサービスに与える影響は計り知れません。
いきなり色々やるのは難しいとしても、まずは、テストコードを書くところから始めていきましょう。