我的20年职业生涯：全是技术债( 四 ) _技术

“我希望看到当下诞生的新项目能始终牢记长期可维护性的重要意义，甚至把它当作一项基本设计前提。毕竟真的没多少人有能力维护陈旧软件项目。尽管地球人口仍在增加，但掌握足够技能来维护这些古早软件的开发者数量一直都跟不上。”
3国内技术从业者怎么看？
针对技术债问题，InfoQ 曾采访过国内一些技术从业者。
百分点 CTO 刘译璟认为，判断技术债务的重点在于“哪些事情是应该做的”，它是一个因组织而异、因项目而异、因人而异的过程，例如以下一些方面：

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

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

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

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

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

债务是避免不了的，时刻判断“持有债务的价值”，当价值很低时要尽快处理。
腾讯研发总监王辉表示，如果人力、物力和工期等资源丰富，能去优化的就都可以做到极致。但通常，资源都是不丰富的，或者说是捉襟见肘的，那就要根据实际业务情况来看。腾讯一向的方式是“先抗住再优化”，项目是否真的到了非优化不可的地步，是否真的到了不优化随时都可能宕机的时候，如果先抗住了，就等业务占领了市场，站住了用户，到了项目进度慢下来之后，一些优化再开展起来，此时可以要求高可用、高性能、高并发等。
“如果项目资源允许，一些稍微过度的优化和重构，个人认为是可以被接受的，保持团队的技术热情是不错的，但如果资源不允许，就要数着钱花，判断技术债务的合理性，如何更好的还债，是否真的到了非还不可，是否真的到了影响业务发展，需要与业务优先级一起看，业务错过一个时间窗就可能永远错过，有些技术债务还可以后期再还。”王辉总结道。
参考链接：
https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt
https://www.infoq.cn/article/xgP9W*MC6Svi9Zcqd5KX
https://news.ycombinator.com/item?id=35955336
https://www.reddit.com/r/programming/comments/13ihrtx/my_20_year_career_is_technical_debt_or_deprecated/