程序员常遇到的三种技术债务：代码、数据和架构

这些架构决策可以将项目推向完全不同的方向。以上面的例子为例，在流量平稳且 QPS 较低的情况下使用中间发布 / 订阅队列，可能会以维护和调试的形式增加架构债务。但是，如果流量非常陡峭并且服务 B 无法处理峰值负载，那么推送模型将是这一领域产生债务最多的。

架构债务的偿还通常跨越更长的时间周期。长反馈循环更难学习，而且这种架构债务很容易被忽略。SWE 在硅谷的平均任期为 18 个月，但发现早期架构决策的问题可能需要更长的时间！当优步发展到 1000 个微服务和 2000 位工程师时发生的 事情 就是一个完美的例子。走微服务路线确实在短期内提高了他们的速度，但后来这条路线为整个系统带来了可调试性和延迟方面的债务。

架构债务的成本可能很高（糟糕的 on-call 计划，系统僵化且难以推理，缺乏可调试性），并且与代码债务相比更难偿还。深入分析你们正在应对的系统，并了解项目做出了哪些影响服务特性（可维护性、灵活性、可靠性等）的关键决策（不管这些决策明确与否），在任何时候都是非常有价值的行动。其中一些决策可能是故意为之的，并带来了有趣的后果。

最后，即使人们在试图避免架构技术债务时，这些债务也可能会偷偷增加。过早的优化通常会导致我们最终产生债务。一个例子是为 10k QPS 设计的一个 Web 服务，最后只用来应对 1/100 的流量。许多架构决策可能会各自冲突，而且很容易因为不必要的复杂性而产生债务。

数据和建模技术债务

数据建模似乎不像以前那么常见了。曾经有一段时间，大多数工程师都要定期从事数据建模工作。现在人们通常将其委托给一个特殊的团队（“用户服务来处理”），或者使用一些允许他们完全忽略这类问题的工具（在这方面的例子有 graphQL、mongoDB）。

数据建模的影响在短期和长期范围都存在。从短期来看，在模型和类型上花费大量时间会让人感觉成本很高，因此人们很容易选择一些非常灵活的东西来优化早期迭代和灵活性。然而，我已经看到这是错误的方式（把所有内容都放在一个 JSON 中，并在客户端上进行所有过滤工作），最后我们会在回填、数据完整性修复和重构方面多做很多工作。良好的数据建模对代码和系统架构都有正面影响，也就是说这 3 类技术债务其实是相互关联的。然而，数据是最难做对的事情之一，也是最难改变的事情之一。所以数据技术债务应该被认真对待、积极识别、正确处理。实际上，当你想要更改你的数据模型时，这种更改的依赖关系图通常是非常模糊的。它需要涉及代码更改、数据库迁移和回填，所有这些都可能具有复杂的依赖关系，并且可能影响多个系统、团队或服务。

我个人认为，这个技术债务类别的偶然性是最大的。理解读写模式和数据模型之间的关系可以帮助你有效预防这种债务方面，或者至少有意识地承担它。预测哪里需要灵活性、哪里不应该存在灵活性是非常微妙的问题。随着时间的推移，人们处理这种问题时会更有经验，但必须有意识地应对它们才行。

小结

我们提到了代码、数据和架构类别的技术债务。下次你做设计决策或审查代码时，可以试着找出你所承担的债务，并就此作出明确的讨论：这些债务可能的后果是什么么时候才能得到解决常的开发工作中，架构和数据类技术债务是最难注意到的，但它们以后的消化成本却是最高的，因此值得你认真应对。

最后我想强调的是，技术债务并不总是坏事。使用 MongoDB 来原型化想法或编写一个丑陋的函数来解决关键错误都可以是合理的做法，并且可能是最佳方案。问题是不要故意去做一些增加技术债务的事情。

·················· END ··················

专注架构技术学习及分享，职业与认知升级

坚持分享接地气儿的干货，期待与你一起成长

「架构精进之路」专注架构研究，技术分享

点个在看少个 bug p> 文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93918 人正在系统学习中