——当遗留代码遇上文档驱动开发
这篇文章的由来
之前我写了《用一份 .md,把想法变成产品》系列,讲的是怎么从 0 到 1 用文档驱动开发。文章发出后,收到很多反馈。其中最多的问题是:"这套方法挺好,但我们是老项目,代码都写了好几年了,还能用吗?"
有人更直接:**"新项目谁不会写文档?关键是屎山代码怎么办?"**这个问题很现实。大部分团队面对的不是"如何从零开始",而是"如何在已有的烂摊子上改进"。所以,这个系列就是来回答这个问题的。
一、遗留代码为什么这么难?
让我们先诚实地面对一个问题:为什么遗留代码这么难搞?
老项目更难,但更普遍
坦白说,老项目引入文档驱动比新项目难 10 倍。为什么?
**新项目是一张白纸:**你可以按理想状态设计,文档和代码同步推进。
**老项目是历史包袱:**代码已经写了,很多设计决策的人已经离职,文档要从头补。更难的是:没人知道该从哪里开始。
但老项目也有优势:**痛点更明显。**新人看不懂代码?知识流失严重?改个需求提心吊胆?这些痛点会成为推动力。
**新项目是一张白纸:**你可以按理想状态设计,文档和代码同步推进。
**老项目是历史包袱:**代码已经写了,很多设计决策的人已经离职,文档要从头补。更难的是:没人知道该从哪里开始。
但老项目也有优势:**痛点更明显。**新人看不懂代码?知识流失严重?改个需求提心吊胆?这些痛点会成为推动力。
所以,这个系列不讲理想状态,讲的是:如何在现实约束下,渐进式地引入文档驱动。
二、两种思路,两种结局
面对同一个老项目,不同的处理思路会带来完全不同的结果。让我们看两个真实的案例。
周五下午 5 点的噩梦
周五下午 5 点,你正准备关电脑下班。
产品经理突然出现在你工位旁:"这个支付功能能不能支持花呗分期?客户要得急,下周要上线。"
你心里一紧。
打开 IDE,找到 PaymentService.java,2000 行代码扑面而来。翻到支付核心逻辑,发现分散在 8 个文件里。上次改这块代码的同事 3 个月前离职了,留下的注释只有寥寥几行。
Git 历史显示,这个文件被 15 个人修改过,每次都是"临时补丁"。
你不知道:
-
为什么这里要用这个状态?
-
这个重试逻辑是处理什么场景的?
-
改了这里会不会影响其他支付方式?
这就是老项目的现状。
你可能会说:"这不就是技术债务吗?重构不就完了?"
但问题是:有多少项目有机会推倒重来?