プログラムを書き直すべき時
とは逆方向な意見を書いていこう。というのも僕自身は結構な回数で書き直してきた人間で、おおよそはいい結果になっているからだ。
そもそもブログで「９割」というのはなにかしら統計をとったのかな？と思ったけど主観的な数値っぽいのであんまりそれはよくないかなと思っているが、まぁ細かいことだろうむしろ「ほどんどの結果で間違い」と言われると僕はそうでないと思うので、やっぱり反対の方向である。
そもそも、元のブログを読むと「コードが汚いから」とか書いてあった。「なにかいてあるかわからない」とかあるので、たぶん僕がプログラムを書き直したきっかけとは異なる状況な気がする。その状況ではおそらく失敗するだろう。だが、しかし、書き直しが有効な手である場合も多くあるので、「ほとんど」や「九割」と言ってしまうと、書き直しダメぜったいになる風潮はいやなのでやはり、選択肢にはちょっと入るべきなので、そのことについて書いていこう。
たまに時々、書き直さざるを得ない時がたくさんあった。たとえば、そもそもライブラリが古くなりすぎて動かなくなったり、別の言語とかでより良いライブラリがあって、そっちのほうに移行したりとかね。その場合いったん古い設計を見直して、新しいライブラリを考えつつ書き直していく。この場合は、書き直さないって選択肢がないので、あまり参考にならないかもしれない。
意味が分からないというより、このままだと絶対にまずいってときもある。コードは確かによく動くんだけど、でも、もっとこうしたら、早くなったり、コードの量が短くなるみたいな、「読みやすくする」などの主観的ではなきう、ある程度客観的な提案ができるときに書き直したりする。だいたいうまくいってるので、すごくよかった。
とここまでかいてふと思ったのが、そもそも書き直し方が悪いだけかもしれない。もし、テストがなければ、テストをまず書くことからやるべきだし、全部一から構築するというよりも、そもそも古い実装をあるていど参考にして、新しくより良い方向に改善していくというやりかたで、書き直すってことがある。ある意味、リファクタリングに近いことをよくやるのだ。一つのプログラムに責務が集中しているのであれば分離し、単一の責務にもっていくようにしたりするとかね。
そもそも、元のブログも僕の意見と似たようなことがかいてあった。
ここで取るべき行動は、注意深く辛抱強くコードを読み、解きほぐし、チームメンバやテックリードに相談し、リファクタリングすることだ。安易に「書き直す」なんて言ってはならない。少なくともそこに「何書いてあるか分かるまで」書き直すなんて言えないはずだ。
よくよく考えたら、僕がやっていることはリファクタリングなだけで、書き直しとは言えないかもしれない。でも、書き直しとリファクタリングの違いってなんだ？
