「あとで直す」は合理的に見える
Pythonを書いていると、
こう思う場面はよくあります。
- 今は時間がない
- 動いているから問題ない
- 後でまとめて直せばいい
この判断自体は、間違いではありません。
問題は、それが常態化したとき です。
「あとで」が積み重なった結果
「あとで直す」を繰り返したコードは、
次第にこんな状態になります。
- なぜこう書いたか思い出せない
- どこまでが仮実装か分からない
- 触るたびに全体を確認する必要がある
結果として、
直すはずだったコードほど、
一番壊れやすくなります。
仮のつもりが前提になる
よくあるのが、
仮で書いた処理が前提になるケースです。
# TODO: 後でちゃんと直す
result = value * 1.1
この「後で」は、
だいたい来ません。
やがてこの処理を前提に、
別のロジックが積み上がっていきます。
なぜ「あとで直す」は危険か
危険な理由はシンプルです。
- 判断の背景が消える
- 仮と本番の境界が曖昧になる
- 修正コストが時間と一緒に増える
時間が経つほど、
「直す理由」より
「触らない理由」の方が強くなります。
設計としての対処法
「あとで直す」を完全になくす必要はありません。
大事なのは、
- 仮であることを構造で分ける
- TODOをコメントではなく形で残す
- 直す前提なら影響範囲を閉じる
たとえば、
def temporary_calculation(value):
return value * 1.1
仮であることを
関数として切り出すだけでも、
後で扱いやすくなります。
作って分かったこと
このテーマから分かったのは、
- 「あとで直す」は技術ではなく判断
- 判断を残さないと設計は壊れる
- 先延ばしは構造に出る
ということです。
おわりに
この話は、
「あとで直す」という判断が、
なぜコードを壊しやすくするのかを
設計の視点で整理した記録です。
次は、
設計を先読みではなく
整理として捉える 話に進みます。
コメント