Python 函数职责划分的判断标准

函数该拆，当它同时处理不同抽象层的逻辑，如查库与渲染、校验与发请求；参数超3个未聚合、命名含“and/or/then”、返回类型混乱、测试需多mock，均是拆分信号。

函数是不是该拆？看它有没有「两件不相干的事」

一个函数干了多件事，不是代码多、行数长才叫“职责不清”，而是它在同时处理不同维度的逻辑。比如既查数据库又渲染 HTML，或者既校验输入又发 http 请求——这两类动作天然属于不同抽象层。

实操建议：

• 问自己：如果我要给这个函数写单元测试，是否得 mock 数据库、网络、时间等至少两个外部依赖？如果是，大概率该拆
• 检查函数内部是否有明显分界：比如前半段处理 user_input，后半段拼接 sql_query 并执行，中间没共享状态，就是拆分信号
• 留意命名：如果函数名里带 “and”、“or”、“then”，比如 validate_and_save_user，基本是职责混合的铁证

参数超过 3 个时，先怀疑是不是封装错了

不是参数多就一定错，但 python 的 def 函数一旦接受超过 3 个独立参数（不含 *args 或 **kwargs），往往意味着它在协调多个上下文，而没把关联数据聚合成一个概念。

常见错误现象：create_order(user_id, product_id, quantity, currency, discount_code, notify_email) —— 这些参数其实属于两个对象：User 和 OrderRequest，硬塞进函数里会让调用方反复构造零散值。

立即学习“Python免费学习笔记（深入）”；

实操建议：

• 把语义上成组的参数打包成 dataclass 或 NamedTuple，比如 OrderRequest(product_id, quantity, discount_code)
• 避免用字典传参代替结构化类型，create_order(**order_dict) 看似简洁，实则隐藏了契约，ide 和类型检查器都帮不上忙
• 如果函数必须支持多种组合（如部分字段可选），优先用 dataclasses.field(default_factory=...) 而非一堆 None 默认值

函数返回值类型混乱，说明它在承担「决策」和「执行」双重角色

比如一个叫 process_payment 的函数，有时返回 dict（成功），有时抛 ValueError（校验失败），有时又返回 None（余额不足但静默跳过）——这不是健壮，是职责模糊。

使用场景：支付、权限校验、配置加载这类有明确成败路径的操作，最容易在这里失控。

实操建议：

• 让函数只做一件事：要么纯计算（无副作用、确定性返回），要么纯执行（有副作用、统一返回 bool 或 Result 类型）
• 拒绝“成功返回结果，失败返回 None”模式；Python 有异常机制，就别用 None 当控制流
• 如果真需要多态返回（如 union[str, int, None]），说明它本该是多个小函数，或者用 Result 模式（如 result = process_payment(...); if result.is_ok(): ...）

测试难写、难读、难改，根本原因常是函数边界没划清

当你发现要为一个函数写 5 个以上测试用例，且每个都要 patch 三四个地方（patch('requests.post')、patch('datetime.now')、patch('os.getenv')），那不是测试写得不够好，是函数本身越界了。

性能影响：过度耦合的函数没法单独压测 IO 密集或 CPU 密集部分，也难以用 functools.lru_cache 缓存中间结果。

实操建议：

• 每个测试文件只验证一种行为：比如 test_payment_validation.py 只管校验逻辑，不碰数据库；test_payment_gateway.py 只管对接第三方，不碰业务规则
• 如果某个函数的测试需要启动真实数据库或网络，立刻停手——它已经不属于 unit test 范畴，该被隔离出去
• 用 typing.Protocol 定义依赖接口（如 PaymentGateway），而不是直接 import 具体实现，能倒逼你把职责切开

真正难的不是判断“要不要拆”，而是识别哪些逻辑看似相关、实则不该绑在一起——比如“生成订单号”和“保存订单”，前者是纯函数，后者是副作用，它们共享的只有“订单”这个名词，没有共享的执行上下文。