リファクタリングは積極的にやろう

notwoです＾＾

プロダクトを出した結果どれだけの利益が見込めるか、ということばっかりビジネス面では重要視されてるわけですが、一見利益にはならなそうなリファクタリングについて書きます。

リファクタリングしなくていいコードを書けばいいんじゃないのか？

やってみると分かりますがこれが結構難しいです。

お金を出す側からすると、お金にならないことに時間を使うな、と言いたくなってしまうようです。しかしエンジニアなら大概誰でもこのリファクタリングの重要性はわかっていて、ひどいコードを見つけたらすぐクリーンアップしたい気持ちに駆られます。ここには意見の食い違いがあるようです。

リファクタリング用の工数なんてない！

クリーンなコードばっかりにしたいけど、工数が十分にないとひどいコードでも最悪リリースしてしまいます。頭では分かっていても流れ的にそうなってしまう。その繰り返しによって殆どの人が読めないもしくは読みづらいコードが完成していきます。後になってから直そうと思っても結局直ってないということがありませんか。仕方なく直すなら、リリース直後に後追いでやりましょう。

そしてもはや周知の事実ですが...

リファクタリングは、長期的に見れば十分利益なります。開発効率が上がって、バグは減少し、プロダクトの拡張/修正にかかるコストも当然減ります。コスト削減につながります。

リファクタリング自体にはなるべく時間をかけずに、できれば新しいプロジェクトがあれば、そのついでに直すというのがクールだと思います。

余計なテストをしなくていいコードを書こうぜ

リファクタリングよりももっとお金にならないこと、あるじゃありませんか。検証(テスト)です。

それは、何度も何度も繰り返し同じテストを繰り返しやらざるを得ないコードが積み重なるに連れて無駄にエンジニア達の時間を食い潰します。

エンジニアからしてもこんなにもつまらないステップがあったものかと。理想を言うなら、やらずに済ませたいですよね´д` ;

条件分岐を減らしたり、共通化できる部分はなるだけ共通化しましょう。

もしくは、そこまで頻繁に変更がおきないと予測できるメソッドはテストコードを書い

て単体レベルで保証しておけば、神経質にテストテストテスト、って叫ぶまでもなくなるはずw

当然リファクタリングにもリスクはつきものですが、ひどいコードをもとに新機能を追加してカオスなプロダクトを世に出すよりはずっとましになりますw

最初は面倒だけど、文化が醸成されればおのずとリファクタリングが当たり前になるでしょう。

全員で協力してひどいコードを撲滅しましょ！

ではでは＾＾