从“一堆语句”到清晰结构：代码重构与SQL优化实战指南

你见过那种“一堆语句”吗？不是经过设计、有结构的代码，而是一堆密密麻麻挤在一起的语句——没有空行、没有注释、变量名全是 a/b/c，if 套 if 套了五六层，SQL 里 SELECT * 满天飞，JOIN 乱成一锅粥。我接手过不少这样的“祖传文件”，每次打开编辑器，光标停在第一行，脑子里唯一的想法就是标题里那句话：一堆语句……

这篇文章想聊的，就是当你面对这样一堆语句时，应该做什么、按什么顺序做、用什么方法做。它适合正在被混乱代码折磨的开发者，也适合那些刚入行、想要建立代码整理方法论的人。我会用一次真实的 SQL 重构案例，加上几个 Python 整理场景，把这些方法拆开揉碎。核心思路一句话：与其抱怨代码烂，不如把它当成一次结构化思维的训练。

1. 混乱语句的成因诊断：动手前先搞清楚病根

很多人拿到烂代码马上就想“重写”，但我的建议恰恰相反：先别急着动手，先搞清楚这堆语句是怎么变成这样的。病因没搞清楚就开刀，大概率会把原本能跑的东西改坏。

1.1 三种典型的“语句堆”来源

我在实际工作中见过大量混乱语句，总结下来基本逃不出三种来源。

第一种是多人协作后无人统一风格。一个文件经过三五个人的手，有人喜欢用 for 循环，有人喜欢用列表推导式，有人习惯每行都加分号，有人完全不写空行。每个人新增的代码都按照自己的习惯来，日积月累，文件就变成了一个风格拼盘。这种“堆”的特点是局部能看懂，整体看头痛。

第二种是快速迭代中只加不改。产品需求每周都在变，开发节奏一快，很少有人会回头清理旧代码。于是老的逻辑没删，新的逻辑叠在上面，两个版本的处理方式并存，只是用 if 做了个分支区分。这种“堆”的特点是充满了“历史包袱”，很多代码看起来没用，但没人敢删——因为删了不知道会触发什么连锁反应。

第三种是复制粘贴式开发。从问答社区复制一段，从同事代码里复制一段，从自己以前的项目里再粘一段。复制过来的代码往往带着原项目的上下文依赖，风格也完全不一致。这种“堆”的特点是最危险：表面能跑，但里面藏着大量根本执行不到的“僵尸代码”，或者是只有特定条件下才触发的隐藏逻辑。

1.2 先分清：“能跑但烂”和“压根跑不通”

病因搞清楚之后，要做的第二件事是验证这堆语句的当前状态。这个步骤很关键，但很多人会跳过。

我把混乱语句分成两类。第一类叫“能跑但烂”，意思是整个流程能走通，结果也没错，但代码质量极差。第二类叫“压根跑不通”，可能是语法报错，可能是运行时报异常，也可能是逻辑算错了结果。这两类的处理策略完全不同。

“能跑但烂”的，可以放心去做结构梳理。 因为它的输入输出是稳定的，我可以先跑一遍记录下正确结果，然后大胆地拆函数、改命名、调整顺序，改完再跑一遍，对比结果一致，就说明重构没有破坏功能。

“压根跑不通”的，先调通再整理，千万不要边调边整。 我踩过这个坑：有一次拿到一个模块，状态是运行直接崩溃，我一边排查 bug 一边做代码整理，结果一个下午过去，bug 没找出来，代码反而被我改得更加混乱——因为我在改结构的时候，错误信息也变了，导致我根本分不清当前报错是原本的问题还是我改出来的问题。后来学乖了：先恢复功能，再谈优化。就像一辆车发动机故障，你不会先忙着给它重新喷漆。

注意：如果在整理过程中发现逻辑本身是错的，一定要先停下来，跟需求方确认清楚“预期结果到底是什么”。很多“重构翻车”的案例，问题不在重构手法，而在于改代码的人根本没搞明白那堆语句本来应该干什么。

