コードを組み替えたい欲に打ち勝って、コードを組み続けるか。あるいはコードを組み替えるか。
はじめに
私は、リファクタリングが好きです。
コードの組み直しとプログラム構造の解析が好きなので、開発途中でコードを直さないという選択肢は「ありえない」と思っていました。
しかし個人開発では、この組み直しが工数を無限化する可能性があることが分かってからは、リファクタリングをやめ、まずゴール（組み切る）を目指すことにしました。
短期間の開発では組み替える必要が無い限り、組み替える欲を抑え、まずは作り切る（MVP: Most Viable Product）。特に、売れるかどうか分からないなら、組み直す時間を惜しんで市場性を先に試すためにも、最小限の機能を実装したプロトタイプの完成を優先します。
短期間の開発なら組み換えたい欲を我慢する
（特に個人開発で、作ったアプリまたはゲームに採算が見込めないなら）
今あるコードで最善を尽くす方が良いと思います。自分が創ったであろう処理なり変数なりを探す時間がかかっても、その方が最小努力です。
コードを組み直したくなるのは開発中期～開発後期ですが、コードの組み直しができるのは、開発前期～開発中期かと思います。
コードを組み替える
それでもコードを組み替える場合、基本は YAGNI：You ain't gonna need it であると心に唱え、以下のようにすると良いかと思います。
モジュールの関係図を描く（To-Be）
先に、モジュール同士のあるべき姿を描きます。これは、現在のコードをあまり考慮しない、これがあるべき姿だと感じる図の方が良いと思います。（できるかどうかでなく、こうであってほしい）
現在のコードをリファクタリングする（As-Is→To-Beに近づける）
次に、先ほど描いた「あるべき姿」に従って、コードを持ってこようとしたとき、そのモデルで表現できない（当てはまらない）コードがないか考えます。
そのコードは、もしかすると先ほどの図に入らない別の構造かもしれません。
先ほど書いた「あるべき姿」にできるだけ手を入れずに、自分の考慮が漏れていた部分を全体に足すために、一体どんな構造があれば良かったのか。これを繰り返すことで、全体をいくつかの小さいパーツに分けることができます。
※詳しい手法は省略します。大事な点はそこではないので…
いつリファクタリングしたらいいのか？
個人開発で、かつ短納期でプロジェクトを回す場合、リファクタリングに適した時期は、過去のコードを持ってくる時だと思います。
過去作の振り返りに時間が取れない場合、モジュールの関係図（To-Be）だけ描いておきます。
（形式は問わない、自分の近くにいる開発メンバーにプログラムの説明をする時にホワイトボードに殴り書きするようなレベルのものが良い）
例 モジュールの関係図（20分・90分タイマー）
私が描いた図はこんな感じです。（実際にこう組まれている（As-Is）でなく、こう組まれてたらいいな（To-Be）の図です）
モジュールの関係図を残しておくことで、次回作で過去のコードを持ってくる時に、現状がどうなっているか（As-Is）でなく、本当はどうしたかったか（To-Be）に基づいてコードを組み直して持ってこられます。
私自身、タイマーでは組み直しに頓挫したものの、メモを作ったことでコードを移植しやすいくなりました。
また、次回以降にこの汎用的な構造を意識することで、もう少し最初からすっきりしたコードを組めるような気がしました。
（以上）
