リファクタリングタスクの着手時期・やるやらの判断基準
リファクタリングの着手時期・やるやらの判断基準が判らないみたいな話があり、じゃあ言語化してみようかと言うことになりまとめたものを雑まとめとして残しておく。
(個人的な主観だったり何度も言われていることをただまとめてるだけだけど
大前提
Martin FowlerがRefactoring is a part of day-to-day programmingと述べているように、リファクタリングは日々の開発に組み込むべきものだと考えている。
「後で(何時か)やります」=「やらない」
この現象には何度も遭遇してきたから。
既存機能に手を入れることだけでなく新規開発の中でも行われるべきものであると個人的には思っているので、リファクタリングは振る舞いを変えずに内部ロジックを変えると言う手法からすると、私の考えは「リファクタリング」というよりは「改善活動」と呼ぶ方が適切かもしれない。
とは言え現実は
理想的にはいつでも自由にリファクタリングできるのが望ましいが、現実にはさまざまな制約がある。そこで迷うときにどう判断するかを整理してみる。
リファクタリングすることでのコストとリターンで判断する
リファクタリング(改善)することで必要になる工数(コスト) > それ以降に得られる工数削減(リターン)
ならリファクタリング(改善)しても良いかもねと提案、判断ができそうである。
ビジネスのコアに関わりるかどうかで判断する
コアが何かを断言するのは難しいが、競合他社のサービスと差別化されているもの(お金を生み出す源泉)は何かと言うこと、差別化のある箇所ならリファクタリング(改善)する意義はあるかもねと提案、判断ができそうである。
コアの分析するならこの辺を参考にすると良い？
参考:
ドメイン駆動設計をはじめよう
マイケル・ポーターの競争戦略
上記の2つの判断軸を参考に四象限っぽく整理してみる
上記2つの軸（コスト・リターンとビジネスコア）で四象限を作成するとこんな感じか？
やるやらの判断基準として一定使えそうかなと思いつつ、この四象限だけで判断してしまうとズレが起きてしまう可能性はあるので注意は必要そうである。
例えば以下のようなケースでは四象限では「実施不要」に分類されがちだが、実際には実施すべき場合もある。
- 競争優位性はあるか？ → これができることで売り上げ上がるとかはなさそう
- インシデント発生した場合の影響度 → 影響はあまりなさそう
実施しなくても可の範囲になってしまう
しかし次のような条件が加わると話は変わってくる。
- 今後も機能拡張で手が入っていく可能性はあるか？ → 確実にあると見込まれる
- 何もしないと実装コストはどうなるか？ → 追加する毎に右肩上がりで増えてしまう可能性がある
- 今回リファクタしたことによりかかったコストをペイできるか？ → 増加数の何処かでリターンの恩恵は得られる＆複雑性も抑えられる
となるケースはあり得るので、リスクとリターンも同時に考えて、総合的に判断すると、このタイミングで実施する意義は十分ある。
余談
どんなに綺麗に設計・実装しても、時間の経過とともにコードは負債化する可能性を避けられない。
- 業務理解の深化
- 技術的・ビジネス的な環境変化（路線変更、法改正など）
これらの要因でコードは陳腐化する。そのため「雑に書いてよい」という意味ではなく、その時点での最善を尽くすことが、将来的な痛みを最小限に抑える手段となる。
Discussion