2. 给语句“分堆”的三个核心动作：边界、依赖、职责

诊断做完，接下来进入正式整理环节。面对一堆杂乱的语句，我总结出三个核心动作：划边界、理依赖、定职责。这三个动作按顺序执行，基本可以把任何一段混乱代码拆成清晰的结构。

2.1 划边界：先找输入、处理和输出

不管代码多乱，它本质上都在做三件事：拿数据、算数据、给结果。所以整理的第一步，是先把一段语句按照“输入—处理—输出”三段划出边界。

拿一段 Python 代码举例。假设我从一个历史项目里继承了一个函数，里面的语句是这种画风：

python复制def process():
    data = open('orders.csv').readlines()
    result = []
    for line in data[1:]:
        parts = line.strip().split(',')
        total = int(parts[3]) * float(parts[4])
        if parts[2] == '已支付' and total > 100:
            result.append([parts[0], parts[1], total])
    with open('result.csv', 'w') as f:
        for row in result:
            f.write(','.join(row) + '\n')
    return len(result)

表面上看有 14 行语句，不算太多，但问题在于边界完全模糊：文件读取、数据过滤、计算、写文件、返回结果全混在一起。如果要改其中的过滤条件，你得在一堆语句里找“if”到底在第几行；如果要改输出格式，又得小心别碰坏前面的计算逻辑。

正确的做法是先划出三段：

• 输入段：读取 orders.csv 并解析成结构化数据（第 2 行到第 4 行）
• 处理段：过滤已支付且金额大于 100 的记录，计算 total（第 5 行到第 8 行）
• 输出段：写 result.csv 并返回数量（第 9 行到第 13 行）

划完之后，每段之间的边界点就清晰了：输入段结束在数据解析完成，处理段结束在 result 列表填充完毕，输出段从一个全新的 write 操作开始。有了这个边界，下一步的拆分才有依据。

2.2 理依赖：画出语句之间的上下游关系

边界划好之后，第二步是看语句之间的依赖关系。

依赖的本质是“谁在等谁”。一条语句用到了另一个变量，它就依赖产生那个变量的语句。依赖关系决定了哪些语句能够被单独抽取，哪些必须留在原地。

我举一个非常典型的依赖问题：SQL 里的隐式依赖。

sql复制SELECT *
FROM orders o, customers c, products p, order_items oi
WHERE o.customer_id = c.customer_id
AND oi.order_id = o.order_id
AND p.product_id = oi.product_id
AND o.order_date >= '2024-01-01'
AND c.country = '中国'
AND oi.quantity >= 1
AND p.category = '电子产品'

这段 SQL 表面上只有 9 行，但表之间的关联关系全糊在一起，依赖完全不可见。你根本不知道哪个过滤条件最早生效，哪个表应该作为驱动表。优化的时候更是无从下手。

把依赖关系理清楚之后，这种“多表泥潭”就能按顺序拆解了：先确定基础订单范围（orders 表按日期过滤），再确定有效客户范围（customers 表按国家过滤），然后确定商品范围（products 表按品类过滤），最后把明细表关联进来。每一步的输入输出都明确，依赖链条才清晰。

实战有一个很实用的技巧：去找“被最多语句引用的那一条语句”——它往往就是整个逻辑的核心枢纽。在代码里它通常是那个被反复使用的变量，在 SQL 里它就是最大的驱动表。理清楚这条核心语句之后，整个依赖树就明朗了。

2.3 定职责：每个函数只做一件事

边界和依赖都梳理完之后，最后一步是“定职责”。这个概念听起来抽象，但落到实操里只有一句话：每一层只能做一件事，每一层只和自己相邻的层次打交道。

继续拿前面的 Python 函数做例子。理清边界之后，把三段拆成三个独立的函数：

python复制def read_orders(path):
    data = open(path).readlines()
    return [line.strip().split(',') for line in data[1:]]

