🦔

汚いコードは後で直せばいい。

2021/08/02に公開

今回は久しぶりに自分の意見のような考え方のようなところを発信していこうかなと思います。

僕は普段、なるべくコードがきれいになるように意識して書いています。
例えば冗長なコードは書かない。コードを抽象化する。ドメインオブジェクトとデータをセットにして再利用性を高める。人が見てわかりやすい処理を書く（どうしてもかけない場合はコメント残すこともある）

挙げたらきりがないのですが、「コードをきれいにしよう！」はいろんなところでもよく言われることで意識している人は多いのではないでしょうか？

一方で技術書にはこういうことを書いていることもあります。

最初から完璧にプログラマなんていないんだから後でリファクタリングすることが大事

僕はどちらかというと結構この考え方が好きで、
最初から完璧を求めても、後から振り返るとこっちの書き方のほうが良かったよねって絶対ありますよね。だからリファクタリングしましょうよと。

しかしチームで開発する際には1つ落とし穴があると思います。

それは、**「結局、後になってもリファクタリングしてなかったわ〜〜〜〜〜」 **です。

（「後でやる」はやらないのと一緒ってことですね。）

自分がやる分には良いけど、チームのメンバーにもやってもらうのはどうすればよいか。
リファクタリングって結局最終的には顧客の利益になってないから価値を感じにくいという人もいるかもしれません。

リファクタリングの必要性

リファクタリングはめちゃめちゃ大事です。

さきほど申し上げたように、最初から完璧に作れるプログラマはいません。プログラムは常に変化していてその時に最善の選択だったものが後になってずっと最善のコードとは限りません。

では、後からリファクタリングを継続していくしかないのですが、なぜ後回しにしたら結局やらなくなっちゃうんでしょう。
個人的には必要性を感じていないからのような気がします。

リファクタリングのメリットは挙げると結構あります。

などなど

結構メリット満載です。短期的なメリットはほとんどなく、長期的なメリットばかりだからあまり目が向けられないのかな？とかやらなくてもシステム動いているからいいやって思っちゃうのかな？と思います。

リファクタリングの必要性を理解して、ぜひ継続的リファクタリングをしてください。
コードを書く時は「来た時よりも美しく！」を意識して、常に清掃活動を心がけましょう！

プログラミングの原則の1つであるボーイスカウトの原則がまさにこの考え方なので参考にしてみてください。

リファクタリングをすることで動いていたコードが逆に動かなくなることがあります。
バグがなかったところにバグを生み出す作業になってしまったら元も子もありません。

なので、ユニットテスト、結合テストなどを行い、処理が期待通りになっていることを確認しましょう。テストがないとリファクタリングは結構厳しいように思います。

今考えていることを結構雑多に書き連ねてみました。

ちゃんと文章に起こしたら結構普通なことを言っているような気もしますが、
リファクタリング＆テストの組み合わせは本当に最強だと思うので、もしまだ取り入れていないという方は早急に取り入れましょう！