极客视点
极客时间编辑部
极客时间编辑部
113243 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:49
登录|注册

如何直面技术债务?

讲述:丁婵大小:8.00M时长:05:49
技术债务仿佛是个筐,什么东西都可以往里装,然而当你企图倒光筐里的东西时,却发现每个人看到的东西都不一样,甚至都数不清里面有些什么。此前,百度 DuerOS 首席布道师曹洪伟在其个人公众号“喔家 ArchiSelf ”总结了技术债务的类型、组成、应对方法等,希望能帮助你更好地了解技术债务并处理它。

技术债务的现象与类型

当出现如下现象的时候,说明技术债务开始累积:
类似的代码在不同的项目/产品间迁移;
代码已经稳定但回归测试的成本在增加;
每一次交付的成本逐渐增加;
类似 feature 开发的周期开始变长;
在既有代码上开发,还不如推倒重来。
技术债务的类型是由产生的原因和方式来定义的,其中一种分类如下:
战略债务:为了战略利益(例如首次上市)故意为之,并长期存在。
战术债务:在知情的情况下为了快速收益而产生,适用于短期。
疏忽债务:在不知情的情况下,由于缺乏知识和意识而产生。
增量债务:定期不慎产生的而导致增量债务。
技术债务还包括那些现在选择不做的内部事务,但会影响未来的开发工作,例如延迟重构等。

技术债务的组成

技术债务是多方面的,涉及技术的多个维度,比如:
代码债务:代码重复、违反静态分析工具和代码异味等。
设计债务:设计异味、违反设计规则等。
架构债务:违反架构规则,对非功能性约束认知不足等。
测试债务:缺乏测试、测试覆盖面不足和不正确的测试设计等。
质量债务:缺乏稳定性和健壮性的技术验证,QA 的自动化不足等。
配置债务:版本控制的模糊,环境参数的混淆等。
平台债务:平台经验的匮乏,云服务融合与应用不足等。
文档债务:存在重大问题的文档、缺乏文档和文档过期等。
以上每一类技术债务,都有着相应的原则和处理方法。

如何直面技术债务?

面对已知的技术债务,普遍的经验是防止技术债务的积聚,以及有计划地偿还技术债务。
防止技术债务产生的主要方法是了解开发团队存在的技术债务。开发团队必须全面了解技术债务,以及债务对项目的影响。合适的流程可以帮助开发团队避免技术债务积累,例如代码、设计、架构和测试的审查等。而且,这些流程必须是务实的,否则事与愿违。
对于偿还技术债务而言,首先是识别并记录现有债务,优先处理异味,在每个迭代中分期偿还债务。同时,留意可能出现的大规模债务偿还,属于不同维度的债务实例相互影响。在某些情况下,即使债务很高,也不值得偿还技术债务。这些情况包括原型、概念实现和即将废弃的产品所产生的技术债务。此外,如果计划将一个传统项目迁移到一个新的技术、平台或架构,不偿还的技术债务是明智的,因为相关的债务可以在迁移过程中解决。
还有一种情况是,由于不提倡重复造轮子,你所使用的第三方软件和开源软件产生的技术债务同样会对你造成影响。它们的 Bug 会成为你的 Bug,它们的安全漏洞也会成为你的安全漏洞。要想了解这种债务问题的严重性,需要审查代码中使用了哪些第三方开源包与依赖。并评估风险和问题,还需要紧密追踪这些软件的补丁、升级信息及 Bug 报告等。
知道问题的严重性是一方面,修复问题则是另一方面。对最新的发布打补丁并非易事,最好能在外围打补丁,因为补丁并非总是适合于你所使用软件的方式。另外,如果每当出现一个 Linux 补丁时需要立刻打上,那就说明架构可能有些问题。
升级更是一个大问题,升级到最新的 OS、RDBMS、VM 等都涉及很高的代价与风险。虽然可以通过升级的方式获得可伸缩性、管理性及新特性等方面的优势,不过升级项目还需要关注一些潜在问题,比如功能回归、兼容性、操作流程的变化、对其他系统的依赖变化等等。升级之后,大多数软件会变得更大而不是更好,也许会加入很多没用的新特性,这也意味着需要花更多的时间进行安装、配置和测试。你需要搞清楚变化的地方,重新进行测试和调优。
其实,人们谈及技术债务的时候往往都清楚它的种种弊端,却缺乏主动使用技术债务的勇气。 债务具有着现金价值,在金融领域中,货币杠杆的作用显著。对企业而言,现金流更是关键因素,所以,没有必要谈债色变,没有债的企业未必都是一流的好企业。
以上就是曹洪伟对技术债务的理解与总结,你也可以点击原文链接了解更多内容。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 小斧
    技术债务的组成 技术债务是多方面的,涉及技术的多个维度,比如: 代码债务:代码重复、违反静态分析工具和代码异味等。 设计债务:设计异味、违反设计规则等。 架构债务:违反架构规则,对非功能性约束认知不足等。 测试债务:缺乏测试、测试覆盖面不足和不正确的测试设计等。 质量债务:缺乏稳定性和健壮性的技术验证,QA 的自动化不足等。 配置债务:版本控制的模糊,环境参数的混淆等。 平台债务:平台经验的匮乏,云服务融合与应用不足等。 文档债务:存在重大问题的文档、缺乏文档和文档过期等。
收起评论
大纲
固定大纲
技术债务的现象与类型
技术债务的组成
如何直面技术债务?
显示
设置
留言
1
收藏
75
沉浸
阅读
分享
手机端
快捷键
回顶部