代码重构手法：整理房间不换家

可视化演示

重构本质：整理房间，不换家

房间乱了，摆在你面前的无非两个选择：搬新家，或者动手收拾。搬新家听着痛快，但要重新刷墙、置办家具、研究新小区的快递柜在哪儿，还可能搬家途中弄丢几件重要物件。收拾房间则完全不同——家具还在原位、东西一件不丢，只是把随处乱放的物品重新归类，让整个空间焕然一新。代码重构就是后一种：它不动摇系统的“地基”，不改变程序的“对外表现”，只在内部把结构理得更顺，让后来的人一眼就能看懂、一改就能下手。

“外部表现”在代码世界里就是程序的行为：同样的输入，重构前和重构后必须给出同样的输出。回想一下，你给房间拍照时，光线、角度、家具的轮廓都没变，变的只是内部每个抽屉的摆放逻辑。这正是重构与重写最本质的分水岭——重写是“拆了盖新的”，重构是“微创整理”。

在工程上，重构被定义为：在不改变软件可观察行为的前提下，通过一系列小步骤改善代码内部结构。Martin Fowler 在他的著作中强调，重构不是一次性的剧烈运动，而是大量细碎动作的累积，每个动作小到几乎不可能出错。小到什么程度？小到每一步之后都可以立刻运行测试确认没有破坏任何东西。

所以，重构的底气来自“等价性”。哪怕只是把一个表达式提出来变成变量，也必须保证前后行为毫无变化。有了这把标尺，你整理的每一步都有据可依：整理不是凭感觉乱摆，而是按照“等价”这条准绳精确归位。

坏味道识别：房间里那些不对劲的信号

判断房间要不要收拾，不必等它变成垃圾场。有些信号早就出现了：袜子出现在厨房水槽边、剪刀消失在一个月前的快递盒里、想找支笔要翻遍三个抽屉——这些细节都是房间的“坏味道”，它们不致命，却在悄悄耗尽你的时间。代码世界同样如此。代码坏味道（Code Smell）是代码中疑似存在深层问题的表面迹象，它不会让程序立刻崩溃，但会让每一次改动都变得沉重、危险。

最常见的坏味道有四种。重复代码：同一段业务逻辑在多处各写各的，改一处忘一处，就像两把一模一样的钥匙丢在家里的不同角落，出门前总担心其中一把是不是丢在了昨天地铁上。过长函数：一个函数动辄几百行，开头读得明白，看到结尾已经忘了开头，如同一只塞满杂物的抽屉，要找一根数据线必须把整抽屉倒出来。过长参数列表：函数签名排着七八个参数，调用者要小心翼翼对齐每一个位置，仿佛出门要带五个包，哪个装什么全靠记忆。霰弹式修改：改一个需求要同时跑遍五六个文件修修补补，就像为了挪一张餐桌，得先把客厅、餐厅所有的摆设全部挪动一遍。

这些坏味道有一个共同的“体检指标”——圈复杂度（Cyclomatic Complexity）。它统计函数中独立执行路径的条数：每条 if、for、while 分支都会多出一条路。路径越多，函数越难读、越容易埋 bug、越难写测试。把这个指标量化出来，就是经典的圈复杂度公式：

坏味道就是房间向你发出的求救信号，圈复杂度则是测量乱象的“凌乱指数”。学会识别这些信号，你才知道该从哪里开始动手，而不是对着整间屋子发呆。

提取函数：把杂物装进收纳盒

房间整理最常用的一招是“收纳盒法”：把散落在桌面、茶几、地板上的同类小物——充电线、文具、票据——收进一个盒子，贴上标签。从此桌面清爽，找东西时只需拿起对应盒子，掀开盖子就能看到。提取函数（Extract Function / Extract Method）正是代码世界的收纳盒。当一段代码能够表达一个完整意图，比如“计算订单折扣”“校验用户输入”，并且它和周围的逻辑相对独立时，就把它从大函数中抽取出来，变成一个带名字的新函数，原位置只留下一个调用。

