话题：如何正确对待技术债？
极客时间编辑部
讲述：子阳大小：6.47M时长：04:43
在上一篇文章中，我们探讨了程序员面对技术债到底是该继续维护还是推倒重写，以及怎样避免在技术债务上浪费过多时间的方法，InfoQ 针对这一话题采访了多位国内技术从业者，试图对这一问题进行深入剖析。以下为重点内容。
1. 百分点 CTO 刘译璟
技术债是指在软件工程中“应该”做而“没有”做的那些事情，判断技术债务的重点在于“哪些事情是应该做的”，它是一个因组织而异、因项目而异、因人而异的过程，例如以下方面：
组织上要求做但没做的：制度、流程、规范、分享学习等；
业务和技术上要求做但没有做的：功能、性能、安全、高可用、扩展、监控、辅助工具等。
如果按照软件工程环节分类，技术债务可以分为：需求分析、方案设计、架构设计（逻辑架构、功能架构、数据架构、部署架构、运行架构等等）、编码、测试、发布等。如果按照产出物类型分，可以分为：
文档类：管理过程文档、需求分析文档、设计文档、测试案例文档等；
代码类：代码、脚本、规范等；
软件包类：产品软件包、依赖软件、依赖资源等；
环境类：开发环境、测试环境、预上线环境、生产环境等。
至于是否重写或继续维护，需要判断“继续维护的收益”和“重写的收益”哪个更大。可以综合考虑如下几方面的收益：
开源：提升现有业务收入、支持新业务的开拓；
节流：节省维护人员、节省运营费用；
组织：人员结构调整、组织能力培养。
债务是避免不了的，时刻判断“持有债务的价值”，当价值很低时要尽快处理。
2. 腾讯研发总监王辉
团队为了短期利益、因为技术人员能力或者历史原因，造成的必须为之付出代价的事情，就是合理的技术债务。
技术债务通常可以分为：
因短期利益，追求快速上线导致的粗制滥造；
因为人员技术能力和疏忽，导致的项目质量差；
因方案选型不当，方案设计不合理导致的推倒重来；
项目合并、团队合并带来的代码融合，引起的效率低下。
如果人力、物力和工期等资源丰富，这种能优化的问题就可以做到极致。但通常，资源都是不丰富的，那就要根据实际业务情况来看，腾讯一向的方式是“先抗住再优化”，项目是否真的到了非优化不可的地步，如果先扛住了，就等业务占领了市场，项目进度慢下来之后，再开展优化，此时可以要求高可用、高性能、高并发等。
3. 国双技术总经理何恺铎
我们呼吁更多企业高层能理解技术债务，它也真的是企业债务的一种。
部分技术债务实质上和技术团队的组织架构密切相关，尤其对于大型研发团队，很容易出现各自造轮子的情形，造得不够好的轮子很容易成为债务负担。所以，在合适粒度上的基础设施团队对避免底层技术债务的产生很有帮助，前提是该基础团队要有一定影响力，也要善于沟通。
至于是继续维护还是推翻，不能一概而论，要看对应业务是否有长期规划和决心，为了长期成功，可考虑择机重构，但如果业务本身有试水性质或者尚不明朗，那也许就先别折腾。
4. 资深技术专家焦振清
是否需要面对技术债务，主要还是取决于当下的业务场景是否会继续发展。如果预估会继续发展，就需要处理技术债务，重写的概率会高一些。如果预估业务继续发展的可能性不大，而当下的解决方案存在各种隐患，那么选择维护的概率会高一些，甚至继续保持现状也是极有可能的。还有一种可选择的做法是将项目交给新人，以此来锻炼新人，
除上述观点外，关于技术债务的利息，很少有人提起，也几乎从来没人在决策时拿来做筹码，技术债务应该是有生命周期的，如果生命周期长于该技术产品本身的生命周期，就不值得改。但是，团队还是应该对技术债务具备一定认识，如果团队起点的不良代码就非常多，或者出现大量人员变动，还是应该将解决问题放在首位，避免互相甩锅的情况发生。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论