コーディングを担当している部下から、担当しているモジュールのリファクタリングをさせてくれと要求を受けることがあります。リファクタリングとはインタフェースと機能性は変えずに実装方法を変更することです。
リファクタリングという名前が付いているので、何か重要そうな作業に聞こえますが、成果物を管理している立場からすると市場で今まで動作していた実績が無くなって、作業前と作業後の機能差は全くないのに、人件費だけは立派にかかる代物なので、折角の部下の熱意にこたえることが難しい場合が多いです。
なぜリファクタリングをするのか
コーディング担当者はなぜリファクタリングがしたいと言っているのでしょうか。リファクタリングの利点としては一般的にコードの質やメンテナンス性の向上があります。これにより機能追加やバグフィクスと言ったことがやりやすくなることがあります。
過去にその人が担当したモジュールであれば、何か後ろめたいことがあるのかもしれないので、具体的に問題点を話し合ったほうが良いかもしれません。他人のコードであるのであれば、コードレビューでもさせて、分かりやすく解説してあげるのもよいです。
実装が悪いのを放置しておくのは実装者として気持ち悪いのも事実です。どうしても直したくなる気持ちはよくわかります。でも実装の綺麗さは実装者にだけしかわからなくて、実際の利用者はそんなの関係ないということも理解させてあげる必要があります。
今すぐに必要でない場合は無意味
まず考えなくてはいけないことは、今コードの質やメンテナンス性を向上させる必要があるのかということです。実際にインタフェース変更が予定されていたり、そのモジュールの不具合が多発しているのであれば、リファクタリングするべきでしょう。でもそれ以外の場合は成果の面ではほぼ無意味に終わります。
インタフェースの変更をしやすくすると言って、実際にはインタフェース変更がなかったり、そのプロジェクトごと無くなることがほとんどです。
不具合が全く起きていないモジュールをリファクタリングしたら大きな設計漏れがあって、その後大きな品質問題になることがあります。
テストが十分にできる必要がある
そもそも自動テストが充実していないと、リファクタリング後の品質を維持することはほぼ無理といってよいです。手動のテストスクリプトがそれなりにあったとしても、必ず後で問題を起こすことになります。
数千ラインのコードを修正すると、仕様を同じにしたとしても振る舞いやタイミングが変化します。その差によって別のモジュールに影響を与えて不具合になって表面化したりします。
リファクタリングが必要な開発は、一か所だけでなく全体にわたってコードが整理・整頓されていない状態でしょう。そのような品質の場合、一部を修正するリスクというのは大きくなります。
ですので、各サブモジュールのテストの自動化がされていて、常に広く評価可能にしておくことが、リファクタリングをするかしないかの大きな判断材料になります。
教育的にリファクタリングさせる
新人など担当者が未熟な場合は、リファクタリングをさせることがあります。旧実装がリファレンスになるので、分からないことがあっても調べながら自分で設計・コーディングを完了させることが出来ます。
技術力が低くても自分で実装したコードであれば、機能拡張なのどのメンテナンスもできますので、出来上がりが悪くても目をつぶってあげることも必要ですね。ただ自分で設計した気になってしまうので、要注意です。ゼロから設計する大変さとは程遠いことを理解させる必要があります。
リファクタリングが他に影響を及ぼすことも
旧実装が問題なく動作していたのに、リファクタリングをすることで実装が変わって問題が表面化することは非常に多いです。特に排他が必要な処理などインタフェース仕様書に現れていない場合に起きます。昔は排他処理が必要がなかったのに、新しい実装では排他処理を要求するとかです。
このようにリファクタリングをしたために、その他のモジュールにまで影響を及ぼし作業工数が増大することがよくあります。
リファクタリングの課題は工数だけ
合理的にビジネスだけを考えるとリファクタリングはやるべきではありません。でも開発が谷に入り工数に余裕があるときは別です。この時ばかりは積極的に課題のあるモジュールのリファクタリングに取り掛かるべきです。
実装が社員で行われている場合は、谷の場合も一日8時間拘束する場合がほとんどでしょう。こういった場合はリファクタリングの意味があります。ただ外注に出してまでリファクタリングする必要は無いはずです。
コメント