1. 代码优化基础:从“能跑”到“好改”

各位好,我是老张。做这行十几年了,见过太多代码——有的像艺术品,有的像一团乱麻。今天咱们聊聊代码优化。说白了,优化不是炫技,而是让代码更“省心”。

我刚开始带团队时,有个同事写的代码跑得飞快,但三个月后他自己都看不懂了。嗯,这就是典型的“优化了个寂寞”。真正的优化,得兼顾机器和人。

1.1 什么是代码优化?

代码优化,不是单纯地让程序跑快一点。它是在不改变外部行为的前提下,让代码内部变得更好。你可以理解为——给代码“健身”,而不是“整容”。

核心定义:代码优化 = 保持功能不变 × 提升质量属性(可读性、性能、可维护性)

举个例子,你写了个排序函数,结果是对的。但优化后,别人一眼能看懂逻辑,改起来不费劲,跑起来还快——这才是优化到位了。

1.2 代码优化的三大目标

我个人习惯把优化目标分成三个维度。你想想看,一个项目里,哪个维度出问题最让人头疼?

目标 核心关注点 典型问题
可读性 人能不能快速理解 变量名像密码、函数长到翻页
性能 资源消耗是否合理 循环套循环、重复计算
可维护性 改一处会不会崩一片 全局变量满天飞、硬编码遍地

可读性:先让人看懂

我在项目中遇到过最离谱的变量名是 a1b2c3。问作者什么意思,他说“临时变量,懒得想”。结果后来改 bug,全组人花了半天才理清逻辑。说白了,代码是写给人看的,顺便给机器执行。名字起清楚,比什么都强。

性能:别做“慢动作”

性能优化要抓大头。我曾经优化过一个报表模块,把 O(n²) 的循环改成 O(n log n),耗时从 30 秒降到 0.5 秒。但有些同学喜欢纠结“用 for 还是 while”,其实那点差异可以忽略。记住:先找瓶颈,再动手。

可维护性:为未来留条活路

可维护性差,说白了就是“改一处,崩三处”。我见过一个函数 800 行,里面全是 if-else 嵌套。后来需求变了,没人敢动,最后重写了整个模块。可维护性好的代码,应该像乐高积木——拆得开,拼得上。

1.3 常见的代码坏味道

“坏味道”这个词,是《重构》那本书里来的。它不是 bug,但暗示着代码可能出问题。下面这几种,我几乎在每个项目里都见过。

避坑指南:我曾经在一个遗留系统里看到 2000 行的函数,里面还有 goto 语句。嗯,那是我职业生涯最想辞职的一天。遇到这种代码,别犹豫,能重构就重构,不能重构就写文档。

1. 重复代码

同样的逻辑,出现在三四个地方。改一个漏一个,bug 就来了。

# 坏味道:重复代码
def calc_discount_a(price):
    return price * 0.9 if price > 100 else price

def calc_discount_b(price):
    return price * 0.9 if price > 100 else price  # 完全一样!

# 优化后:提取公共函数
def calc_discount(price, threshold=100, rate=0.9):
    return price * rate if price > threshold else price

2. 长函数

一个函数做太多事。超过 20 行,就该考虑拆分了。我个人的经验是:一个函数只做一件事,做好它。

3. 过长的参数列表

函数参数超过 3 个,调用时容易搞错顺序。建议用对象或字典封装。

# 坏味道:参数太多
def create_user(name, age, email, phone, address, city, zip_code):
    pass

# 优化后:用数据类
from dataclasses import dataclass

@dataclass
class UserInfo:
    name: str
    age: int
    email: str
    phone: str
    address: str
    city: str
    zip_code: str

def create_user(info: UserInfo):
    pass

4. 全局变量滥用

全局变量让代码耦合度飙升。改一个全局变量,可能影响整个系统。我建议:能用局部变量就别用全局的,实在要用,加个命名空间。

5. 魔法数字

代码里直接写数字,比如 if status == 3。3 是什么意思?没人知道。应该用常量或枚举。

# 坏味道:魔法数字
if status == 3:
    print("订单已发货")

# 优化后:用常量
ORDER_STATUS_SHIPPED = 3
if status == ORDER_STATUS_SHIPPED:
    print("订单已发货")

1.4 知识体系总览

下面这张图,把本章的核心内容串起来了。你可以把它当作代码优化的“地图”——遇到问题,先定位是哪个维度,再对症下药。

代码优化知识体系 代码优化 可读性 性能 可维护性 重复代码 长函数 参数过多 全局变量滥用 优化原则 先保证可读性,再考虑性能 可维护性差 = 技术债务,迟早要还

小技巧:每次提交代码前,问自己三个问题:别人能看懂吗?跑得快吗?改起来方便吗?如果有一个答案是否定的,那就再优化一下。

好了,这一章就到这里。记住:代码优化不是一次性工作,而是持续的习惯。从今天开始,写代码时多想想“如果三个月后的我看到这段代码,会是什么感受?”——嗯,答案往往就在你心里。