DevOps 实战笔记
石雪峰
京东商城工程效率专家
37393 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

15 | 技术债务:那些不可忽视的潜在问题

技术债务比例 = 修复已有技术债务的时间 / 完全重写全部代码的时间
技术债务是基于SQALE方法计算出来的
原则:良性下降趋势、优先解决高频修改的问题、在新项目中启动试点、技术债务无法被消灭,也不要等到太晚
改善
止损
可见
共识
SonarQube
额外的研发成本、不稳定的产品质量、难以维护的产品
内部代码质量的高低影响
七宗罪:复杂性、重复代码、代码规范、注释有效性、测试覆盖度、潜在缺陷、系统架构
代价是后续维护代码的额外工作成本
团队为了实现短期目标选择权宜之计
你遇到过印象深刻的烂代码吗?
解决方法和原则
如何量化技术债务?
为什么要重视技术债务?
技术债务长什么样?
什么是技术债务?
思考题
技术债务

该思维导图由 AI 生成,仅供参考

你好,我是石雪峰,今天我来跟你聊聊技术债务。
如果要问软件开发人员在项目中最不愿意遇到的事情,答案很可能是接手了一个别人开发了一半的系统。而且,系统开发的时间越长,开发人员的抵触情绪也就越大。那么,既然是同一种代码语言,同一种语法规则,至少还是一个能运行的东西,开发人员为什么要发自内心地抵触呢?我猜,很可能是不想看别人写的代码。之所以会这样,看不懂和怕改错是一个非常重要的原因,而这些,其实都是技术债务的结果。

什么是技术债务?

那么,究竟什么是技术债务呢?它是从哪里来的呢?好好地写个代码,咋还欠债了呢?
试想这样一种场景,老板拍下来一个紧急需求,要求你在 3 天内开发完成上线。在评估需求和设计的时候,你发现,要实现这个功能,有两种方案:
方案 1:采用分层架构,引入消息队列。这样做的好处是结构清晰,功能解耦,但是需要 1 周的时间;
方案 2:直接在原有代码的基础上修修补补,硬塞进去一块逻辑和页面,这样做需要 2 天时间,还有 1 天时间来测试。
那么,你会选择哪个方案呢?
我想,在大多数情况下,你可能都会选择方案 2,因为业务的需求优先级始终是最高的。尤其是当下,市场竞争恨不得以秒来计算,先发优势非常明显。
而技术债务,就是指团队在开发过程中,为了实现短期目标选择了一种权宜之计,而非更好的解决方案,所要付出的代价。这个代价就是团队后续维护这套代码的额外工作成本,并且只要是债务就会有利息,债务偿还得越晚,代价也就越高。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

技术债务是软件开发中常见问题,团队为了实现短期目标选择了权宜之计,而非更好的解决方案,所要付出的代价包括团队后续维护代码的额外工作成本。技术债务的表现形式包括低质量的代码、不合理的架构、过时的技术等。为了量化技术债务,可以使用开源软件SonarQube,通过将不同类型的规则按照一套标准的算法进行识别和统计,最终汇总成一个时间,从而对代码质量有一种直观的认识。解决技术债务的方法包括共识、可见、止损和改善,遵循原则让技术债务呈良性下降趋势、优先解决高频修改的问题、在新项目中启动试点以及不等到太晚。最近智能研发的声音不绝于耳,其中关于使用人工智能和大数据技术提升代码质量的方法是目前的一个热门研究领域。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DevOps 实战笔记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • 桃子-夏勇杰
    老师可以分享一下,什么样的技术债还起来比较容易,收益又比较大的?或者分享一个你印象特别的技术债。

    作者回复: 你好,我理解你的问题是哪些技术债修复的投入产出比最高,或者最应该优先处理对吧?这个因项目而已,我给你的建议是参考大厂比如阿里巴巴的编码规范,选择其中优先级较高的问题进行修复。另外在我们实际工作中,有以下这些问题的优先级较高,你也可以参考以下: 线程池不允许使用Executors去创建,而是通过ThreadPoolExecutor的方式 多线程并行处理定时任务时,使用ScheduledExecutorService。 在if/else/for/while/do语句中必须使用大括号,即使只有一行代码,避免使用下面的形式:if (condition) statements; 所有的包装类对象之间值的比较,全部使用equals方法比较。 在使用正则表达式时,利用好其预编译功能,可以有效加快正则匹配速度。 不要在foreach循环里进行元素的remove/add操作 避免通过一个类的对象引用访问此类的静态变量或静态方法

    2019-11-14
    9
  • 陈斯佳
    这一周为了解决一个脚本的问题,硬是花了三四天的时间来理解同事写的这个代码,最后修改其实只要改一行代码就够了……我大好的青春啊!

    作者回复: 看来这个代码的技术债已经已经达到几十小时的规模了,好人做到底多加点注释吧😂

    2019-11-15
    6
  • 陈 争
    之前有一个项目由于时间紧张,没有抽取公共方法,每个人都按自己的逻辑写。比如一个下拉列表查询功能,三个人就会写出三种实现方式,这个不是代码重复的问题,而是完全不重复,无法复用!!! 今天学习了SonarQube,希望在以后的工作中能够把这个工具用起来,做到技术债直观可视,这样可以更方便的跟领导解释技术债的重要性。

    作者回复: 是的,一定要让抽象的事物具象化话,整好我今天遇到一个公司,他们甚至将Sonarqube里面的规则定义了一套自己的算法,并结合多种代码质量类型,比如安全等,最终给出了一个可量化的得分,我个人觉得这个方法很不错,没有比较就没有伤害哈。

    2019-11-14
    4
  • sugar
    感觉遇到的好多烂代码(小声哔哔),开发人员技术能力良莠不齐,多数都没有一个完整成熟的手册规范,一顿操作,先上线再说,哎

    作者回复: 这就是典型的“先上再说”吧,这就看出来代码检查工具的必要性了,降低人与人之间的摩擦(哔哔),有一套客观的标准,谁也不能说啥。

    2019-11-15
  • leslie
    其实提及技术债就不得不去提及领导的魄力和远见以及管理能力。 领导有魄力:发现一堆技术债会定期清理,后续人员发现时上报的时候会在维持现有的情况下控制新内容的增速,为此换取陆续解决相关技术债的问题。没有大局观和魄力的:先解决当下,亡羊补牢,能补多少算多少,问题积累数目偏多,老项目就这样通过硬件优化算了,一切的防御改进新项目再说。 两种领导都碰过:一种-通过一段时间的治理后不会因为人员的流动而对现有系统产生如何影响;继任者是个高手性能提升不少,能力一般的勉强维持现状。 这是我对于企业技术债亲身的感悟吧😄

    作者回复: 👍希望你能成为“前一种领导”

    2019-11-14
  • Robert小七
    最近又回看了这篇文章,然后我自己也读了一些技术债务的文章或书籍,有一个点想请教下,技术债务和坏味道的关系是怎样的?
    2023-02-03归属地:广东
  • 张浩
    您好,老师,我目前主要写Ruby,比较好奇公司之前的Ruby系统,是不是当时就被重写了呢?
    2022-04-27
  • BertGeek
    项目前期就应该共识规范,统一约定
    2021-05-25
  • 苏进宇
    针对测试环境和生产环境上线时因环境差异造成的错误, 是否可以通过Docker做出环境差异的屏蔽呢?
    2020-03-26
    1
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部