DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

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

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

什么是技术债务?

那么,究竟什么是技术债务呢?它是从哪里来的呢?好好地写个代码,咋还欠债了呢?
试想这样一种场景,老板拍下来一个紧急需求,要求你在 3 天内开发完成上线。在评估需求和设计的时候,你发现,要实现这个功能,有两种方案:
方案 1:采用分层架构,引入消息队列。这样做的好处是结构清晰,功能解耦,但是需要 1 周的时间;
方案 2:直接在原有代码的基础上修修补补,硬塞进去一块逻辑和页面,这样做需要 2 天时间,还有 1 天时间来测试。
那么,你会选择哪个方案呢?
我想,在大多数情况下,你可能都会选择方案 2,因为业务的需求优先级始终是最高的。尤其是当下,市场竞争恨不得以秒来计算,先发优势非常明显。
而技术债务,就是指团队在开发过程中,为了实现短期目标选择了一种权宜之计,而非更好的解决方案,所要付出的代价。这个代价就是团队后续维护这套代码的额外工作成本,并且只要是债务就会有利息,债务偿还得越晚,代价也就越高。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(5)

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

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

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

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

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

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

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

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

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

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

    2019-11-14
收起评论
5
返回
顶部