具体怎么操作？第一步，在大函数里圈出高内聚的语句块，划定“收纳盒”的边界。第二步，处理局部变量：新函数要读取的变量作为参数传进来；新函数要改写的变量作为返回值带出去。第三步，命名。好的函数名应该描述“做什么”而非“怎么做”，就像收纳盒上写“充电线”而不是“黑色塑料捆”。第四步，把原位置的代码替换成对新函数的调用，立刻运行测试确认行为不变。

设大函数 F 的语句序列为 [s1, s2, s3, s4]，我们把其中 s2、s3 提取成新函数 G：

收纳盒让桌面一次只放一种东西，提取函数让每个函数只操一份心，可读性与可测试性同步提升。不过要小心：如果被提取段既读又写同一个局部变量，就像一条毛巾同时搭在挂钩和椅背上，硬扯出来容易带翻旁边的花瓶。这不代表不能提取，而是要先做变量改名、拆分循环等预处理，让变量的归属变得清晰，再从容地打开收纳盒。

内联与搬移：扔掉中转箱，物品归其位

收纳盒用久了，也会出现两种尴尬。第一种：家里堆了一排空盒子，明明可以把东西直接放到最终位置，偏要经手一层“中转箱”。第二种：厨房的烘焙工具躺在卧室衣柜里，每次要用都得从卧室搬到厨房，用完再搬回去。内联（Inline）解决第一种尴尬，搬移（Move）解决第二种。

内联是提取函数的逆操作。当一个函数的函数体比函数名更直观，或者一个中间变量的名字不比它代表的表达式更有意义时，这一层“包装”就纯属多余。举个例子，const price = base * 0.8 如果只被用到一次，而 base * 0.8 又一看就懂，那还不如直接把表达式写到使用处，把变量名删掉。内联函数同理：调用方读起来完全不比函数体费解，那就拆掉这层壳，让逻辑“裸露”在阳光下。

再说搬移。判断依据很简单：特性 f 被谁使用得最多，就应该住在谁家。函数调用次数不会说谎——一个函数被类 B 引用十次、被类 A 引用两次，那它就属于 B，应该搬家。

提取是“汇聚”，内联是“简化”，搬移是“归位”。这三招配合起来，就能把整理工作覆盖到房间的每一个角落。收放之间，代码结构越来越贴近真实世界的“高内聚、低耦合”。

测试保护网：整理前的照片与清单

整理房间最怕什么？怕收完发现东西丢了。聪明的做法是：动手前先给每个角落拍照片、列物品清单；每收拾完一个区域就对着照片清点一次。有了这套对照系统，哪怕不小心弄乱，也能立刻发现并对症找回。代码重构的“照片”就是测试。重构圈子里有一条铁律：没有测试就动手重构，等于在悬崖边跳舞。

具体的舞蹈节奏叫“红绿重构循环”（Red-Green-Refactor）。第一步“红”：先写一个会失败的测试，确认新行为确实缺失；第二步“绿”：用最直接的办法让测试通过，不管代码美不美，先保证行为正确；第三步“重构”：在测试持续为绿的前提下，把刚写出来的代码整理干净。整个过程像过马路看红绿灯——红灯停（测试失败）、绿灯行（测试通过）、黄灯整理（重构优化）。

那这层保护网织得够不够密，怎么度量？看覆盖率。

测试就是那张“物品清单”，让你有底气说“我整理过，东西一件没少”。测试全绿，重构才能小步快跑、随时收手；测试如果飘红，说明刚才那步动坏了什么，立刻回滚到上一个绿点即可。保护网越密，重构的手越敢下。

重构节奏：每天十五分钟胜过周末大扫除

同样是整理房间，有人一年只大扫除一次，累到虚脱、期间还容易弄丢东西；有人每天睡前随手收拾五分钟，房间永远保持八十分以上的整洁。重构的哲学是后者。与其攒出一座“代码屎山”再发起总攻，不如把整理变成日常呼吸的一部分。代码质量不是靠一次“重构周”救回来的，而是靠无数个微小的好习惯堆出来的。

