"这段代码先这样，后期我们再重构。"
我相信这是软件开发历史上被引用次数最多的一句话。每一次技术方案评审，每一场赶进度的sprint回顾，每一个被deadline追着跑的凌晨，这句话都会准时出现。它不是承诺，它是诅咒——说的时候心安理得，还的时候痛不欲生。
我见过一个团队，靠着这句话撑了四年。
四年前他们接了一个政务系统项目，周期紧、需求急，上线时间表比正常开发快了将近一半。技术负责人拍胸脯说"先把功能跑通，后续慢慢优化"。于是很多模块的架构设计是"够用就行"，文档是"后面补"，注释是"代码即文档"。注释只有两种：一种是"这里有问题，以后改"，另一种是空白的。测试覆盖率？不用说，能跑就行。这句话像是万能挡箭牌，所有本该在设计阶段解决的问题，都被它挡到了"以后"。项目经理听到这句话就头疼，因为"以后"永远不是真正的计划，是一张空头支票。
四年后，这个系统还在跑，但已经没人能完整地说清楚它的工作原理了。业务逻辑在代码里，代码的意图在注释里，注释的更新在空气里。三个东西各过各的，唯一相同的是名字都叫"系统"。
核心模块的代码是三年前一个外包工程师写的，那人早就离开了公司。系统里有一段逻辑，绕来绕去绕了七八层if-else，每次改需求都要先花两天时间理解这段代码在做什么。有个新来的同事试着重构这块，结果改出一个线上bug，被紧急回滚，从那以后再没人敢动它。那段代码成了事实上的禁区，所有人都知道它有问题，但所有人都选择绕着走。绕着走不产生新的bug，但绕着走的人会越来越累，因为每次绕都要消耗精力，而这份精力本来可以用在更有价值的地方。
代码和文档的关系，大概是这样的：代码是实际运行的系统，文档是两年前写的"预期中的系统"。两者偶尔重合，大部分时候各过各的。新人入职，先看文档，觉得这个系统设计得还挺清晰；上手干活，发现文档里说的和代码里跑的完全是两回事。那种认知被颠覆的感觉，每个经历过的人都懂。有时候你觉得自己在看一个现代建筑的设计图，实际你站在一个满是补丁的危房里。文档说这里应该有个窗户，你敲了敲墙才发现这里其实是承重墙，窗户开在隔壁。
这种"两层皮"的现象，本质上是技术债的累积。
技术债不是一夜之间产生的。它来自每一次"先这样"的妥协，每一次"后面再优化"的承诺，每一次因为赶进度而跳过的设计评审。每一笔债都会产生利息——你今天为了赶工期少写了一个接口文档，下周改接口的时候就要多花两个小时去猜这个接口原本的逻辑是什么。你跳过了单元测试，上线后发现bug，影响了用户留存，这个锅也要算进技术债的利息里。更可怕的是，利息是复利计算的，越欠越多。到了后期你发现，你不是在开发新功能，你是在给旧债还利息。
巴别鸟的团队文档管理功能，某种程度上就是来解决这个问题的。它不是银弹，但它提供了一个让文档和项目同步更新的机制——代码仓库和文档放在同一个空间，文档变更记录可追溯，版本历史不会丢失。对技术团队来说，这种"文档跟着代码走"的约束，比任何代码规范都有效。它把文档从"想起来就写，想不起来就算了"的状态，变成了"不写就没法干活"的状态。当工具逼着你保持一致，你就不需要靠自觉了。自觉是最靠不住的东西，因为它取决于人，而人是最不稳定的因素。
当然，我不是说用了巴别鸟技术债就消失了。债还在，只是还起来没那么痛苦了。你还是需要还，但至少你知道债在哪里，有多少，什么时候欠的，欠的是谁。账本清晰了，还债的效率才能提高。
回到那个政务系统团队。他们后来花了三个月时间做了一次彻底的文档审计，把所有能追溯到的历史决策、技术方案、接口说明全部整理成册，同时给代码里所有核心逻辑补上了注释。这三个月没有交付任何新功能，但从长远来看，这是他们四年来第一次真正"还债"。三个月不交付新功能，听起来很奢侈，老板当时很不满意，在季度汇报里点名批评了技术团队。但事后算账，那三个月的还债期省下了后来将近八个月的混乱和返工时间，ROI其实是正的。只是这个账大多数人不愿意在开始之前算，只愿意在结束之后后悔。
问题是，大多数团队的老板不会给你这三个月。他们觉得"系统不是跑得好好的吗为什么要停下来整理文档"，觉得三个月不做新功能是不可接受的浪费。但不主动还债，就只能被动还债，前者是可控的，后者往往以事故的形式到来，不可控且代价更高。这种时候，技术负责人能做的，就是尽可能把债务的增长速度降下来。每次技术方案评审，多问一句"这段设计有没有人写文档"；每次代码review，提醒一下"注释补一下"；每次发布，把变更记录同步更新。这些小事积累起来，能让四年后的你，少流一点冷汗。
"先这样，后期再重构"这句话本身没错，技术债务是现实存在的，项目进度永远比理想架构重要。但欠债要还，而且越早还越划算。你拖得越久，利息越高，等你想还的时候可能已经还不起了。
