こんにちは。
株式会社エス・スリーの開発スタッフです。
最近、2年ほど前に作成したプログラムのリファクタリングをしていました。
作業をする中で、リファクタリングの考え方は日常生活にも応用できるのではないかな、と考えて本記事を書かせていただきます。
まず、リファクタリングとは、
ウィキペディアによれば、こういう内容です。
ここに書いてあるように、実は筆者の就職したころにはあまりリファクタリングという考え方は一般的ではなかったように思います。
・現在正常に動作しているプログラムを触るべきでない。
・触って問題が発生したときに原因を上手く特定できなかったりすると収拾がつかなくなるから。
・だから、この部分だけ修正してね。
と先輩方に言われていました。
この考え方が間違っているわけではないのですが、システムの寿命が長くなるにつれ問題が出てきます。
ある修正を加える時、本当は全体的に最適な方法があったにもかかわらず、
問題の部分以外に手を触れてはいけないという制約の下で非効率な変更が積み重ねられ、継ぎはぎのプログラムへと進化してしまうのです。
これは多くのシステムで見られる、非常によく見るパターンです。
リファクタリングは、この状況を打開するために提唱されました。
問題のコードを部分的に修正するのではなく、もっと上のレベルでコードを整理し効率化します。
と、長くなりましたが、この考え方はいろんな分野で適用できそうな気がしませんか？
大体、日常の雑務で問題が発生したときに、一番考えなくても良い、かつ労力が少ない解決方法が採用される傾向があります。
例えば書類を置いている棚にファイルがいっぱいになってしまった。
この場合、良く採られる方法は、
・無理やりファイルを押し込む
・追加の棚を導入する
ではないかと思います。
しかし、本当に最適な方法を考えると、
・棚に収まっているファイルの要・不要の判定をする
・不要のものを処分し、スペースを空ける
こちらが正しいのではないでしょうか。
ただ、忙しかったり、他のことも差し迫っていたりすると前者の方法をとってしまいがちですよね。
(プログラマーも、そうです)
後者の方法がとられるのは日本では「大掃除」のタイミングが多そうです。
つまり、
リファクタリング＝大掃除 ？
年末には、システムも大掃除が必要かもしれません…
最後までお読みいただき、ありがとうございます。
