「修正しやすい」とはどういう状態か
Pythonを書いていると、よく聞く言葉があります。
「このコード、修正しやすいですね」
けれど、
何がどうなっていると「修正しやすい」のかを
はっきり説明できることは、意外と少ないものです。
この話では、
実務や実践を通して感じた
修正しやすさの正体 を整理してみます。
動くことと、修正できることは別
まず前提として、
- 動くコード
- 修正しやすいコード
は、同じではありません。
動くコードは、
「今の条件」を満たしているだけです。
修正しやすいコードは、
条件が変わることを前提にしている
という違いがあります。
修正しづらいコードの共通点
これまで困ったコードを振り返ると、
共通点がありました。
- どこを直せばいいか分からない
- 1か所直すと別の場所が壊れる
- なぜそう書かれているか分からない
コード自体が難しいというより、
意図が見えない 状態です。
修正しやすいコードの特徴
逆に、修正しやすいコードには
いくつかの特徴があります。
- 役割ごとに分かれている
- 名前を見れば何をしているか分かる
- 変更点が局所的で済む
たとえば、
def calculate_total(rows):
return sum(int(r["value"]) for r in rows)
この関数は、
- 何をするか
- どこを直せば挙動が変わるか
がはっきりしています。
修正しやすさは「構造」で決まる
修正しやすさは、
書き方の上手さではありません。
- 処理の流れ
- 責任の分け方
- 情報の持たせ方
といった 構造 で決まります。
コメントを増やしても、
if文を工夫しても、
構造が曖昧だと修正は怖いままです。
設計と呼べる一番小さな単位
「設計」と聞くと、
大げさに感じるかもしれません。
ですが、
- この関数は何を責任として持つか
- どこから先は別の処理か
を決めるだけでも、
それは立派な設計です。
修正しやすさは、
こうした 小さな判断の積み重ね で生まれます。
作って分かったこと
このテーマを振り返って分かったのは、
- 修正しやすさは結果ではなく前提
- 「あとで直す」は構造を濁らせる
- 曖昧さは時間差で問題になる
ということです。
おわりに
この話は、
「修正しやすいコードとは何か」を
自分なりに言語化してみた記録です。
次からは、
この考え方を前提にして、
- 状態
- 責任
- 境界
といったテーマを、
もう少し具体的に掘っていきます。


コメント