前两天，一位朋友在技术群里吐槽，他接手了一个五年前的嵌入式项目。代码堪称“艺术品”——全局变量满天飞，单个函数动辄上千行，注释？基本不存在。
他说，每次打开代码库，重构的冲动就涌上心头。但真当鼠标移到键盘上，手指却像灌了铅一样，怎么也敲不下去。
这种纠结，我相信绝大多数程序员都感同身受。想动，又不敢动，这背后的症结究竟在哪里？
“能跑”即是最高准则
老旧代码虽然结构混乱，但它有一个无可辩驳的优势：经过时间验证的稳定性。
它可能已在生产环境平稳运行了数年，服务了海量用户，经历了各种极端场景的考验。你认为那段看似毫无逻辑的延时函数是垃圾？也许它正是当年为了解决某个棘手的硬件时序问题而专门添加的“补丁”。
在项目负责人和产品经理眼中，系统的稳定运行远比代码是否优雅重要。当你试图向他们解释技术债务或可维护性时，最常见的回应是：“现在系统有问题吗？没问题为什么要动它？”
这就是我们必须面对的现实。
重构，无异于拆除一颗“定时炸弹”
老旧项目最令人望而生畏之处，往往在于文档缺失、注释匮乏、测试用例空白。最初的开发人员可能早已离职，连他们自己也未必记得当初为何如此设计。
更棘手的是，许多业务逻辑已经遗失了。当年为何采用这个架构？这个特殊的判断条件缘何存在？这个看似奇怪的算法解决了什么问题？全都成了未解之谜。
你以为删除了一段冗余代码，结果可能就在某个不起眼的边界场景引发了致命的 Bug。因此，重构老项目就像在拆除一颗结构不明的炸弹，你永远不知道剪断哪根“线”会引发爆炸。
权责不对等：不出事则已，出事必背锅
这或许是问题的核心：责任归属。
老代码虽然“烂”，但它“没出事”。一旦你启动重构，所有的潜在风险便立即转移到了你的肩上。重构成功，众人觉得理所应当；一旦失败，所有的指责都会扑面而来：“原本好好的系统，你为什么要瞎折腾？”
职场中，这种现象屡见不鲜。事情办成了，功劳是团队的；搞砸了，责任就是你个人的。因此，许多开发者宁愿在“屎山”上继续小心翼翼地堆叠新代码，也不愿冒险去推倒重来。
根本原因在于，风险与收益严重不成正比。
永远短缺的时间与资源
即便你下定决心重构，公司也未必会给予支持。产品经理不断催促新功能，测试排期满满当当，老板只关注交付速度。
如果你提出需要两个月来重构代码并改善架构，很可能会被视作在“浪费时间”。
况且，重构绝非简单的代码重写。你需要先理解原有复杂逻辑，设计更优的新架构，补充缺失的自动化测试用例以确保安全，最后还要进行灰度发布与线上验证。整个周期可能比开发一个新特性还要漫长。
但业务不会等待。最终你只会听到：“项目排期这么紧，先完成新需求再说。”于是，技术债务如同高利贷，利滚利，越积越重。
心理层面的恐惧与不确定性
归根结底，程序员对重构的抗拒，还源于一种深刻的心理压力——对未知的恐惧。
你无法预知重构后是否会出现问题，是否会影响线上业务，是否会遭到领导批评，甚至影响绩效评估。这种不确定性带来了巨大的精神负担。
此外，许多程序员带有完美主义倾向，一旦决定重构，就希望一次性解决所有历史遗留问题。但现实是，你不可能一口吃成胖子。试图“推倒重来”的雄心，往往以“无从下手”的挫败告终。
于是，许多人选择了最“安全”的策略：不动。毕竟，老代码再烂，至少“还能跑”。动了之后会怎样？无人知晓。
那么，究竟该如何破局？
不要幻想一次性完成彻底重构，而应采取 “游击战术” 或 “男孩 scout 规则”：每次修复 Bug 或添加新功能时，顺手将你接触到的那部分相关代码进行优化。
今天抽离一个工具函数，明天拆分一个臃肿的模块。日积月累，整个系统的架构便能逐渐焕然一新。
这种方式风险可控，每次改动范围小，一旦出现问题也易于定位和回滚。并且，由于它被融入正常的开发流程中，无需额外申请专门时间，管理层通常也不会反对。
一个至关重要的经验是：重构之前，务必先补充测试用例。没有测试覆盖率作为安全网，你的重构无异于在悬崖边蒙眼行走。
总而言之，程序员面对老旧项目的纠结，本质上是技术理想主义与商业现实主义的冲突。
我们都渴望书写优雅、整洁的代码，但现实要求是按时交付、稳定运行的产品。因此，很多时候，我们不得不在这座“屎山”上小心跋涉，一边抱怨前人留下的坑，一边可能也在无意中为后人制造着新的麻烦。
这或许就是软件开发中，一种带着些许无奈的常态。
发表于 前天 19:07
|
查看: 4|
回复: 0