三个纪律决定了节奏是否健康。时机判断：不用专门留出“重构月”，最好的时机就藏在日常里——添加新功能时发现现有结构碍手碍脚，修 bug 时发现相关代码绕成一团，代码评审时发现明显的坏味道，都是顺手重构的黄金时刻。一次一处：一次只做一个重构动作，做一步、测一步、交一步。像整理房间时一次只收拾一个抽屉，绝不把整个衣柜都倒出来。频繁提交：小步提交让每一次改动都有记录、可回溯，出问题秒回退，避免了“改了一整天最后不知道哪里错了”的绝望。

把这些微小的改进叠加起来，你会发现一个惊喜——复利效应。质量不是线性增长，而是指数增长：

整理房间的秘诀从来不是“大扫除”，而是“物归原位 + 每日微调”。重构也一样：小步、频繁、有测试守护，让代码库像滚雪球一样越滚越干净。你今天花十五分钟提取的那个函数，可能为三个月后的自己省下一个下午的排查时间。

AI 应用场景

Python 演示

import ast  class SmellDetector(ast.NodeVisitor):    def __init__(self, max_lines=15, max_args=5, max_cc=10):        self.max_lines = max_lines        self.max_args = max_args        self.max_cc = max_cc        self.smells = []     def visit_FunctionDef(self, node):        lines = node.end_lineno - node.lineno        if lines > self.max_lines:            self.smells.append(                "long-function: {} has {} lines, suggest extract function".format(                    node.name, lines                )            )        args = len(node.args.args)        if args > self.max_args:            self.smells.append(                "long-parameter-list: {} has {} args".format(node.name, args)            )        cc = self._cyclomatic_complexity(node)        if cc > self.max_cc:            self.smells.append(                "high-complexity: {} has CC={}, try extract function".format(                    node.name, cc                )            )        self.generic_visit(node)     def _cyclomatic_complexity(self, node):        score = 1        for n in ast.walk(node):            if isinstance(n, (ast.If, ast.While, ast.For, ast.ExceptHandler)):                score += 1            elif isinstance(n, ast.BoolOp):                score += len(n.values) - 1        return score  SAMPLE = """def place_order(user, cart, coupon, addr, pay, note):    total = 0    for item in cart:        total += item.price * item.count    if coupon and total > 100:        total = total * 0.9    if not addr:        raise ValueError("no address")    if not pay:        raise ValueError("no pay method")    if note:        print("note:", note)    print("total:", total)    print("ship to:", addr)    print("pay by:", pay)    return total"""  def main():    tree = ast.parse(SAMPLE)    detector = SmellDetector(max_lines=6, max_args=4, max_cc=4)    detector.visit(tree)    if detector.smells:        print("Found {} smell(s):".format(len(detector.smells)))        for s in detector.smells:            print("- " + s)    else:        print("No smell found. Great!")  if __name__ == "__main__":    main()

1. class SmellDetector(ast.NodeVisitor):继承 AST 访问者类，让代码自动“逛”遍每一个语法节点，如同带着清单逐间检查房间。
2. def visit_FunctionDef(self, node):访问者回调方法，碰到任意函数定义就停下来执行检查，是扫描仪的核心触点。
3. lines = node.end_lineno - node.lineno用函数结束行号减开始行号算出函数体长度，对应“房间面积”测量。
4. cc = self._cyclomatic_complexity(node)调用自定义方法计算圈复杂度，相当于给每个函数测“凌乱指数”。
5. elif isinstance(n, ast.BoolOp):识别 and/or 逻辑运算符，每个运算符都会增加一条独立路径，让圈复杂度上升。
6. tree = ast.parse(SAMPLE)把源码字符串解析成 AST 抽象语法树，就像给房间画一张结构图，之后所有测量都在结构图上进行。
7. detector.visit(tree)启动全屋巡检，所有坏味道被逐一记录进 smells 列表，最终打印成“整改建议书”。

常见误区

面试题