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 知识体系总览
下面这张图,把本章的核心内容串起来了。你可以把它当作代码优化的“地图”——遇到问题,先定位是哪个维度,再对症下药。
小技巧:每次提交代码前,问自己三个问题:别人能看懂吗?跑得快吗?改起来方便吗?如果有一个答案是否定的,那就再优化一下。
好了,这一章就到这里。记住:代码优化不是一次性工作,而是持续的习惯。从今天开始,写代码时多想想“如果三个月后的我看到这段代码,会是什么感受?”——嗯,答案往往就在你心里。