很多工程师都经历过“代码越写越多、越写越难维护”的阶段。问题往往不在业务复杂，而在我们用复杂度对抗复杂度。 下面 7 个 Python 写法，不靠框架、不靠技巧堆砌，却能稳定减少重复逻辑，让代码更小、更清晰、更好扩展。 |
01用字典替代多层条件分支
痛点：一长串 if/elif 会把流程缠成一团，新类型一来就得改旧逻辑。
做法：用字典作为“分发表”，把分支变成可插拔函数。
收益：逻辑扁平化、扩展不动旧代码，测试边界更清晰。
HANDLERS = { "admin": handle_admin, "editor": handle_editor, "viewer": handle_viewer,}return HANDLERS[user_type](user)
02数据类代替手写模型
痛点：大量 __init__ / __repr__ / __eq__ 只是机械重复。
做法：用 @dataclass 明确“这是数据，而非行为”。
收益：模型层更轻，表达更直接，减少样板代码。
from dataclasses import dataclass@dataclassclass User: name: str age: int active: bool
03没有状态的类，用函数替代
痛点：很多类只有一个方法、没有状态，只是“函数套壳”。
做法：直接用函数表达行为。
收益：少一层抽象，降低心智负担，代码更透明。
def calculate_price(order):
...
04用早返回压平嵌套
痛点：嵌套越深，可读性越差，分支也越难维护。
做法：将失败路径提前返回，让主逻辑直线展开。
收益：结构更扁平，路径清楚，减少漏判。
def process(user): if not user: return None if not user.active: return None if not user.has_permission: return None return do_work(user)
05用推导式替代“循环 + 条件”
痛点：常见的 for + if + append 让意图分散在多行。
做法：用列表/集合/字典推导式直接表达结果。
收益：语义集中、行数更短、bug 更少。
results = [u.email for u in users if u.active]
06组合优于继承
痛点：继承层级一深，就容易“牵一发而动全身”。
做法：用组合的方式组织权限、能力与行为。
收益：耦合更弱，复用更稳，减少脆弱基类问题。
class User: def __init__(self, permissions): self.permissions = permissionsdef can_edit(user): return "edit" in user.permissions
07让 Python“响亮地失败”
痛点：过度防御性判断让代码充满“如果…否则…”。
做法：相信运行时与测试，让错误暴露在应该暴露的位置。
收益：分支更少，问题更早出现，测试更有价值。
value = data[key] # 让 KeyError 直接暴露
08什么时候别用
🚫 可读性下降：为了“短”牺牲直观理解。 🚫 团队无共识：写法不统一会增加维护成本。 🚫 抽象过度：聪明但难懂，反而更危险。 |
✓结语
少写代码不是目标，少写“为复杂度买单的代码”才是。把注意力放在业务本身，系统会更稳定、团队也更轻松。 |
🔗 原文链接：
https://medium.com/the-pythonworld/7-python-patterns-that-eliminated-40-of-my-code-2b1036ba490c
10个月宝宝每天需要喝多少奶粉？
