プログラミングの歩み(3) 〜リファクタリング〜

最近、リファクタリングの勉強をものすごくしています。
ものすごくってどのくらいかっていうと

• 業務でリファクタをメインでやる

• 読む本の6割くらいがリファクタリングメイン

• 自分の書いたコードに追加しながら、常にリファクタを心がける

というのを徹底するくらいにはやっています。

その際にふと思うことがあります。
こういう言葉を聞いたことがある人もいるのではないでしょうか。

「コードは書いたそばから負債になる」

これは言い得て妙で
書いた瞬間は「ベストなコードだ！」と思っても、書き終わった瞬間から刻々と負債への道を歩み続けるのである。

ただし、それはフェーズによって異なるという点が大きく、10年前のコードだから全てが負債になってる！とは言い切れないのも事実。
つまり、10年経っても、使われ方が変わらないのであれば、それは現役の負債になっていないコードであるのです。ピチピチなのです。

でも、システムというのは追加や、変更が付き物です。
変更があるということは、変更をする人がいて、変更されたコードにさらに変更を重ねる可能性があるということです。

皆さんは想像したことあるでしょうか。
100年間、継ぎ足し継ぎ足しされてきた秘伝のタレのことを。
100年の間、ただひたすら継ぎ足されるだけで、常に綺麗な器で、ゴミや虫が入ることなく、綺麗に保たれてきていると信じるような心のピュアな人はいますでしょうか。

当然そんなことはありえないので、メンテナンスが必要になります。

コードも同じものです。
10年メンテされずに継ぎ足されるだけとなったコードは、それはもう器は黒く濁り、底には害虫の死骸が蔓延り、表面だけ綺麗にされた何が入ってるとも見えなくなってるようなコードかもしれないのです。

考えるだけでゾッとしますよね。
そんな秘伝のタレ、口をつけたくないので、やはりメンテナンスは必要なんです。

定期的に器を変え、ちゃんと濾し、メンテナンスの日程などの管理も行き届き、良い環境で保管されているタレにしないといけないのです。

リファクタのことなので、コードの話になってしまってますが、開発環境にも梃子入れは絶対必要なものです。
CIであったり、ドキュメントといった周辺のメンテナンスは常に行われることが健常であるべきなのです。本来は…。

このことを頭に置いておいて、機能追加や修正の時に気づいたものをリファクタしたりすることで少しずつでも健全に戻せるといいですね。
（そのために見にくいPRになってしまっては元も子もないですが…。）