def filter_paid_orders(rows, min_total=100):
    result = []
    for parts in rows:
        total = int(parts[3]) * float(parts[4])
        if parts[2] == '已支付' and total > min_total:
            result.append([parts[0], parts[1], total])
    return result

def write_result(rows, path):
    with open(path, 'w') as f:
        for row in rows:
            f.write(','.join(row) + '\n')
    return len(rows)

处理函数只负责计算和过滤，读写函数只负责 IO，调用方只需要关心三个函数的拼接顺序。以后要改过滤规则，只动 filter_paid_orders；要改输出格式，只动 write_result。这就是“职责收敛”带来的直接收益。

3. 实战复盘：500 行 SQL 泥潭的重构全程记录

理论讲完，我拿一次真实的 SQL 重构过程来完整走一遍。这个案例是我去年处理过的一个销售统计报表模块，原始 SQL 总共 500 多行，是典型的“一堆语句”。

3.1 改造前的状态：为什么它这么难读

这份 SQL 是从一个遗留系统里导出来的，用于生成“国内电子产品销售季度报表”。500 多行里存在的问题包括：

• 同一张表被 JOIN 了 4 次，别名分别叫 a、b、c、d，根本看不出什么区别。
• 所有过滤条件都堆在 WHERE 里，没有一层 CTE（公共表表达式）包裹。
• 十几个计算列用的都是超长的 CASE WHEN，中间还混着子查询。
• 同样一段“计算订单金额”的逻辑，在全文中重复出现了 3 次。
• SELECT * 出现在两个子查询里，导致外层根本无法判断查询返回了哪些列。

我把这段 SQL 复现成简化版本，大概长这样：

sql复制SELECT
    c.customer_name,
    oi.product_name,
    CASE WHEN o.status = '已完成' THEN oi.quantity * oi.price ELSE 0 END AS revenue,
    CASE WHEN o.status = '已完成' AND o.payment_method = '月结' THEN oi.quantity * oi.price ELSE 0 END AS monthly_revenue,
    ...
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
LEFT JOIN (
    SELECT order_id, product_name, SUM(quantity) AS quantity, AVG(price) AS price
    FROM order_items
    GROUP BY order_id, product_name
) oi ON oi.order_id = o.order_id
WHERE o.order_date >= '2024-01-01'
AND o.order_date < '2024-04-01'
AND c.country = '中国'
...

问题就出在：每个字段的计算逻辑层层嵌套，后面的 WHERE 条件还得回看前面 JOIN 的别名才能确认到底过滤的是哪张表的数据。

3.2 分层拆解的第一步：用 CTE 建立数据边界

我做的第一个动作是：把“过滤订单”、“过滤客户”、“商品明细”分别封装成独立的 CTE。

sql复制WITH
filtered_customers AS (
    SELECT customer_id, customer_name
    FROM customers
    WHERE country = '中国'
),
paid_orders AS (
    SELECT order_id, customer_id, order_date, status, payment_method
    FROM orders
    WHERE order_date >= '2024-01-01'
    AND order_date < '2024-04-01'
    AND status IN ('已完成', '处理中')
),
order_product_metrics AS (
    SELECT
        order_id,
        product_name,
        SUM(quantity) AS quantity,
        AVG(price) AS price
    FROM order_items
    GROUP BY order_id, product_name
)

这一步做完，主查询里的 JOIN 变得非常干净：从 4 张表关联变成了 3 个 CTE 关联，每个 CTE 都有自己的名字，从名字就能看出它代表什么数据边界。

3.3 消除重复逻辑：把计算列收敛成指标定义

第二步是处理那 3 次重复的“订单金额”计算。原始 SQL 里每个 CASE WHEN 都重新写了一遍 oi.quantity * oi.price，一旦要改折扣规则，得改 3 处，漏改一处报表数据就对不上。

我的处理方式是在 CTE 里先算好基础金额字段，然后所有上层指标直接引用：

