🦔

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

1 min read

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 開発者にとって読みやすくなり、その後の開発スピードが上がる
  • 開発者にとって読みやすくなり、その後の開発品質があがる
  • 開発者にとって読みやすくなり、属人化が減る(誰でもタスクを引き継げる)
  • スピードと品質が上がることで、外部環境の変化に対応しやすくなる(顧客の利益につながる)
  • リファクタリングでコードを読み返すことにとってバグが減る
  • 有事のトラブルの際に対応が早くなる
  • プログラムの動くスピードが早くなる

などなど

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

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

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

プログラミングの原則の1つ「ボーイスカウトの原則」が素敵すぎた

リファクタリングの注意点

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

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

終わりに

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

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

Discussion

ログインするとコメントできます