この記事は「「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022」の参加記事になります。
レガシーの定義と終わらない戦い
まず、前提としてレガシーの定義を確認したいと思います。
レガシー(legacy)とは英語で資産・遺産という意味であり、レガシーシステムとは典型的には、まだユーザーが必要とする機能を持つが、現在可能な、より新しい技術やより効率的な技法ではないシステムのことである
含意が広いですね。
見てわかる通り、レガシーなシステム・アプリケーションと言う言葉は明確な定義を持っていません。
言ってしまえば、現在の技術/手法によって"レガシー"状態を脱したとしても、それ以降の何処かのタイミングではレガシーとなってしまう可能性があります。
単純に開発手法の問題であれば、"放置"という選択肢もなくはないですが、プラットフォームの使用期限や利用形態の変化によってシステムは変わり続ける必要に迫られます。
システムやアプリケーションが使われ続ける限り、更新続けることを考慮した作りが必要となり、"レガシーからの脱却"という状態は実現不可能。もしくは時限的な状態に思えます。
なので、正しい表現・一つのゴールとしては「レガシーからの脱却がより容易な状態にしておく」というところだと考えています。
テストに対する信頼性の確保
レガシーの話題が出ると、大抵出てくるのが「自動テストがない」という話です。
自動テストがあることによって、リファクタリングをしてもそれら自動テストによって、それまでの仕様が変更されていないことが保証されるというもの。
または、テストを仕様と考え、技術刷新の際には同様のテストを通すことでバージョン間の差異を明らかにするということができます。
では、そのテストが仕様を満たしているかはどうやって信頼/保証するのでしょう
一般的にはこれらはカバレッジ分析によって表現されることが多いです。
しかし、カバレッジも万能ではなく、単純なコードカバレッジだけでなく条件網羅を厳密に考えるのであれば非常にパターン数が増加し、どこかのタイミングではテストコードを書くことが非常に非効率な状態が生まれます。
逆に言えば網羅可能なサイズに納めることが非常に大事になります。
これは、いわゆるマイクロサービス的な文脈に近づきますが、マイクロサービスに限らず、充分にテスト可能な状態を保つという形が大事です
そういうテストが備わって初めて、レガシーからの脱却準備が整ったと言えるのかもしれません
優先順位をつける
とは言っても、対象となるシステムのボリュームによっては必ずしもすべてを網羅する必要はないのではないかとも考えています。
正確に言えば優先順位をつけるわけですね。
費用対効果を考えた場合、たとえ機能的に重要な位置づけのモジュールであったとしても、充分に時間が過ぎていて安定しているのであれば優先順位は低いでしょう。
その代わり、変更頻度が高い場所。
継続的に改良が加えられたり、新機能の開発が行われているモジュールに関しては優先度を上げて取り組むべきなのだと考えています。
多くの場合、経営層から見たときに仕様が変わらない変更。つまりリファクタリングによる内部的な価値の想像に対して工数を用いるより、新たな機能を追加することでの価値創造のほうがプライオリティが高いです。
このバランスをしっかりとり、お互いが原理主義者のような論調にならないような提案・調整をしていかなければなりません。
最後に
なんだか随分と教科書的な内容になってしまいました。
過去に、テストが大事と言いながらも納期や度重なる仕様変更に見舞われて自動テストを何度もおざなりにしてしまったことがあります。
あの時はしょうがなかったんだ、なんて言うつもりはありませんが、当時を思い起こしながら反省を含めて書いてみました。
完全に自分への自戒になってしまった・・・