软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6706 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?

宝玉 2019-04-23
你好,我是宝玉,今天我想与你讨论一下关于技术债务的问题。
做开发的同学对以下场景应该不会陌生:
为了赶项目进度,单元测试代码就来不及写了,打算以后再补;
随着需求的变化,原本的架构设计已经不能很好地满足新的需求,但是又不想对架构做改动,于是就绕开架构设计增加了很多代码;
一个旧的系统,没有文档没有注释,技术老旧,难以维护。
这些问题,如果没有及时修正,就会导致代码臃肿、系统效率低下,难以维护,也难以新增功能。
有一个很形象的名词叫“技术债务”,用来形容上面这些架构或代码上的质量问题。
所以今天的课程,我将带你一起来了解一下什么是技术债务,它形成的原因是什么,以及怎么来管理技术债务。

什么是技术债务?

我们在学项目管理金三角时,有一张表示软件质量与时间、成本、范围关系的三角形图,也特别解释了为什么质量要放在三角形中间,因为质量往往是其他三个因素平衡后结果的体现。
范围不减,成本不增加,还想节约时间走捷径,就会影响到质量。这个“质量”,不止是产品质量,还有架构质量和代码质量。这种对质量的透支,就是一种债务。而技术债务,就是软件项目中对架构质量和代码质量的透支。
技术债务确实是个形象生动的比喻,让你意识到它是和成本挂钩的,而且技术债务也有金融债务的一些特点,比如有利息,再比如技术债务也有好的一面。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(17)

  • bearlu
    明白了为什么不要接到一个需求就马上写代码。没有经过设计的代码,后期维护成本极高。

    作者回复: 是这样子的,磨刀不误砍柴工

    2019-04-23
    6
  • clever_P
    对技术债务有深刻的感触,但凡对技术有深刻理解的人都会采取预防的策略。
    对于已经欠下的技术债务,如果软件生命不会很快结束,维持的策略长期来看是不可取的,债务只会越来越多,问题也会越来越多,在业务紧的情况下,不只是透支研发成本,还会透支工程师的健康。对于重构的策略,个人理解是从局部到整体的,在输出结果不变的情况下,改善内部设计,但是对于大的结构设计缺陷,有时局部重构也不太好做,整体结构会有很多限制。对于重写,要对原有系统的业务功能和业务特点有细致的理解,对业务发展有较为清晰的认识,最最重要的是能够清楚识别原有系统的设计问题,有针对性的提出解决方案来处理这些问题,不然重写就真的只是重写一遍了。

    作者回复: 预防是最好的方法,也是要求最高的。

    技术债务的问题确实是没有万能的解决方案,还是要先识别,然后理性客观的做一个方案,再有计划的去实施。

    2019-04-23
    3
  • Joey
    请教宝玉老师:

    1.如何更好地推广SonarLint白盒扫描工具。
    2.如何要求各开发团队更好地,有效地做代码走查,而不流于形式。(我们现在使用Gerrit)
    3.如何要求开发人员有效实施单元测试。

    我们一个研发部门人数1000左右,由于历史原因,大家根本不重视单元测试、代码走查以及白盒扫描,或者说这只是留于形式,走流程。久而久之,开发人员觉得我不关心这些东西,也没有出现很严重的事情啊,反正有测试人员对质量把最后一道关,我为什么要浪费时间呢?

    但是现在随着业务越来越多,系统越来越复杂,要从研发过程上加强质量,面临以上三个很突出的问题,请宝玉老师支支招,多谢老师解答!

    作者回复: 这种开发流程问题肯定还是要自上而下推才能推得动。

    我觉得首先应该先找一两个小项目组试点,摸索出一套适合你们的最佳实践,形成流程规范,比如说基于Github Flow,把CI(持续集成)环境搭建起来(如果没有的话),把你说的SonarLint、自动化测试加入到CI流程中。

    再就是逐步扩大范围,在更多项目组推行最佳实践和流程规范,并且改进流程规范。

    最后就必须要借助行政手段强制推行了。

    因为我对你的情况不是很了解,先简单回复一下,你有后续问题可以继续留言。

    2019-05-16
    2
  • 果然如此
    最近遇到一些Bug 数量越来越多技术债务,而且都是同一类问题,因为数据准确性关系到月月末统计工资,所以临时解决方案是修复已知的错误数据。由于这个模块以前是其他同事做的,我在本周花了几天时间研究,得出结论是原设计没考虑到业务变化后的相关联数据如何跟着同步变化,导致了很多相关统计报表错误。
    这个债务临时解决办法只是头疼医头脚疼医脚,最终还要抽出时间根本解决数据同步变化问题。

    作者回复: 👍技术债务最重要的一步就是识别出来问题在哪,然后再有一个稳妥的方案。

    你这个问题,我建议你先把相应的自动化测试代码补上,然后保证有一定测试覆盖之后,再逐步用新模块替换旧模块,最终完全替换。

    2019-04-26
    2
  • 纯洁的憎恶
    技术债务不全坏,与金融债务一样,需要具体问题具体分析。轻率&有意的债务要避免。谨慎&有意的债务有收益。轻率&无意的债务要警惕。谨慎&无意的债务要改变。识别债务防患于未然。根据成本收益分析,决定重写(一次性还款)、维持(只还利息)还是重构(分期付款)。

    作者回复: 突然感觉我们是金融行业从业者😄

    2019-04-23
    2
  • kirogiyi
    在研发过程中,产生技术债务的时候,稍微有点技术功底的人,或多或少都会有感觉的。比如:有重复代码的时候,会意识到好像已经写过了;函数命名的时候,会意识到好像有个相似的名称已经命名过;函数行数过多的时候,自己心里会感觉不舒服等等。更有甚者,你去整理这些问题还会被同事标上“强迫症”患者的称号,还是放弃吧。技术债务就这样在外部和内部双重压力下自然而然的产生了。

    那么如何产生有利的技术债务呢?我觉得应该从公司制度、研发流程、个人素质培养三方面入手。公司制度实际上是为领导层准备的,领导层以身作则去影响下面的员工,员工就没有冒犯的理由,比如:合理的奖惩制度,要做到公平合理,一视同仁;研发流程主要是让团队成员知道自己什么时候该做什么事情,如何去按照指定的约束去做好自己的事情,除此之外,还应该给予明确的成长上升空间;员工素质的培养则需要从一个人的职业素质,技能优化,团队协作方面着手,让他们拥有积极努力的心态参与到工作中去,这基本上就能解决最基础的技术债务问题(领导决策错误产生的技术债务另当别论)。

    在我遇到过的技术债务中,主要由领导决策、产品业务逻辑、技术最初选型、技术更新换代、团队综合素质中的一种或几种导致。对此,我只能说个人能力达到什么层次就应该去解决什么层次的技术债务,不能去推诿和落井下石,在你手中的技术债务就应该当成自己欠下的技术债务来解决,这样才能持续性的做好自己分内和分外的事情,工作起来才能得心应手。

    作者回复: “在你手中的技术债务就应该当成自己欠下的技术债务来解决,这样才能持续性的做好自己分内和分外的事情,工作起来才能得心应手。”👍👍

    说的真好,偿还技术债务,从自己做起!

    2019-04-23
    2
  • WL
    老师能不能具体讲讲重构有哪些原则和要注意的地方,感觉一直得不到要领

    作者回复: 重构的要领我觉得两点:
    第一:你要先写一部分自动化测试代码,保证重构后这些测试代码能帮助你检测出来问题
    第二:在重构模块的时候,老的代码先保留,写新的代码,然后指向新代码,或者用特定开关控制新旧代码的指向(这样上线后可以自己先测试,有问题也可以及时关闭),然后让自动化测试通过,再部署测试,新代码没问题了,删除旧代码

    2019-04-23
    2
  • 小老鼠
    1、技术债务是不是仅是产品质量低。2、重构:如何作好新老系统接口的一致性。

    作者回复: 1. 技术债务通常是指技术层面的,比如说代码质量底下,缺少良好的架构设计,缺少自动化测试覆盖等等,最终技术债务导致的结果就是产品质量低,难以响应需求的变化等

    2. 重构和接口设计是两个不同概念,重构是对代码或系统结构进行调整优化,接口设计是架构设计的一部分。

    大的系统重构也需要先进行架构的设计,其中包括接口的设计,在设计的时候就要决定新的接口是否兼容老的接口,设计完成后,在重构时,就应该遵循设计时定义的接口设计。

    2019-09-20
    1
  • Mr.Chen
    看了几次项目管理金三角后,发现有意思的是,这个图里,时间和成本的缩减,都会引起三角形面积减少,也就是质量变差,范围缩减也会引起三角形面积减少,但它应该是提升质量吧。😄

    作者回复: 这个三角形,更多的是反应各个因素的影响关系,不完全对应几何上的反应 😛

    2019-07-25
    1
  • hua168
    十年前的系统perl写的,很重要的,没办法维护,经常他会出问题,效率低下。
    如果用Go重写的话,之前的perl开发走完了,
    那如果重写,是按照业务逻辑来重写吗?

    就问那些经常操作人了解有哪些功能,结合他们的讲解,把业务功能列出来?然后用Go来重写对吧?

    作者回复: 是的,就是一个普通的软件项目,有需求说明,然后立项开发。

    2019-04-29
    1
  • hua168
    像我们公司有老系统,十年了,程序员都换完了,用perl写的,基本上都没有几个人懂perl
    无法重写、也无法重构怎搞?

    作者回复: 需要综合评估一下,如果很稳定也不重要,那就别动了,补一点文档。
    如果很重要又不稳定,建议对其立项,用开源产品或者商业产品或者新技术实现同样的需求,然后换掉。

    2019-04-28
    1
  • Charles
    我们的技术债务:单元测试覆盖率几乎为0
    主要两个方面原因,一个是一直创业公司待着,不知道单元测试好的实践到底是怎么样的,PHP的单元测试到底应该怎么做。另外一个就是项目排计划的时候总是不允许排单元测试实践,否则感觉整个项目周期太长
    所以就这么一直恶性循环下去,怕重构怕改需求导致系统不稳定,测试全靠人(测试工程师)

    最近每次一有空下意识就会补几个单元测试,希望能坚持下去,回头也得多找点这方面的书补一补

    作者回复: 单元测试、自动化测试在第27篇会再讲,希望到时候能解答你的一些困惑,当然也建议你看一些书,毕竟一些语言相关的还是得自己去学习研究。

    2019-04-23
    1
  • 刘晓林
    偿还技术债务,最重要的还是要明白自己在哪个地方欠了债,深究问题的根源,然后才去寻找应对措施。比如你是因为流程不规范,没有必要的代码审查,那就应该规范流程,否则重写了之后,依旧是一堆乱代码。是因为测试没有做充足,那就应该把测试补上。是语言或者框架过时了,那么就要考虑更换语言框架了。但无论如何,最好还是分模块、有计划地把重构纳入到迭代中去逐步完成。防止步子迈太大,总是容易出问题

    作者回复: 是的,需要先识别,然后做方案,再做计划。线上项目不能太激进,不然代价很大的。

    2019-04-23
    1
  • 空知
    基本隔个3年左右 全部推倒重建...债太多 还补上了

    作者回复: 这未必是最好的方式,可以尝试预防为主,日常及时小范围重构,应该效果更好

    2019-04-23
    1
  • Linuxer
    我们应该是这种谨慎 / 有意的债务,应该是通过重构来偿还

    作者回复: 👍先识别,然后定方案,最后再行动

    2019-04-23
    1
  • 纯洁的憎恶
    投资的比喻很传神👍
    2019-04-23
    1
  • williamqian
    写代码只是最后一步,前期的思考设计很重要。

    作者回复: 👍谢谢总结分享

    2019-05-27
收起评论
17
返回
顶部