sql复制revenue_base AS (
    SELECT
        oi.order_id,
        oi.product_name,
        oi.quantity,
        oi.price,
        oi.quantity * oi.price AS gross_amount,
        o.status,
        o.payment_method
    FROM order_product_metrics oi
    JOIN paid_orders o ON oi.order_id = o.order_id
    JOIN filtered_customers c ON c.customer_id = o.customer_id
)
SELECT
    customer_name,
    product_name,
    SUM(CASE WHEN status = '已完成' THEN gross_amount ELSE 0 END) AS revenue,
    SUM(CASE WHEN status = '已完成' AND payment_method = '月结' THEN gross_amount ELSE 0 END) AS monthly_revenue
FROM revenue_base
GROUP BY customer_name, product_name;

重复逻辑被消灭了，指标口径统一到 gross_amount 这一个字段上。以后调价、改折扣、改金额计算规则，只需要动一处。

3.4 改造前后效果对照

为了方便理解，我把这次重构的关键变化整理成一张表：

这个案例想表达的核心观点是：SQL 重构和代码重构一样，本质上不是“把语句变少”，而是“让语句的边界和依赖变得清晰”。500 行里真正有用的逻辑可能只有 50 行，剩下 400 行全是重复、冗余和结构性混乱造成的噪音。

4. 格式化与 AI 辅助的正确姿势：能做什么，不能做什么

说到整理语句，很多人第一反应是用工具格式化一下，或者说让 AI 帮忙整理。这两种方式我都大量使用过，但它们的边界在哪里，值得好好聊聊。

4.1 格式化器只是“整容”，不是“正骨”

像 Black、Prettier、SQLFluff 这类格式化工具，它们做的事情是：统一缩进、统一换行、统一引号风格、统一运算符两侧空格。这很重要，但注意，它改变的只是语句的“外貌”，完全不涉及“结构”。

换句话说，你用格式化器跑一遍，原来“一堆语句”的样子不会改变，只是从“一堆歪歪扭扭的语句”变成了“一堆整整齐齐的语句”。问题依然在：逻辑还是嵌套五层，函数还是 200 行，重复代码还是重复。

所以我的建议是：格式化器必须用，但要清醒地知道它解决的是排版问题，不是结构问题。每天提交前跑一遍，保证代码风格统一；但千万别以为跑完格式化，代码质量就提升了。真正提升质量的，是上一章说的“划边界、理依赖、定职责”那套手工动作。

4.2 批量重构的三个安全策略

面对“一堆语句”，很多人会忍不住想一次性全部改完。但我的实践经验是：重构规模越大，失败概率越高。 我给自己定过三个安全策略，分享出来供大家参考。

第一，小步提交，每步可运行。每次只改一个模块，改完立刻测试提交。不要等把所有文件都改完再一次性验证——那意味着如果出了问题，你得在几百处改动里找 bug。

第二，重构和修 bug 严格分离。一次提交只做一件事：要么是重构，要么是修 bug，绝不混在一起。因为重构的 diff 应该只涉及结构调整，不涉及行为变化。如果重构过程中顺手改了一个 bug，那这个 diff 的 review 难度就会成倍增加，出了线上事故也没法快速回滚定位。

第三，输出一致性校验。这是 SQL 重构的专属技巧。任何时候重构完一段查询，我都会把改造前后的结果各跑一遍，然后做全字段对比。两个结果集完全一致，才说明这次重构是“无损”的。

sql复制-- 改造前查询结果
CREATE TABLE before_result AS SELECT ...;

-- 改造后查询结果
CREATE TABLE after_result AS SELECT ...;

-- 一致性校验
SELECT COUNT(*) AS diff_count FROM (
    SELECT * FROM before_result
    EXCEPT
    SELECT * FROM after_result
) t;

差集数量为 0，说明改造前后输出一致，可以放心提交。

4.3 AI 辅助整理语句的边界

这两年 AI 编程助手很火，我也经常用，但它对“一堆语句”的整理能力，目前还停留在“初稿辅助”的阶段，离“可信任的架构师”差得很远。

