おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。
工数としてはコード管理費みたいな感じで乗せるのがよさそう。
まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。
なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。
ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性かわるか？という疑問があります。
リファクタリングで保守性高いコードを導き出せる人は最初からそれなりの保守性のコード書いてるのでは？保守性オワットルコードを書く人はリファクタリングしても保守性を盛り込めないんでは？と。
保守性オワットルコードを、保守性高いマンがリファクタリングするとき、それリファクタリングの範囲ですむのか、アーキテクチャ変更になるんでは、とか。
また、コードの追加変更って、まずどこをいじくるか探して、新しいコードを既存コードに接続すると、あとはずっと同じコードをいじくり続けがちになると思います。機能開発の間に開いてるファイルは決まっているというか。
そうすると、リファクタリングの効果が出るのはどこをいじくるか探すところで、機能開発が進むと効果は薄まっていくのではという気がします。
あと、「住めば都」原理により、人間はそれなりに散らかったコードでも割と適応して、結構コードを把握できてしまって、リファクタリングの効果が構造の変化ほどは出ないんではないかというのもあり。
そして、リファクタリング効果が高い条件設定をすると、それはそのままリファクタリングができない条件にもなりがちということもあります。たとえば、コードは保守性オワットルマンが書き、それを保守性高いマンがリファクタリングに集中して構成変更していく、と。それは効果ありそうなんですが、現実には保守性高いマンは機能開発にまわされて、リファクタリングというお金を産みにくい作業にまわしてもらえないように思います。
もちろん、リファクタリングがちゃんとされているコードと書き散らしのコードでは、作業の気持ちよさが違います。ということはリファクタリングはエンジニアの精神衛生を保つ福利厚生の面が高いんではないでしょうか。
福利厚生、つまり、エンジニアに与えられる金銭以外の報酬ってことです。
ということでリファクタリングは工数とってまとめてやるんじゃなく、スキマ時間で気がついたときにやったほうがいいのではないかと思います。そしてそういったリファクタリング作業を「バグが入る可能性があるからやるな」などと言われないよう、テストをちゃんと書いてエンバグを防いで、リファクタリングできる環境を整えておきましょう、というのが現実的かなという結論でした。
