順序はいつでも、バグ修正、リファクタリング、機能追加だ！
— ぎゃばん@手洗い (@ledsun) July 12, 2012
10年前と同じことを言います。 必ずでなくてもいいけど、お得な順番があります。 機能追加する前に考えなきゃいけないことを減らします。
機能追加するときにバグがあると余計なことを考える必要があります。
- 本来ならあり得ない操作だけど、バグでできちゃうから・・・
- バグだから直したいんだけど、既存の動作だから直して良いかわからないし
わかっているバグがあるなら、無理矢理なパッチであっても直してしまうのが良いです。 すくなくとも機能仕様に考えることが減ります。 減った分、よりよい機能を考えることに知恵が使えます。
ソースコードが複雑だと機能追加が難しいです。 複雑なソースコードは複雑なことを考えさせます。 引数でコールバック関数を受け取る関数がありました。 「コールバック関数で受け取るのだから、呼び出し元に寄って色々な動作をさせたいのだろう」と考えてしまいます。 呼び出し元を検索すると一種類のコールバック関数しか渡しません。 ここで「一種類のコールバック関数しかこないので・・・」と考えては行けません。 脳のリソースを消化します。 どんなにわかったつもりでも、何度も「呼び出し元に寄って色々な動作をさせたいのだろう」という考えが脳に浮かんで、新しい実装を考えるのを邪魔します。
「コールバック関数を引数からローカル変数に変える」簡単なリファクタリングをします。 それで「呼び出し元に寄って色々な動作をさせたいのだろう」は脳に浮かんでこなくなります。 機能追加の実装を考えるために使う脳のリソースが減ります。 減った分、よりよい実装を考えることに知恵が使えます。
