「触ると壊れるコード」第4回：ifを追加したら壊れた話

「条件を足しただけなのに…」

実務あるある

👉 新しい仕様が増えた
👉 ifを1個追加した

結果

👉 別の条件が壊れる

元のコード

def calc_shipping(price, is_vip):
    if is_vip:
        return 0

    if price >= 5000:
        return 0

    return 500

👉 VIPなら送料無料
👉 5000円以上でも送料無料

👉 シンプルです。

ここで仕様追加

👉 「セール商品は送料無料対象外にしたい」

よくある追加仕様です。

追加したコード

def calc_shipping(price, is_vip, is_sale):
    if is_sale:
        return 500

    if is_vip:
        return 0

    if price >= 5000:
        return 0

    return 500

👉 一見問題なさそうです。

でも後から気づく

VIP会員は

👉 セール商品でも送料無料にしたかった

何が起きているのか

例えば

calc_shipping(
    price=1000,
    is_vip=True,
    is_sale=True
)

この場合、本来は

0

になってほしい。

でも実際は

500

になる。

「なんで？」

ここが今回のポイントです👇

ifを追加すると…

👉 条件同士が干渉し始める

今回のコードでは

if is_sale:
    return 500

が最初に評価されます。

つまり

👉 VIPかどうかを見る前に終了する

🔥 ここが本質

ifは「増える」のが問題ではありません。

問題は

👉 条件の優先順位が増えること

最初の状態

通常
VIP
5000円以上

条件追加後

通常
VIP
5000円以上
セール
VIP + セール
5000円以上 + セール

👉 一気に組み合わせが増えます。

結果

👉 修正のたびに影響範囲が読めなくなる

👉 「どこを直せばいい？」になる

👉 if追加で壊れやすくなる

今日のポイント

👉 ifが増える = 状態パターンが増える

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

「じゃあどう整理すればいいの？」と思った人へ

• Effective Python 第3版
  👉 条件分岐を整理する考え方が具体例で学べます

• Clean Architecture 達人に学ぶソフトウェアの構造と設計
  👉 条件・責任・状態の分け方がかなり分かりやすいです

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

実務だとこうなる

• フラグ追加で条件爆発

• ifだらけで誰も触れない

• 修正すると別条件が壊れる

👉 全部同じ構造です。

次回予告

👉 「共通化したら壊れた話」

“DRY”の落とし穴に入ります。

ひとこと

👉 このif、あと3個増えても読めますか？