1. 好函数的三大核心要素
编写函数就像烹饪一道好菜——食材（代码）本身可能很简单，但如何组合它们决定了最终的质量。一个真正优秀的函数应该像一道精致的法式料理，每个组成部分都恰到好处，而不是把所有食材胡乱炖成一锅。
1.1 调用时的自然语言感
当我第一次看到这样的代码时，简直想砸键盘：
python复制process(True, False, 100)
这就像在餐厅点菜时说"给我来份1号套餐加2号调料"，鬼知道那是什么！
参数设计的黄金法则：
- 参数数量控制在3个以内（心理学研究表明，人脑短期记忆容量平均为4±1个组块）
- 布尔参数是代码的"臭味指标"，建议改用枚举或策略模式
- 参数顺序应符合自然语言习惯（比如
resizeImage(width,height)就比resizeImage(height,width)更符合直觉）
来看看我是如何重构一个电商项目的结账函数的：
python复制# 重构前
def checkout(user_id, cart_id, coupon_code, is_guest, use_points):
# 重构后
def checkout(order_request: OrderRequest):
"""OrderRequest包含:
- customer: 用户信息对象
- items: 购物车项列表
- payment: 支付方式对象
"""
通过引入参数对象模式，调用时就像在说人话：
python复制checkout(OrderRequest(
customer=current_user,
items=selected_items,
payment=credit_card
))
1.2 函数体的黄金比例
我见过最恐怖的函数有1200行代码，作者还骄傲地说"这是一个完整的业务流程"。这就像把整头牛直接端上餐桌！
函数长度的科学依据：
- 心理学研究表明，人脑理解7±2个概念单元最舒适
- 谷歌研究显示，8-15行代码的函数缺陷率最低
- 我的经验法则：屏幕不滚动就能看完整个函数（约20行）
来看看我在金融系统重构的真实案例：
python复制# 反例：处理贷款申请的"巨无霸"函数
def process_loan_application(application):
# 验证部分（30行）
if not application.name: raise...
if application.income < 0: raise...
# 计算部分（50行）
credit_score = calculate_score(...)
risk_level = assess_risk(...)
# 审批部分（40行）
if risk_level > 5: return...
# 记录部分（20行）
log_approval(...)
# 通知部分（15行）
send_email(...)
# 正例：抽象层次分明的处理流程
def process_loan(application):
validate_application(application)
decision = underwrite_loan(application)
record_decision(decision)
notify_parties(decision)
return decision
每个子函数都保持单一职责，就像餐厅里切菜、炒菜、摆盘各司其职。
1.3 输出与副作用的管控
曾经有个bug让我加班到凌晨3点——某个函数偷偷修改了全局配置，而调用者完全不知情。这就像厨师在汤里加盐时，顺手把厨房的盐罐子也扔进去了！
纯净函数的优势：
- 可预测性：相同输入永远得到相同输出
- 可测试性：无需复杂的环境准备
- 可组合性：像乐高积木一样自由组合
来看个缓存处理的例子：
python复制# 反例：有副作用的缓存函数
cache = {}
def get_data(user_id):
if user_id not in cache:
data = db.query(...) # 直接访问数据库
cache[user_id] = data # 修改外部状态
return cache[user_id]
# 正例：纯净的函数式实现
def get_data(repository, cache, user_id):
if user_id in cache:
return cache[user_id]
data = repository.query(user_id)
return data
第二个版本明确所有依赖，就像厨师明确告知用了哪些调料。
2. 函数拆分的艺术
拆分函数不是简单的"切香肠"，而是建立清晰的抽象层次。就像写文章要有段落，写代码也要有层次。
2.1 抽象层次的一致性
我在代码审查时最常说的话是："这个函数里既有业务逻辑又有SQL语句，就像在小说里突然插入一段汇编代码！"
典型的抽象层次：
- 业务层：
place_order() - 领域层：
calculate_discount() - 基础设施层：
save_to_database()
看一个电商系统的例子：
python复制# 违反抽象层次的反例
def checkout_order(order):
# 业务逻辑
if order.total > 1000: apply_discount(...)
# 直接操作数据库
conn = psycopg2.connect(...)
cursor = conn.cursor()
cursor.execute("INSERT INTO orders...")
# 又跳回业务逻辑
if order.user.is_vip: add_vip_points(...)
# 层次分明的正例
def checkout_order(order):
apply_business_rules(order)
order_repository.save(order)
reward_service.update_points(order.user)
2.2 拆分的实操技巧
我有个简单的"5分钟规则"：如果不能在5分钟内给函数起个好名字，说明它做了太多事。
拆分的具体信号：
- 函数内有空行分隔的逻辑块
- 存在注释解释某段代码的作用
- 使用了"然后"、"接着"等连接词描述函数
来看一个数据分析脚本的重构：
python复制# 重构前
def analyze_data(file_path):
# 读取数据
data = pd.read_csv(file_path)
# 清洗数据
data = data.dropna()
data = data[data['value'] > 0]
# 计算统计量
stats = {
'mean': data['value'].mean(),
'std': data['value'].std()
}
# 生成报告
report = f"""分析报告：
平均值：{stats['mean']}
标准差：{stats['std']}"""
print(report)
# 重构后
def analyze_data(file_path):
data = load_and_clean_data(file_path)
stats = calculate_statistics(data)
present_results(stats)
每个步骤都提升了一个抽象层次，就像从食材准备到烹饪再到摆盘。
3. 实战中的经验教训
在15年代码生涯中，我总结出这些血泪教训：
3.1 参数设计的陷阱
布尔参数陷阱：
python复制# 坏味道代码
def render(text, is_html, is_markdown):
if is_html: ...
elif is_markdown: ...
# 优雅解决方案
def render_html(text): ...
def render_markdown(text): ...
或者使用策略模式：
python复制renderers = {
'html': HTMLRenderer(),
'markdown': MarkdownRenderer()
}
renderers[format].render(text)
3.2 重复代码的变种
重复不只是完全相同的代码块，还有：
- 结构重复（相同的处理流程）
- 概念重复（相同的业务规则分散在各处）
比如多个地方都有折扣计算：
python复制# 在订单处理中
if user.level == 'gold': discount = 0.2
elif user.level == 'silver': discount = 0.1
# 在支付模块中
if customer.tier == 'premium': reduction = 0.15
应该统一为：
python复制class DiscountPolicy:
def get_discount(user):
return DISCOUNT_TIERS.get(user.tier, 0)
3.3 测试驱动开发(TDD)的启示
TDD强迫你写出可测试的函数，自然就会：
- 保持函数短小
- 减少依赖
- 明确输入输出
我的TDD工作流：
- 写一个失败的测试
- 实现刚好能通过的最小函数
- 重构时保持测试通过
4. 行业最佳实践对比
不同语言社区对函数长度有不同约定：
| 语言 | 推荐长度 | 典型特征 |
|---|---|---|
| Python | 10-20行 | 强调可读性 |
| Java | 20-40行 | 受类结构影响 |
| Go | 5-15行 | 倾向小函数 |
| JavaScript | 15-30行 | 灵活性强 |
但所有语言都认同：
- 函数应该做一件事
- 命名要表达意图
- 避免副作用
在微服务架构中，我推荐：
- 业务逻辑函数保持纯净
- 将IO操作推到边界
- 使用中间件处理横切关注点
比如：
python复制# 业务核心
def transfer_funds(account_from, account_to, amount):
validate_transfer(account_from, amount)
new_balance_from = account_from.balance - amount
new_balance_to = account_to.balance + amount
return (new_balance_from, new_balance_to)
# 边界处理（可包含IO）
@app.post('/transfer')
def handle_transfer(request):
try:
result = transfer_funds(...)
db.commit()
return jsonify(result)
except Exception as e:
db.rollback()
log.error(...)
raise
5. 性能与可读性的平衡
有人担心小函数会影响性能，但：
- 现代编译器/解释器会内联小函数
- 真正的性能瓶颈通常在IO操作
- 可维护性差的代码后期优化成本更高
我曾经优化过一个"优化过度"的系统：
python复制# 原始"优化"代码（难以维护）
def process_data(data):
# 200行高度耦合的逻辑
...
# 重构后版本
def process_data(data):
cleaned = clean_data(data)
enriched = enrich_data(cleaned)
validated = validate_data(enriched)
return validated
虽然调用栈深了，但：
- 每个步骤可单独测试
- 可以并行处理某些步骤
- 更容易定位性能瓶颈
实际测试显示，重构后整体性能还提升了15%，因为可以针对特定步骤优化。