软件越写越烂?聊聊研发团队如何对抗熵增

前几天跟一个做技术总监的老朋友吃饭，他吐槽说团队现在有个怪现象：

新功能开发速度越来越慢，改一个bug能带出三个新bug，测试环境三天两头崩，代码评审越来越像走过场。

“明明人没少，怎么活儿越干越费劲？”

我说恭喜你，你正在经历一场典型的研发熵增。

什么是研发熵增

物理学说，一个孤立系统总是趋向于熵增，也就是从有序走向无序。你刚收拾好的房间，不刻意维持，几天后就会乱；你刚梳理清楚的代码，不刻意治理，几个月后就会烂。

软件研发也是一样。

项目启动时，架构清晰、命名规范、文档齐全、测试覆盖到位。可随着需求不断叠加、人员来来往往、deadline一个接一个，系统就开始“自发地”变乱：

代码里开始出现“先这样吧，回头再改”

测试用例从“全覆盖”变成“挑重点跑”

文档停留在三个月前，没人记得更新

同一个功能，三个人写出三种风格

这不是谁不努力，这是熵增在起作用。

熵增在开发和测试中的典型症状

开发侧：

有个项目，初期代码整洁得像教科书。半年后我再看，一个用户登录功能，Controller里写了三百行，业务逻辑、参数校验、数据库操作、日志埋点全揉在一起。我问为什么不拆一拆，开发说：“拆了怕影响其他功能，现在能跑就行。”

这就是熵增的典型表现——局部最优解绑架了全局可维护性。

还有个更隐蔽的：命名越来越随意。一开始叫UserService，后来叫UserService2，再后来叫NewUserService，最后叫UserServiceFinal。新人进来问区别，没人说得清。

测试侧：

测试用例是最容易熵增的地方。一开始每条用例都有明确目的，后来为了赶进度，开始出现“验证功能正常”这种万能用例。再后来，失败用例没人修，直接标记为“已知问题”。最后，测试报告变成“通过率98%”，但没人知道那2%是什么。

更可怕的是测试环境。多个分支共用一套环境，数据库里躺着半年前的数据，配置项靠口口相传。新人搭环境要两天，老人说“我帮你看看”，然后默默改了三个配置文件，也没记录改了什么。

对抗熵增的三个实操方法

熵增不可逆，但可以对抗。关键不是“消灭混乱”，而是“持续投入能量维持秩序”。

第一，把重构写进迭代计划。

很多团队把重构当“额外工作”，需求都做不完，哪有时间重构？结果就是代码越来越烂，开发越来越慢，形成恶性循环。

我们的做法是：每个迭代固定留出10%的工作量给重构。不是大张旗鼓地重写，而是小步快跑。比如这周把登录模块的校验逻辑抽出来，下周把订单查询的SQL优化一下。每次改动不大，但持续做，代码就不会烂到无法维护。

关键是：重构不是可选项，是迭代的固定组成部分。就像房间每天都要收拾，不是等乱到没法住才大扫除。

第二，让测试用例“活”起来。

测试用例熵增的根源是：写的时候有人管，维护的时候没人管。

我们的解法是给每条用例加“主人”。每条自动化用例都有明确的负责人，失败了自动通知到人。不是“测试组的事”，是“你的用例你负责”。

另外，每周花半小时做“用例瘦身”。删掉重复的、过时的、永远不跑的用例。测试用例不是越多越好，是越有效越好。一千条跑十分钟但没人看的用例，不如一百条跑一分钟但每条都有人盯的用例。

第三，建立“信息辐射源”。

熵增在信息层面的表现是：知识从共享变成私有。老人知道，新人不不知道；文档里写的和实际做的不一样。

对抗方法是把所有关键信息“辐射”出来，而不是藏在某个人脑子里。

环境配置写进README，新人照着做就能跑起来

架构决策记录在ADR里，为什么选A不选B有据可查

接口文档自动生成，代码变了文档跟着变

每周一次“技术同步会”，不聊进度，只聊“这周我踩了什么坑”

这些事看起来小，但坚持做，团队的“信息熵”会显著降低。新人上手快，老人不重复踩坑，协作效率自然上来。

最后说点实在的

熵增这件事，没有一劳永逸的解法。

你今天把代码整理干净，明天加个需求又可能变乱。你今天把文档更新到位，下周改个架构又可能过时。这不是你做得不好，这是系统的宿命。

但你可以选择：是等系统烂到无法维护再推倒重来，还是每天花一点力气，让它烂得慢一点。

对抗熵增的本质，不是追求完美有序，而是持续投入。 就像健身，不是练出肌肉就一劳永逸，而是保持训练习惯，让身体维持在一个健康状态。

软件研发也一样。那些看起来“一直很整洁”的项目，背后都是团队日复一日的刻意维护。

所以，下次你觉得“代码怎么又乱了”的时候，别急着怪人。想想熵增，然后问自己：我今天做了什么来对抗它？

哪怕只是删了一条没用的测试用例，改了一个含糊的变量名，更新了一行过时的文档——都是在给系统注入秩序。

这就够了！