技术债 笔记

1. 技术债 笔记

1.1. 什么是技术债

1992 年, Ward Cunningham 在敏捷宣言中首次提出了"技术债"概念, 主要指有意或无意地做了错误的或不理想的技术决策所累积的债务。随后, 《重构》一书的作者 Martin Fowler 基于 Cunningham 的比喻, 创建了一个"技术债务四象限", 包括:

• 鲁莽/有意: “我们没有时间去设计”;
• 谨慎/有意: “我们必须现在交付, 之后再处理因为追求速度所产生的结果”;
• 鲁莽/无意: "什么是分层? ";
• 谨慎/无意: “我们现在知道应该怎么做了”。

1.2. 讨论

前段时间, Reddit 上有关技术债的话题再次引起程序员的广泛讨论。用户 spo81rtyOP 表示, “大多数软件的实际使用寿命也就 5 到 10 年。即便软件能幸存下来, 完全由过时技术栈编写这一现实也会让它的路子变得很窄。这就是软件工程师的真实命运。”

与此同时, 在过去的 20 多年里, 很多编程语言也都"失宠"了, 比如 Perl、Delphi、Fortran、FoxPro、ColdFusion。也许这些古老的编程语言还存在某些应用程序中, 但大多数情况下, 还应用这些编程语言的公司必须要对旧的应用程序进行现代化改造, 并将其淘汰。如果你用这些过时的编程语言构建程序, 最终的结果可能只有重写, 因为很难再找到使用这些语言的程序员了。

在 21 世纪初, 人们认为 Adobe ColdFusion 是最热门的产品, 但在今天呢? Ruby on Rails 也可能走上 Adobe ColdFusion 的老路, 它已经失宠了, 并且很难找到使用它的开发人员。曾经 Ruby on Rails 独有的东西, 现在也可以在其他语言中使用了。

Watson 表示, 编程语言来来往往, 开发人员不希望学习工作中不需要的技能。同时, 开发人员跳槽的速度也很快, 他们总是希望自己的简历上有一些热门的新东西。

Watson 预测, WebAssembly 最终会超越当今的前端开发, 一个全新的世界将不断发展。

用户 chesterriley 则想象了一个极端可能: 也许未来终有一天, 人们会继续使用 100 年前就编写出来的代码。最终的大赢家可能会是 Unix 实用程序或者 TCP/IP 代码之类, 又或者是某些编译器、运行时引擎或解释器。还有来自 Linux 或 Windows 等操作系统的代码。人们可能突然发现, 自己修复的错误居然诞生自 100 多年前。

当然, 也有些代码并没真正受到当今炒作的影响。有趣的是, 这类代码大多集中在服务器端。虽然一直有强大的力量在 “颠覆” 微服务、Lambda 函数等服务构建方式, 但如果忽略掉这些实现细节, 那服务器的内存空间里肯定还有 db+ 服务在运行、也还有空闲周期没有利用起来。

“我希望看到当下诞生的新项目能始终牢记长期可维护性的重要意义, 甚至把它当作一项基本设计前提。毕竟真的没多少人有能力维护陈旧软件项目。尽管地球人口仍在增加, 但掌握足够技能来维护这些古早软件的开发者数量一直都跟不上。”

1.3. 国内技术从业者怎么看?

百分点 CTO 刘译璟认为, 判断技术债务的重点在于"哪些事情是应该做的", 它是一个因组织而异、因项目而异、因人而异的过程, 例如以下一些方面:

• 组织上要求做但没做的: 制度、流程、规范、分享学习等;
• 业务和技术上要求做但没有做的: 功能、性能、安全、高可用、扩展、监控、辅助工具等。

如果按照软件工程环节分类, 技术债务可以分为: 需求分析、方案设计、架构设计(逻辑架构、功能架构、数据架构、部署架构、运行架构等等)、编码、测试、发布等。如果按照产出物类型分, 可以分为:

• 文档类: 管理过程文档、需求分析文档、设计文档、测试案例文档等;
• 代码类: 代码、脚本、规范等;
• 软件包类: 产品软件包、依赖软件、依赖资源等;
• 环境类: 开发环境、测试环境、预上线环境、生产环境等。

至于如何决定要重写还是继续维护, 需要判断"继续维护的收益"和"重写的收益"哪个更大, 来决定继续维护还是重写。可以综合考虑如下几方面的收益:

• 开源: 提升现有业务收入、支持新业务的开拓;
• 节流: 节省维护人员、节省运营费用;
• 组织: 人员结构调整、组织能力培养。

债务是避免不了的, 时刻判断"持有债务的价值", 当价值很低时要尽快处理。

腾讯研发总监王辉表示, 如果人力、物力和工期等资源丰富, 能去优化的就都可以做到极致。但通常, 资源都是不丰富的, 或者说是捉襟见肘的, 那就要根据实际业务情况来看。腾讯一向的方式是"先抗住再优化", 项目是否真的到了非优化不可的地步, 是否真的到了不优化随时都可能宕机的时候, 如果先抗住了, 就等业务占领了市场, 站住了用户, 到了项目进度慢下来之后, 一些优化再开展起来, 此时可以要求高可用、高性能、高并发等。

"如果项目资源允许, 一些稍微过度的优化和重构, 个人认为是可以被接受的, 保持团队的技术热情是不错的, 但如果资源不允许, 就要数着钱花, 判断技术债务的合理性, 如何更好的还债, 是否真的到了非还不可, 是否真的到了影响业务发展, 需要与业务优先级一起看, 业务错过一个时间窗就可能永远错过, 有些技术债务还可以后期再还。"王辉总结道。