AI 能做好的事情包括：给变量和函数重新起名（往往起得还不错）、生成注释草稿、把一段长代码按模板格式化、给 SQL 加缩进和 CTE 包装。这些属于“低风险机械劳动”，交给 AI 能省很多时间。

AI 做不好的事情包括：判断一个业务字段到底该不该出现在结果集里、理解“为什么这两张表要用 LEFT JOIN 而不是 INNER JOIN”、决定一个函数应该拆成两个还是合并成一个。这些需要业务上下文和架构思考，AI 帮不上忙。

我的用法是：让 AI 先出一版“整理后的草稿”，我自己再拿着业务需求去核对边界、依赖和职责。 AI 提效的部分是排版和命名，真正的结构性判断仍然把在自己手里。

注意：千万不要让 AI 直接“全文重写”一段烂代码。AI 很容易把原来隐藏的逻辑错误也“重写”一遍，而且会生成看起来更合理、实际上不存在的逻辑。整理代码的人必须对每一行改动负责。

5. 从根上杜绝“一堆语句”：日常开发中的防堆机制

说实话，整理别人留下的烂代码虽然痛苦，但至少目标清晰。真正难的是：自己写的新代码，怎么保证三个月后不会变成下一堆“一堆语句”？这需要一套日常的防堆机制。

5.1 最小可理解单元：函数控制在 20 行内

我在代码评审里发现一个规律：只要一个函数超过 20 行，它往往就在做超过一件事。所以我给团队定的内控标准是：单个函数尽量不超过 20 行，如果一个函数超过 20 行，必须说出“为什么不能拆”的理由。

这个标准的背后逻辑是“工作记忆容量”限制。人脑一次能记住的逻辑链条是有限的，函数越长，review 的人理解成本越高，出错概率越大。20 行不是一个魔法数字，而是一个实践阈值。我曾经把一个 120 行的“上帝函数”拆成 6 个 15-20 行的小函数，代码总行数反而增加了，但新同事读懂它所需的时间从半天缩短到了半小时。

5.2 注释只写“为什么”，不写“是什么”

很多“一堆语句”的注释是完全没有信息量的，例如：

python复制# 计算总价
total = price * quantity

这种注释纯粹是噪音，删掉之后代码依然可读。真正有价值的注释是解释“为什么”的：

python复制# 这里用月结价而不是目录价，因为月结客户在合同里约定了折扣
total = monthly_price * quantity

我给自己定的注释习惯是：变量名和函数名负责表达“这是什么”，注释只负责解释“为什么会这样”。如果一段代码需要大量注释才能看懂，那说明变量命名和函数拆分本身出了问题，应该先去优化结构，而不是用注释去给烂结构打补丁。

5.3 代码评审里守住的底线

最后提一下代码评审在防堆机制里的作用。前面说的所有技巧，如果没有评审环节的坚持，靠个人自觉很难长期维持。

我评审代码时最看重的不是语法风格，而是三条结构底线：

• 这条语句能删掉吗？ 不能被合理解释的语句，就是潜在的死代码。
• 这个函数还能再拆吗？ 任何超过 20 行的函数，我都会追问拆分方案。
• 这段逻辑在别处出现过吗？ 出现过的，就要统一收敛到一个公共函数里。

这三条问下来，大部分“语句堆”在提交前就被拦截了。效果远好过事后花一个下午去重构。

最后再分享一个小技巧

整理“一堆语句”这么多年，我最大的体会是：这件事本质上不是技术能力，而是克制能力。 克制自己不去写那些“现在觉得方便、以后想骂人”的语句，克制自己在重构时不要顺手改业务逻辑，克制自己不要“顺便优化一下”那些看起来不顺眼的却又无关紧要的细节。

如果你手上正有一堆语句等着处理，我建议从今天做起：先把它们跑通，记录正确结果，然后只做一件事——把最长的那段拆成两段。拆完跑一遍，对比结果一致，提交。明天再拆一段。两周之后回头看看，你会感谢那个没有冲动重写、而是按部就班做结构拆分的自己。