从“能跑但不敢改”到“敢改”：系统重构与代码质量提升实践
1. 从“能跑”到“不敢改”：一个普遍的技术困境
最近在维护一个老项目时，我又一次陷入了那种熟悉的、令人窒息的境地：系统在线上跑得好好的，功能一切正常，但只要一想到要修改其中的某个模块，哪怕只是加一个简单的日志，后背都会冒出一层冷汗。我相信这种感觉，很多开发者都经历过——我们称之为“能跑但不敢改”的系统。这不仅仅是代码质量问题，它更像是一种弥漫在整个项目中的“氛围”，一种由技术债、糟糕的设计和脆弱的依赖共同构成的“气场”。最近，一个叫“vibecoding”的词在开发者社区里火了起来，它精准地捕捉了这种状态。Vibecoding，直译过来是“氛围编码”，它描述的正是这种由代码、架构、团队习惯甚至项目历史共同营造出的、一种难以言喻但又真实存在的“开发氛围”。一个健康的vibecoding让人如沐春风，敢于重构和迭代；而一个糟糕的vibecoding，就像我面对的那个老系统，让人每一步都如履薄冰。
这个标题“这个系统能跑，但我不敢改：一次典型的 vibecoding 反思”，恰恰点出了我们日常开发中最核心的痛点之一。它不是一个具体的技术bug，而是一种系统性的“病态健康”。系统在功能层面是“健康”的（能跑），但在可维护性、可扩展性和开发者的心理安全层面，它已经“病入膏肓”（不敢改）。这次反思，我想深入拆解一下，到底是什么样的代码和项目特征，共同酿造了这种令人望而生畏的vibecoding。我们会从代码的“气味”、架构的“陷阱”、团队协作的“熵增”以及具体的实操策略几个层面，来一次彻底的诊断和复盘。如果你也正在某个“屎山”旁徘徊，或者担心自己的项目正滑向那个深渊，那么这次讨论或许能给你一些清晰的行动路线图。
2. 诊断“不敢改”系统的六大核心症状
一个让人“不敢改”的系统，其糟糕的vibecoding通常不是单一原因造成的，而是多种“症状”并发的结果。识别这些症状是解决问题的第一步。下面我结合自己的踩坑经历，总结出六个最典型、也最致命的特征。
2.1 症状一：高耦合与低内聚的“蜘蛛网”架构
这是最经典也最普遍的问题。模块之间不是通过清晰、有限的接口进行通信，而是像蜘蛛网一样相互缠绕。你常常会看到这样的代码：一个“工具类”里引用了半个系统的配置、服务甚至数据库连接；一个业务对象的修改，需要同步改动五六个看似不相关的模块。
为什么这会让人不敢改？因为修改的影响范围完全不可预测。你以为只是在A模块加个参数，结果B、C、D模块都因为隐式依赖而崩溃。这种架构下，没有所谓的“局部修改”，任何改动都是“牵一发而动全身”的系统性风险。
一个具体的例子：我曾遇到一个订单处理系统，它的“价格计算器”模块，不仅需要商品数据，还直接去读取用户会员等级表、营销活动缓存，甚至调用了物流费用估算的HTTP接口。当我想优化价格计算逻辑时，我发现自己不是在修改一个计算函数，而是在面对一个微型的、混乱的“全域系统”。任何调整都可能引发会员、营销、物流链路的连锁反应，而现有的测试完全覆盖不到这些边缘场景。
2.2 症状二：缺失或无效的测试保护网
当系统没有测试，或者测试脆弱不堪（比如大量Mock、测试与实现细节强绑定）时，你就失去了最重要的安全网。没有测试，你就无法自信地回答一个最基本的问题：“我这次修改，有没有破坏原有功能？”
为什么这会让人不敢改？修改变成了“盲人摸象”。你只能依靠手动点击进行回归测试，而一个复杂的业务系统，其功能路径组合是天文数字。你永远无法保证自己点击的那几条路径能代表所有用户场景。更糟糕的是，如果现有测试本身就需要大量维护（比如你一改接口，几十个测试就因为Mock数据而失败），那么测试就从保护网变成了负担，进一步抑制了修改的意愿。
实操心得：测试的缺失往往是历史欠账。一个可行的策略是“包围策略”。即，在修改某个模块前，先为这个模块的当前行为补充高价值的集成测试或契约测试。这相当于在动手术前，先给病人做一个局部的、精确的CT扫描。虽然不能保证全身无恙，但至少能确保手术部位的情况是清晰的。
2.3 症状三：“魔术数字”与“神秘字符串”的泛滥
代码中充斥着未经解释的硬编码数字、字符串和标志位。比如if (status == 3)， 这个3代表什么？是“已发货”还是“审核中”？再比如数据库查询里拼接的WHERE type = ‘SPECIAL_USER’， 这个‘SPECIAL_USER’是在哪里定义的？有多少地方在用？
为什么这会让人不敢改？这些“魔术”元素是隐藏的炸弹。你想把状态3改成4，但可能某个遥远的报表系统正依赖这个原始值进行统计。你想重命名用户类型，但发现它被以字符串形式写死在三个微服务、两个前端页面和一个数据脚本里。修改它们意味着要进行一次全代码库的字符串搜索和替换，并且祈祷没有漏网之鱼。这种不确定性极大地增加了修改的成本和风险。
2.4 症状四：文档与现实的严重割裂
文档要么不存在，要么严重过时。README里写的启动方式早已失效，API文档描述的字段实际返回的已经是另一个结构，架构图还停留在三年前单体应用的版本。团队的知识存在于少数几个“老炮”的脑子里。
为什么这会让人不敢改？新成员或是不熟悉该模块的开发者，在动手前需要花费大量时间进行“考古”——阅读代码、询问同事、甚至通过测试用例反推业务逻辑。修改的决策缺乏可靠的上下文依据。你可能会因为不知道某个看似无用的参数是下游系统强依赖的，而将其删除，从而引发线上事故。知识的垄断和信息的缺失，是制造恐惧的温床。
2.5 症状五：复杂的、非标准的构建与部署流程
项目的构建脚本是一坨无人能懂的“祖传秘方”，依赖管理混乱（比如直接修改node_modules里的文件），部署需要手动执行一连串神秘的命令，或者依赖于某个特定人员电脑上的特定环境变量。
为什么这会让人不敢改？即使你的代码修改是正确的，你也无法确保它能被正确地构建、集成和部署。你可能会陷入“在我本地是好的”的经典陷阱。更可怕的是，一次失败的部署可能没有回滚机制，或者回滚流程同样复杂。当你无法控制代码从开发到上线的完整链路时，修改代码本身就成了一场赌博。
2.6 症状六：无处不在的“临时解决方案”和“TODO”注释
代码里散落着// TODO: refactor this later、// FIXME: hack for production issue #123这样的注释，以及大量以temp_、quick_fix_命名的函数和文件。这些“临时”方案往往一用就是好几年，并且已经成为了核心逻辑的一部分。
为什么这会让人不敢改？这些代码是“已知的未知风险区”。你知道它们有问题，但你不清楚如果动了它们，会解开一个怎样的“封印”。那个为了解决线上紧急问题而写的hack，可能恰好掩盖了另一个更深层的逻辑缺陷。修改它，可能会让那个隐藏的缺陷暴露出来，引发更大的问题。于是，大家心照不宣地绕着这些“地雷”走，代码库就这样变得越来越臃肿和怪异。
3. 重构“敢改”氛围：从认知到实操的四步法
诊断出问题只是第一步，更重要的是如何行动，逐步将系统从“不敢改”扭转为“敢改”。这需要一个系统性的、渐进式的策略，而不是一次性的、颠覆式的重写。下面是我在实践中总结出的一个四步法。
3.1 第一步：绘制“恐惧地图”与建立安全区
在动手改代码之前，先别急着写代码。拿出一张白纸（或一个文档），为这个令人恐惧的系统绘制一张“恐惧地图”。
- 识别核心恐惧点：列出你最不敢碰的模块或文件。是那个十万行的上帝类？是那套错综复杂的消息队列消费者？还是那个没有任何测试的支付网关集成？
- 分析恐惧根源：针对每个点，写下你害怕的原因。是缺乏测试？是依赖复杂？还是逻辑完全无法理解？
- 划定“安全区”：在系统里找到一个相对独立、边界清晰、你比较有把握的模块。它可能是一个工具类、一个数据模型、或者一个简单的API端点。这里将是你发起第一次“进攻”的根据地。
实操技巧：这个“安全区”最好具备以下特征：有相对完整的单元测试、外部依赖少（或可以被轻易Mock）、在业务链路上不处于核心位置（即使改坏了影响也有限）。从这里开始，你的目标是取得一次小的、确定的胜利，建立信心。
3.2 第二步：实施“缝补匠”策略，而非“爆破手”
面对一个糟糕的系统，推倒重来（做“爆破手”）的诱惑非常大，但这通常是灾难性的。它周期长、风险高，且往往在重写的过程中，业务需求又发生了变化，导致新系统还没上线就旧了。
更有效的策略是扮演“缝补匠”：
- 引入接缝：在原有混乱的代码中，寻找或创建“接缝”。接缝是指那些可以让你插入新代码而不影响旧逻辑的点。例如，将一个庞大的函数中的一部分逻辑提取到一个新类中，并通过接口与旧代码交互。
- 抽象与隔离：对于最令人恐惧的依赖（比如那个直接连接了五个数据库的全局管理器），尝试为其创建一个清晰的接口（抽象），然后提供一个适配器来包装原有的混乱实现（隔离）。这样，其他代码就可以依赖这个清晰的接口，而不是那个混乱的实现。
- 逐步替换：一旦接口和适配器就位，你就可以开始逐步将调用方从旧的、混乱的实现，迁移到新的、整洁的实现上。每次只迁移一个调用者，并充分测试。
一个案例：对于那个“蜘蛛网”式的价格计算器，我的做法是：
- 首先，定义一个清晰的
PriceCalculator接口，里面只有calculate(OrderContext context)一个方法。 - 然后，写一个
LegacyPriceCalculatorAdapter类，实现这个接口。这个适配器类的内部，就是原封不动地调用那坨旧的、混乱的计算逻辑。 - 现在，任何需要计算价格的新代码，都依赖
PriceCalculator接口，并使用这个适配器。 - 接着，我可以开始新建一个
CleanPriceCalculator类，也实现同一个接口。在这个新类里，我可以一点点地、用测试驱动的方式，重新实现计算逻辑，每次只处理一种业务场景（比如普通用户、会员用户）。 - 每完成一个场景，我就在适配器里做一个开关，将对应场景的流量切到新的计算器上。通过配置或特性开关控制，一旦有问题，可以瞬间切回。 这个过程虽然慢，但每一步都是安全的、可验证的、可回滚的。
3.3 第三步：投资于自动化安全网
要让人们敢改，必须提供安全网。在软件工程中，最有效的安全网就是自动化的测试和CI/CD流水线。
- 从“ characterization test ”（特征测试）开始：对于完全没有测试的遗留代码，不要一开始就想写完美的单元测试。可以先写“特征测试”。即，用当前系统的输入和输出来编写测试，目的是“捕获”系统现有的行为。这些测试可能很丑，可能依赖真实环境，但它们提供了一个行为的基线。当你后续修改代码时，这些测试会告诉你行为是否发生了改变。
- 建立快速反馈的CI流水线：确保每一次提交都能触发一个完整的构建、测试（包括单元、集成、端到端）流程，并在10分钟内给出结果。快速的反馈是勇于重构的关键。如果一次测试需要跑2小时，开发者就会倾向于攒一堆改动再提交，从而失去小步快跑、及时验证的安全感。
- 实现一键部署与回滚：部署过程应该是完全自动化的、可重复的。回滚机制必须和部署机制一样简单、可靠。当开发者知道任何错误的部署都能在1分钟内无损回滚时，他们对于发布修改的恐惧会大大降低。
3.4 第四步：培养团队的技术纪律与共识
糟糕的vibecoding往往也是团队习惯的产物。改善它需要整个团队在认知和纪律上达成一致。
- 建立代码审查文化，聚焦于“可维护性”：代码审查不应只关注功能是否正确，更要关注“这段代码我敢不敢改”？审查者可以问这样的问题：“这里的魔法数字能否用常量替代？”“这个函数的长度是否超过了50行？”“新增的依赖是否必要？”。
- 定期举行“代码考古”或“重构道场”：每周或每两周，团队花1-2小时，一起研究系统里某个“臭名昭著”的模块。不一定要立刻修改，目标是集体理解其中的问题，并讨论可能的改善方案。这能共享知识，打破“只有某人能懂”的信息壁垒。
- 将技术债可视化并纳入迭代计划：不要隐藏技术债。使用问题跟踪工具（如Jira）创建“技术债”工单，并像处理功能需求一样，为其评估优先级和工作量。每个迭代（Sprint）都分配一定比例的时间（比如15-20%）来处理这些工单。这让偿还技术债成为一项持续的、可见的、有价值的工作，而不是被业务需求永远挤压的“额外任务”。
4. 具体技术手段：让“不敢改”的代码现形
除了策略和流程，我们还需要一些具体的技术工具和实践，来辅助我们识别和处理糟糕的代码。下面介绍几种非常实用的手段。
4.1 利用静态代码分析工具进行“体检”
现代IDE和CI工具集成了强大的静态分析功能。它们能自动检测出许多“代码坏味道”。
- 复杂度分析：识别圈复杂度过高（比如>10）的函数、类。这些通常是逻辑混乱、难以测试和修改的重灾区。
- 依赖关系分析：生成模块/类之间的依赖关系图。直观地看到哪些模块是高度耦合的“枢纽”，哪些模块是相对独立的“叶子”。这为你确定重构的优先级提供了数据支持。
- 重复代码检测：找出重复的代码块。重复是万恶之源，它不仅增加维护成本，还容易导致修改不一致。
- 未使用代码检测：找出从未被调用的“死代码”。大胆删除它们，可以简化代码库，减少认知负担。
工具推荐：对于Java项目，SonarQube是一个集大成的平台。对于JavaScript/TypeScript， ESLint 配合@typescript-eslint规则集非常强大。像codemetrics这类VS Code插件也能实时显示复杂度。
4.2 “童子军规则”与“男孩 scout 规则”的日常实践
“童子军规则”很简单：离开露营地时，要让它比你发现时更干净。应用到编程中就是：每次你阅读或修改一段代码时，都尝试做一点小小的改进。
这些改进可以非常微小，但累积起来效果惊人：
- 给一个含糊的函数或变量改名，让它更达意。
- 将一个长的函数拆分成几个小函数。
- 将一段重复的代码提取成一个公共函数。
- 删除一行过时的注释。
- 将一个魔法数字替换成有名字的常量。
关键在于，这些修改必须与当前的任务相关，并且要保证有测试覆盖。你不是专门花时间去重构，而是在完成本职工作（比如修复一个bug、添加一个小功能）的同时，顺手把代码整理得更干净一点。这能有效防止代码库在无人察觉的情况下慢慢腐化。
4.3 编写“学习测试”来理解遗留代码
当你面对一段完全看不懂的、但又必须修改的遗留代码时，不要硬着头皮去猜。可以为其编写“学习测试”。
学习测试的目的不是验证功能正确性（那是特征测试做的），而是为了探究代码的行为边界。你可以像做实验一样，构造各种极端、奇怪的输入，观察输出是什么。
例如，面对一个复杂的字符串处理函数，你可以写测试：
@Test void testWhatDoesThisFunctionDo() { // 输入 null 会怎样？ assertEquals("", weirdStringFunc(null)); // 输入空字符串呢？ assertEquals("", weirdStringFunc("")); // 输入超长的字符串呢？ String longStr = "a".repeat(10000); // 观察是截断、报错还是原样返回？ String result = weirdStringFunc(longStr); assertNotNull(result); // 输入包含特殊字符（emoji, 换行符）呢？ assertEquals("??", weirdStringFunc("hello\nworld?")); }通过运行这些测试，你可以快速摸清这段代码的“脾气”，了解它的输入输出映射关系、边界条件和异常处理方式。这比单纯阅读代码要高效和可靠得多，为你后续的安全修改打下了坚实的基础。
5. 心态调整：与“恐惧”共处并管理风险
最后，我想谈谈心态。面对一个“不敢改”的系统，开发者很容易产生挫败感、焦虑甚至逃避心理。管理好这种心态，和技术手段同等重要。
接受“完美重构”的不存在：你不可能通过一次史诗级的重构，就让一个积累了多年的系统焕然一新。接受系统的现状，把它看作一个需要长期护理的病人，而不是一个需要立刻处决的罪犯。你的目标是让它“逐渐变好”，而不是“立刻完美”。
拥抱“小胜”文化：庆祝每一次微小的改进。成功地将一个魔法数字替换成常量，成功地为一段复杂逻辑补充了一个测试，成功地将一个类拆分成两个更内聚的类……这些都是值得肯定的胜利。在团队周会上分享这些“小胜”，能持续积累正向反馈和改善的动力。
将“恐惧”转化为“风险清单”：当你感到“不敢改”时，不要停留在模糊的恐惧中。拿出一张纸，把具体的风险写下来。例如：“风险1：修改A模块的接口，可能会破坏B模块的功能，因为B模块直接依赖了A的内部状态。” 然后，针对每个风险，设计缓解或验证方案：“缓解方案：先为A模块编写集成测试，确保当前行为被捕获；修改后，运行B模块的现有测试套件。” 把未知的恐惧，转化为已知的、可管理的风险项，你的心态会从被动逃避转向主动管理。
理解业务上下文的价值：有时，一段看似“丑陋”的代码，背后可能隐藏着一段特殊的业务历史或一个临时但关键的业务约束。在动手“优化”前，尝试去理解“为什么代码会变成这样”。也许那个奇怪的if判断，是为了满足某个重要客户的特殊需求；也许那个复杂的同步逻辑，是为了解决一个已经发生过的数据一致性问题。不了解业务上下文的重构，就像给病人做手术却不看他的病历一样危险。
改造一个“能跑但不敢改”的系统，是一场关于技术、流程和心态的持久战。它没有银弹，但通过系统性的诊断、渐进式的重构、自动化安全网的构建以及团队共识的养成，我们完全可以将一个令人望而生畏的“屎山”，逐步转变为一个健康、有活力、让开发者敢于并乐于在其中创造的代码库。这不仅仅是改善代码质量，更是在改善我们每天的工作体验和职业幸福感。下次当你再面对这样的系统时，希望你能深吸一口气，拿出这份“反思”作为地图，开始你的“缝补”之旅。记住，最好的开始时间，一个是十年前，另一个就是现在。从绘制你的第一张“恐惧地图”开始吧。