4. 代码优化原则

说到代码优化，我见过太多人一上来就撸起袖子干。结果呢？忙活半天，性能没提升多少，代码倒是改得面目全非。今天咱们聊聊三个核心原则，说白了就是让你少走弯路。

80/20法则：把力气花在刀刃上

这个法则我太有感触了。刚入行那会儿，我总想把每行代码都优化到极致。后来发现，80%的性能瓶颈其实只集中在20%的代码里。你想想看，花时间优化那80%的冷门代码，性价比实在太低。

怎么找？我习惯用性能分析工具。比如在Python里，cProfile就是我的老朋友。

import cProfile

def slow_function():
    total = 0
    for i in range(1000000):
        total += i ** 2
    return total

cProfile.run('slow_function()')

跑完一看输出，哪个函数耗时最多一目了然。嗯，这里要注意，别凭感觉猜。我见过太多人猜错了热点，白费功夫。

不要过早优化：先跑起来再说

这句话你可能听过很多遍了。但说实话，我一开始也不信。总觉得不提前优化，后面会出大问题。直到有一次，我花了两天时间优化一个模块，结果需求变了，整个模块重写。那感觉，真叫一个酸爽。

为什么会这样？因为早期你根本不知道真正的瓶颈在哪。需求在变，架构在调，过早优化就像在沙子上盖楼。

那什么时候该优化？我给自己定了三条红线：

• 功能已经稳定，不再频繁改动
• 性能测试明确指出了瓶颈
• 用户反馈说“太慢了”

这三条都满足了，再动手不迟。

可读性与性能的平衡：别为了快而牺牲理解

这个平衡点，说实话很难把握。我见过一些代码，为了快那么几毫秒，写得跟天书似的。结果后来维护的人（包括我自己）看得一头雾水。

举个例子，下面这段代码性能很好，但你能一眼看懂吗？

# 性能优化版
result = [x * 2 for x in data if x % 2 == 0]

再看这个，虽然多写了几行，但意思清楚多了：

# 可读性优先版
result = []
for x in data:
    if x % 2 == 0:
        result.append(x * 2)

我个人习惯是：先写可读性好的版本。如果性能测试发现这里是瓶颈，再考虑优化。而且优化时一定要加注释，说明为什么这么改。

知识体系总览

下面这张图，是我自己总结的优化决策流程。每次动手前，我都会过一遍：

这张图的核心逻辑很简单：先确认是不是热点，再看可读性是否受影响。两个条件都满足，才动手优化。否则，要么跳过，要么先重构。

总结一下

这三个原则，说白了就是一句话：别瞎忙活，忙活也要忙对地方。80/20法则帮你找准目标，不要过早优化让你别白费力气，可读性与性能的平衡则保证你的代码能长久维护。

我这些年踩过的坑，大多都是违背了其中一条。现在每次写代码，我都会问自己三个问题：

1. 这是那20%的热点吗？
2. 现在优化是不是太早了？
3. 优化后别人能看懂吗？

三个问题都过了，再动手。嗯，这样虽然慢一点，但稳。