リファクタリングをするために必要なこと
駐：この文章は愚痴であって、何らかの生産的な提言を含むものではありません。
この間、HogeContentManagerとHugaContentManagerで同じコードが使われていたので、AbstractContentManagerを作ってHogeとHugaの共通部分を集約し、HogeとHugaにAbstractContentManagerを継承させた。そして、状況によって利用するものが違ったのでContentManagerInterfaceを作って、ContentManagerFactoryを実装した。とても、スタンダードに。
そうしたら、
｢どこに処理を書けばいいのか分からない｣
と言われた。どう反応すればいいのかが分からなかった。
その時僕は、｢ここに書いてください｣と簡単に答えてしまった。当然、矢継ぎ早に、｢なんで継承なんかするの｣と言われたのだけれど。
このような場合、どのように対応するのが正しいのだろうか。つまり、質問者に問われるたびに簡単なフォローをするのが正しいのか、質問者が納得するまで一から説明するのが正しいのか、あるいは、そもそもリファクタリングしてはいけなかったのか。
｢リファクタリングしない｣という選択肢を取るという事は、機能分化が一切されていないスパゲティコードをそのまま保守し、拡張するということになる。それは今後を考えると、ありえない。
では、｢リファクタリングする｣選択肢を取った時に、質問者がその時どうすればいいかを簡単にフォローし続けるという選択肢はどうだろうか。あるプログラミングパラダイムが身についていない人に対してフォローし続けることは、僕の生産性が明らかに落ちるし、質問者の生産性も落ちるだろう。
かといって、質問者が納得するまで一から説明するべきなのだろうか。そのシステムを構築する際に明らかに優位なプログラミングパラダイムがあったとして、それを知識としては知っているものの、全く身についていない人が参加しているプロジェクトがあって、あまつさえ上司だった場合、一から説明することのコストは、僕が払うべきなのだろうか。果たして、リファクタリングはそうまでして行なうべきなのだろうか。
うーん。
ここで、｢リファクタリングするなら、質問者がいる場所でコンセンサスを取りながら行なうべき｣ということを言われそうだけれども、リファクタリングの必要性は感じていても、オブジェクト指向というプログラミングパラダイムがイマイチよく分かっていなくて、3000行の関数が制御構文だけで表現されていて、かつ1枚のファイルに入っていた方が分かりやすいと考えている人に対して、オブジェクト指向的にリファクタリングすると可読性・再利用性・保守性やらなんやらが上がりますよ、と懇切丁寧に説明してその場でコンセンサスを取ったとしても、恐らくは結局、その質問者がリファクタリング後のソースコードを見て｢どこに処理を書けばいいのか分からない｣と質問してくることは容易に想像できる。
僕は、5-6年前はオブジェクト指向命みたいな感じで、ものすごく複雑なプログラム*1を書いていたような気がする。最近は、｢それって自己満足でしょ｣と自分でも思うので、できるだけ使い分けて、簡単なプログラムを書くように心がけている。要するに再利用できる仕組みはモジュール化して、再利用できる短いコードは静的関数にしてしまう。できるだけプロジェクトのメンバーが理解できるようなソースコードが必要だと痛感しているのだけれど。
ううーん。
そう、こうやって管を巻いている、今、この瞬間にもスパゲティコードが拡大再生産されている。良く分からないと思われたら、その刹那、3行で表現した関数がコピペされ、シグネチャが改変されて200行にも1000行にも膨張するのだ。
僕は、ブランチを切ってあなたはこっちに実装してください、あとで僕が実装しなおしますからと進言すべきだろうか。あるいは勇気を持ってオブジェクト指向を教えるべきだろうか。もうあきらめて、リファクタリングせず、制御構文の嵐に立ち向かうべきだろうか。
