软件开发中那些“迟早要还”的技术债

一个被推迟的函数

某个系统的订单导出功能，最初写的时候只考虑了导出当前页的数据。产品经理说：“先上线，后续再加全量导出。”开发人员说：“好，先这样。”

后续来了。三个月后，运营部门需要按月导出几万条订单做分析。当前页导出只能一次50条，运营人员要操作几百次。他们开始抱怨，开发人员被安排加上全量导出功能。

打开那段代码，发现当初写的时候完全没有考虑扩展性。查询逻辑和导出逻辑耦合在一起，分页参数写死在代码里。要加全量导出，几乎要重写。开发人员花了两天时间，改出了一版能用的，但代码更乱了。

又过了半年，财务部门需要导出带成本数据的订单报表。开发人员打开代码，看到那团已经改了多次的逻辑，叹了一口气。这段代码到现在还在被修改，每次改都很痛苦，但没有时间重写。

这个例子很普通，但很典型。软件开发中，很多问题不是一开始就存在的，而是“先这样”累积出来的。“先这样”说得越多，技术债欠得越多。迟早要还，但还的时候利息已经很高了。

技术债不只是代码质量问题

很多人一提到技术债，想到的是代码写的烂、没有注释、没有单元测试。这些确实是技术债的一部分，但不是全部。

更大的技术债在别处。

需求理解层面的技术债：需求评审时没有追问清楚“如果这个字段为空怎么办”“如果并发量大了会怎样”。上线后遇到这些情况，系统报错或者数据错乱。补丁加上去，代码越来越臃肿。当初多问一句，后面能省很多事。

架构设计层面的技术债：为了赶进度，选择了一个“最快能跑起来”的方案，没有考虑半年后业务扩展的需求。半年后业务真的扩展了，发现现有的架构根本撑不住。重构的工作量比重新写还大。

流程缺失层面的技术债：没有代码审查，没有自动化测试，没有发布规范。每个人按自己的习惯写代码、上线。系统越来越脆弱，谁都不敢动，谁都不敢改。

这些技术债不体现在代码行里，但影响比代码质量问题更大。

为什么会欠债

第一个原因是进度压力。项目排期紧，业务催得急，“先上线再说”成了最常见的借口。上线之后，下一个项目已经开始了，没人回头优化。当初的“再说”，变成了“永远不说”。

第二个原因是信息不对称。开发人员不知道业务半年后会扩展，产品经理不关心技术实现方案。双方都只看到了眼前的需求，没有人追问“以后会怎样”。信息没有在正确的时间传递到正确的人那里。

第三个原因是“破窗效应”。代码已经有点乱了，再加一点也无所谓。规范已经有点松了，再松一点也一样。一个人开始妥协，其他人跟着妥协。标准在不知不觉中降到了最低。等到有人想拉回来，已经拉不动了。

技术债不是某一个人的问题，是整个团队在特定环境下的行为结果。

哪些债必须还，哪些可以不还

技术债不是全都需要还。有些债还起来成本太高，收益太小，不如不还。

必须还的债是那些直接影响业务运行的。“用户点这个按钮经常报错”“订单状态偶尔会乱掉”“系统每周宕机一次”。这些问题已经造成了实际损失，不还不行。还的时候要优先解决，哪怕临时方案也行，先止血。

选择性地还的债是那些影响开发效率但不直接影响用户的。“改一个字段要改三个地方”“加一个接口要重启服务”“本地跑一次测试要十分钟”。这些问题业务部门看不见，但开发团队每天都在承受。有时间就还，没时间就忍着。但忍着也是有代价的，时间久了，团队士气会下降。

可以不还的债是那些“看起来不规范但没人在意”的东西。变量命名不够优雅、某个函数可以抽出来复用但一直没抽、配置文件里有个没用的参数。这些属于“完美主义”层面的问题，不影响功能、不影响性能、不影响维护成本，不改也没关系。

区分三类债的能力，是成熟团队和初级团队的分水岭。

新易编码在减少技术债上的作用

新易编码解决的是软件开发中一个具体的重复问题：业务规则的频繁变更导致代码反复修改。这类修改的技术债特点是：难度不高，但量大，而且频繁。每次改的不多，但每个月都要改。单次成本小，累积成本惊人。

物料编码规则变了，要改ERP代码；分类层级调整了，要改MES接口；客户编码格式变了，要改CRM报表。每次改动都要走需求、开发、测试、上线全流程。开发团队被这类需求占用了大量时间，核心业务优化反而没空做。

新易编码把编码规则的配置和管理从业务系统中抽离出来。规则变更时，业务人员在平台上自己改，不需要开发人员介入，不需要走代码上线流程。开发团队不用再为编码规则的频繁变更反复写代码、反复测试。

这种模式减少的主要是“低价值、高频率”的技术债。开发人员的时间被释放出来，去做真正需要技术能力的工作。业务人员自己维护规则，响应速度也更快。

几个可以减少技术债的实践

代码审查不是为了找谁写得不好，是为了在代码被更多人使用之前，发现潜在问题。审查时关注三个问题：这段代码容易改吗？容易测吗？容易懂吗？这三个问题的答案如果是“是”，技术债就不会太高。

写测试不是为了追求覆盖率数字，是为了给未来修改代码的人一个安全网。没有测试的代码，没人敢改。每改一次，测试覆盖率就降一点，直到没有人再愿意碰它。测试是还债的工具，也是防止新债的工具。

重构不能只靠“以后有时间再做”。以后永远不会有时间。把重构拆成小任务，每次改动时顺便做一点，而不是攒一个大版本集中重构。改一个函数时，顺便把它变清晰一点；加一个新功能时，顺便把相关的老代码整理一下。积少成多，比集中重构风险低、效果好。

需求阶段多问一个“如果”。如果数据为空怎么办？如果并发量大了怎么办？如果这个字段以后要扩展怎么办？这些问题在需求阶段回答，成本几乎为零。在开发阶段回答，成本是重新设计。在上线后回答，成本是加班改Bug。

结语

技术债不是软件开发中的“意外”，它是软件开发的一部分。只要系统在演进，技术债就一定会产生。关键不是“能不能没债”，而是“能不能把债控制在可管理的范围内”。

可管理的标准是：知道债在哪里、知道哪些债要还、知道哪些债可以不还、知道还债的优先级。不知道债在哪里的团队，不是因为没有债，是因为没有去发现。

新易编码在这个场景中解决的是“编码规则频繁变更”这个具体问题。把编码规则从业务系统中抽离出来，让业务人员自己维护，开发人员不必为这点事反复写代码、反复测试。这是一个很小的切口，但它说明了一个道理：把那些“变来变去但又不复杂”的规则交给业务人员自己管，开发团队就能少欠很多低价值的债。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码