「触ると壊れるコード」最終回：なぜ「触ると壊れるコード」になるのか

「1行しか変えてないのに…」

実務あるある

👉 少し修正した
👉 軽い変更のつもりだった

結果

👉 別の場所が壊れる

このシリーズでやってきたこと

ここまで

• 1行修正したら壊れた話

• グローバル変数を触ったら壊れた話

• 関数を分けたのに壊れた話

• ifを追加したら壊れた話

• 共通化したら壊れた話

• 状態を共有したら壊れた話

を見てきました。

一見、全部バラバラ

でも実は

👉 全部同じ構造です

共通していたもの

それは

👉 影響範囲が見えていない

例えば第1回

timeout=1

👉 1行変更しただけ

でも

👉 別処理の暗黙の前提を壊している

第2回

retry_count = 5

👉 一部だけ変更したつもり

でも👇

👉 他の処理も変わった

第4回

if is_sale:

👉 条件を追加しただけ

でも👇

👉 別条件まで壊れた

第5回

MAIL_SUBJECT

👉 共通化しただけ

でも👇

👉 片方の修正が全体に効いた

第6回

preview_filters = filters

👉 一時変更のつもり

でも

👉 本検索まで変わった

🔥 ここが本質

「触ると壊れるコード」は

👉 コード量が多いから壊れる

ではありません。

本当に怖いのは

👉 どこに影響するか分からないこと

つまり

• 状態が見えない

• 依存が見えない

• 条件が見えない

• 責任が見えない

これが積み重なると

👉 「触ると壊れるコード」になります

実務で起きること

• 修正が怖い

• レビューで止まる

• 誰も触れない

• 属人化する

• バグ修正で別バグ発生

👉 全部同じ構造です

このシリーズで一番伝えたかったこと

Pythonは

👉 「動けばOK」

で書こうと思えば書けます。

でも実務では

👉 “変更しても壊れない”

の方が圧倒的に重要です。

今日のポイント

👉 設計 = 影響範囲を小さくすること

📚 もう一歩深く理解したい人へ

今回のシリーズに近い内容をもっと深く学びたい人へ

• Effective Python 第3版
  👉 Pythonで“壊れにくいコード”を書く考え方がかなり学べます

• Clean Architecture 達人に学ぶソフトウェアの構造と設計
  👉 「依存」「責任」「状態」をどう整理するか理解しやすいです

※上記リンクはアマゾンアソシエイトを利用しています

最後に

「触ると壊れるコード」は

👉 技術力が低いから

ではありません。

多くの場合

👉 構造の問題です。

ここまで読んで、

👉 「じゃあ実務ではどう設計するの？」

と思った方向けに、
実際に“壊れにくい構造”をどう作るかを整理しました

「Pythonで『修正しても壊れないコード』を書く技術」

• 状態をどこに持つか

• 依存をどう減らすか

• ifを増やさない設計

• “変更しても壊れにくい”構造

を、実務ベースでまとめています。

ひとこと

👉 その修正、どこまで影響しますか？