（プログラムネタ）最初からやり直したい症候群
2009年06月15日10:18
作ったプログラムの構成を大々的に変更して機能追加しやすくすることをリファクタリングという。 今まであるプログラムを区分をかえたり統合したりして、動作を変更せずに構造だけ変えたりする。 でも、最近思うのだけどリファクタリングよりも最初から作り変えたほうが早いのではないか。
でも、作り直そうと思うたびに、非常にわかりやすいプログラミング技術解説の本を書くことで定評がある結城浩氏が書いた以下の日記のことを思い出した。
◇
はじめからやり直したい症候群
http://www.hyuki.com/kokoro/#hajime
（引用）
仕事がある程度の段階まで進むと、あちこちに歪みやアラが目立ってきて、全部「 はじめからやり直したい 」という気持ちが強くなってきます。これを私は「はじめからやり直したい症候群」と呼んでいます。
（中略）
もちろん、「はじめからやり直す」ことで質が向上した仕事も数多くあるとは思います。ここで言いたいのは、詳細な検討もせずに「はじめからやり直したらうまくいく」と考えるのは危険である、ということなのです。
(1997年5月22日)
（引用終わり）
◇
実は、この日記のことが常に念頭にあった。 だから今作っているプログラムを最初からやり直したくなるたびに、いやその前に詳細に検討するべきだろう、と思って思いとどまってきた。 でも、本当にそれがいいのだろうか。
今回の僕の結論は、作り直したほうが早いということだ。
理由はいくつかある。
－ リファクタリングする場合、現在のクラス構造と理想的なクラス構造の差分をとって、どのような経路を通ってリファクタリングするのか作戦を練らなければいけない。 この差分を作る作業がとても難しく、非常に時間がかかる場合がある。
－ リファクタリングした結果、不要と判明するクラスは多い。 このようなクラスがプログラム内にたくさんあると、リファクタリング時、いずれ不要になるはずのクラスであるのにそれに気がつかず、それらの取り扱いを丁寧に考えてしまい、結果的に時間を浪費してしまう。 リファクタリング中にどのクラスが必要でどのクラスが不要になるのかを分別するのは、容易でないことが多い。 最初から作り直す場合、この作業は一切省けるため、このような困難と立ち向かう必要がない。
新しく作り変えると、プログラムが半分ぐらいになってしまうことはあると思う。 そういうときに、（その「そういう時」の見極めが難しいわけだが） 理想と現状を見比べてうんうんうなっているくらいなら、作り変えたほうがいいと思う。
◇
ただし、作り直したほうが早くなるためには大きな前提条件がある。それは 設計がボトムアップになっている、ということだ。 リファクタリングするよりも最初から作り変えたほうが完了が早くなるためには、プログラム内でのそれぞれの機能が完全に部品として分離しており、分離した部品のほうはまったく手付かずですむようになっている必要がある。 たとえばソケット通信部とか、HTTPサーバー実装部・暗号処理実装部という風なそれぞれの機能が、アプリケーションのロジックと無関係なものとしてきちんと自立しており、アプリケーションのロジックと完全に分離していることだ。
こうなっていないと、作り変えたときに、まったく同じものをもう一度実装することになってしまうので、無意味に時間がかかるのだ。
「プログラム内部の分離がよい」ということは、リファクタリングが限界まで完了している、ということでもある。 つまり、初期の段階で「最初からやり直したい」と考えるのは、たいていは間違いなのだろう。
しかし、リファクタリングだけでプログラムの改善を行うことには、一定の限界がある、ということも忘れてはいけない、と思った。
でも、作り直そうと思うたびに、非常にわかりやすいプログラミング技術解説の本を書くことで定評がある結城浩氏が書いた以下の日記のことを思い出した。
◇
はじめからやり直したい症候群
http://www.hyuki.com/kokoro/#hajime
（引用）
仕事がある程度の段階まで進むと、あちこちに歪みやアラが目立ってきて、全部「 はじめからやり直したい 」という気持ちが強くなってきます。これを私は「はじめからやり直したい症候群」と呼んでいます。
（中略）
もちろん、「はじめからやり直す」ことで質が向上した仕事も数多くあるとは思います。ここで言いたいのは、詳細な検討もせずに「はじめからやり直したらうまくいく」と考えるのは危険である、ということなのです。
(1997年5月22日)
（引用終わり）
◇
実は、この日記のことが常に念頭にあった。 だから今作っているプログラムを最初からやり直したくなるたびに、いやその前に詳細に検討するべきだろう、と思って思いとどまってきた。 でも、本当にそれがいいのだろうか。
今回の僕の結論は、作り直したほうが早いということだ。
理由はいくつかある。
－ リファクタリングする場合、現在のクラス構造と理想的なクラス構造の差分をとって、どのような経路を通ってリファクタリングするのか作戦を練らなければいけない。 この差分を作る作業がとても難しく、非常に時間がかかる場合がある。
－ リファクタリングした結果、不要と判明するクラスは多い。 このようなクラスがプログラム内にたくさんあると、リファクタリング時、いずれ不要になるはずのクラスであるのにそれに気がつかず、それらの取り扱いを丁寧に考えてしまい、結果的に時間を浪費してしまう。 リファクタリング中にどのクラスが必要でどのクラスが不要になるのかを分別するのは、容易でないことが多い。 最初から作り直す場合、この作業は一切省けるため、このような困難と立ち向かう必要がない。
新しく作り変えると、プログラムが半分ぐらいになってしまうことはあると思う。 そういうときに、（その「そういう時」の見極めが難しいわけだが） 理想と現状を見比べてうんうんうなっているくらいなら、作り変えたほうがいいと思う。
◇
ただし、作り直したほうが早くなるためには大きな前提条件がある。それは 設計がボトムアップになっている、ということだ。 リファクタリングするよりも最初から作り変えたほうが完了が早くなるためには、プログラム内でのそれぞれの機能が完全に部品として分離しており、分離した部品のほうはまったく手付かずですむようになっている必要がある。 たとえばソケット通信部とか、HTTPサーバー実装部・暗号処理実装部という風なそれぞれの機能が、アプリケーションのロジックと無関係なものとしてきちんと自立しており、アプリケーションのロジックと完全に分離していることだ。
こうなっていないと、作り変えたときに、まったく同じものをもう一度実装することになってしまうので、無意味に時間がかかるのだ。
「プログラム内部の分離がよい」ということは、リファクタリングが限界まで完了している、ということでもある。 つまり、初期の段階で「最初からやり直したい」と考えるのは、たいていは間違いなのだろう。
しかし、リファクタリングだけでプログラムの改善を行うことには、一定の限界がある、ということも忘れてはいけない、と思った。
コメント一覧
クレ 2009年06月16日 00:20
プログラムに限らず、参考になる人生訓のようですねえ。
リセットしてしまうのが一番簡単そうに思えてしまいますものねえ。
リセットしてしまうのが一番簡単そうに思えてしまいますものねえ。
おかあつ 2009年06月16日 00:21
やり直せるものはやり直したほうがいいですが、人生、やり直しのきかないものが多いわけでして．．．
