一个技术债务的例子

我们有一个学校考试系统，其中一个功能就是发布考试项目的成绩。

今天说的不是发布成绩的功能，而是查看成绩发布状态的功能。这个简单的查询功能，会有什么样的技术债务呢？

最开始的时候，查询发布状态是这样的：

1. 前端查询考试项目的成绩发布状态；
2. 后端返回查询结果。1表示未发布，2表示已发布。

不能再简单了。

后来用户提出了需求，希望成绩发布能按照考试科目，一科一科来发布。这样对前端来说，查询结果就不再是一个“是”或“否”的状态，而是要体现每个科目的成绩是否发布。

于是前端要求：

1. 查询结果新增一个状态：3表示部分发布；
2. 新增一个查询接口，一次返回每个科目的成绩发布状态。

那么前端的逻辑就变成了：先查询整个项目的成绩发布状态；如果返回值为3，则进一步查询每个科目的成绩发布状态。

当这个要求提出来的时候，后端开发人员并不觉得有什么问题（相信你看到这里也没发现有什么问题）。所以两边就商量好，开始各做各的。

但是当后端做到一半，发现问题了：什么叫做“部分发布”？就是要先查询每个科目的成绩发布状态，只有当存在已发布成绩的科目，但不是全部科目都发布成绩时，才算“部分发布”。

• 所以当前端第一次查询时，后端就需要查询每个科目的成绩发布状态，以决定返回值会不会是3；
• 然后当前端第二次查询时，后端还要再查询一次每个科目的成绩发布状态。

也就是同一个东西查了两次。而实际上正确的做法，就是改造第一个接口，在返回整个项目成绩发布状态的同时，也返回每个科目的成绩发布状态。

这个技术债务造成了什么后果呢？

首先是界面的加载慢了，本来只需要一次请求，现在当项目存在部分发布时，变成了两次。

其次是不必要的增加了后端的负载。大家一般都会选择在第一次查询时缓存科目的成绩发布状态，但这个缓存是完全没有必要的。而如果不缓存，势必会进一步延长界面的加载时间。

这个例子虽然很小，但是这里面的解决问题的思路如果沿用到大型系统里面去，结果可能是灾难性的。你有能力设计一个小系统，运行得很好，但是如果对于一个大型系统，要你依据需求进行变更的话，就必须小心翼翼，极力避免上面这种脑子抽风样的做法，因为某些决定做出来之后，想再改就很难了。