北京网站制作建设公司哪家好,华夏人寿保险公司官网,精准数据库营销,一个网站的首页包括什么上一讲主要介绍了如何有效管理第三方组件的实际案例#xff0c;目的是让你意识到依赖组件的质量也会影响到软件的质量。前面几个课时谈论的主要内容都是跟软件质量相关#xff0c;通过各种方式方法提高软件交付的质量。这时就会遇到一个问题#xff0c;软件质量固然重要目的是让你意识到依赖组件的质量也会影响到软件的质量。前面几个课时谈论的主要内容都是跟软件质量相关通过各种方式方法提高软件交付的质量。这时就会遇到一个问题软件质量固然重要但工作中我们不可能把软件质量做到完美无缺才上线。软件质量不是免费的更好的质量需要付出更多的成本和时间。那么如何平衡软件的开发速度和软件质量的关系这就是今天要介绍的内容——技术债务。在软件开发的过程中技术债务是不可避免的有技术债务也是正常的。那么如何合理、有效的管理技术债务让软件实现健康地发展呢
什么是技术债务
相信很多软件开发人员都阅读或修改过他人写的代码特别是企业里遗留下来的老代码。如果要修改其中的一个 Bug或者在这些系统之上增加新的功能那将非常痛苦。我听到很多次“改他人的代码还不如我自己写一个。”有时候并不是说大家喜欢重复造轮子而是因为目前这个“轮子”年久失修已经不具备重复使用的可能性。
目前大多数企业由于交付期限的压力都存在这样的问题 文档没有写或者根本与当前版本不同步 架构设计也只是满足当时的需求 代码中留下了很多待优化的代码片段 遗留代码缺乏文档和单元测试无人能改无人敢改。
上面提到的这些问题你应该都能理解这些问题大多是技术债务没有有效处理导致的结果。那么什么是技术债务技术债务的概念是由敏捷先驱 Ward Cunningham沃德·柯宁汉在 1992 年提出的是指那些现在选择不做但如果一直不做就会影响未来软件发展的事情。 下面两个例子可以帮助我们理解。 过时的架构设计支撑 1 万人的架构和支撑 1 千万人的架构肯定是不一样的。在最初用户量不大时采用单体架构满足业务需求是没问题的但随着用户量的增长系统架构不做升级就会影响到业务的发展。 需要重构的代码在单体架构时为了加快数据的加载速度会在内存中将预先加载的数据缓存起来。但当采用分布式系统架构后这段代码逻辑就要进行相应的重构采用像 Redis 这种分布式缓存方案否则就会出现数据不一致的情况。
要注意的是未实现的功能需求不属于技术债务。
因此技术债务是在短期内不会产生影响但从长期来看经常背负技术债务的团队会面临潜在的严重问题甚至会危及软件的可持续性。每个技术债务无论多么小偿还的成本都会随着时间的推移而不断增加还会导致额外的技术债务。
技术债务是如何产生的
生命周期
在介绍技术债务产生的原因之前我们先了解一下技术债务的生命周期掌握技术债务从产生到消亡的整个过程。如下图所示。技术债务经历了四个阶段
1.产生阶段 由于各种原因产生了技术债务此时并未意识到技术债务的存在。
2.意识阶段 开发人员意识到技术债务的存在但并未影响到软件的正常发展。在此之前一直享受技术债务带来的红利。
3.临界点阶段 技术债务已经阻碍软件的正常发展了出现负债的情况。
4.补救阶段 采取措施偿还技术债务恢复到正常开发流程。 产生的原因
从上图可以看出技术债务的产生是源头。要想有效管理技术债务首先就要了解技术债务产生的原因。下面介绍一下在许多团队中技术债务产生的常见原因有利于团队能够清楚地认识技术债务并选择正确的规避方法。这些原因主要与业务、上下文改变、开发流程和团队有关如下图所示。 第一个原因与业务有关。
在企业里业务目标、需求、具备的资源以及能够承担的风险都会影响软件产品。业务问题导致技术问题进而产生技术债务。 时间和成本压力
开发团队通常因为项目交付的时间、项目预算问题而优先处理用户需要的功能。业务人员和客户也只关心如何更快的向用户交付新功能抢占市场先机。因此开发团队没有太多时间设计具有低耦合、高内聚、可扩展的服务层而需要继续在现有的系统中添加这些功能。虽然短期内能暂时满足项目需求但此时技术债务已经产生。 业务目标不匹配
开发团体的设计方案和技术选型不是为了实现业务目标而是其他方面的原因。比如企业需要快速开发一个 App。但技术人员考虑到性能因素采用了原生的 Android 和 iOS 语言开发。由于对语言的掌握有限导致系统设计差用户体验不好最终导致大量返工。 需求不足
当需求不明确就会产生技术债务特别是对软件的非功能性需求没有明确的要求如安全性、性能、可扩展性等情况下。
第二个原因与上下文改变有关
技术债务是一个与时间有关的概念。即便是在当初做决策时未产生任何技术债务的设计随着时间的推移也会过时需要重新设计。这种重新设计是由业务、技术的变化或者自然进化造成的技术债务的结果。 业务上下文变化
系统的所有决策在当初都是合理的可突如其来的外部事件改变了现有的业务目标。比如企业被收购收购后系统需要进行融合等。 技术变化
软件、硬件和中间件技术的更新迭代导致现有系统债务重重。比如十年前使用 JDK5 开发的应用系统在今天的技术形态下只能推翻重来了。 自然进化
系统在演化的过程中会发生变化如修复问题、增加新功能。这种变化本身也会削弱一个系统这是自然进化的结果。就跟人类身体的零部件随时年龄慢慢老化一样如果做过手术更会元气大伤。
第三个原因与开发流程有关
我们通常将没有按照软件工程实践和开发规范完成的事项也归类为技术债务。这类技术债务要分析哪些是没有遵循流程规范哪些是流程规范本身不合理导致的。再根据分析结果进行相应的处理。 无效的文档
文档一直都是软件开发过程中的痛。开发人员对编写文档的抵触一直都是存在的。事实上关键性文档的缺失或过时增加了系统产生技术债务的风险比如架构设计文档、测试用例文档等。最初的设计人员在交付压力下并未有效纪录架构设计的细节、约束和遗留的问题后续的开发人员会犹豫是否要更改他们不确定的代码。 测试自动化不足
随着系统功能不断增加开发人员会着重关注当前开发的新功能是否可用而对已有功能的关注就相应减少了。这时就需要有一套自动化测试工具能够对已有的功能进行测试。这样就可以校验当前的变更是否对已有功能产生影响。 流程不匹配
为了保障研发过程顺利开展所有的软件研发团队都有自己的研发流程。团队成员如果偏离该流程就有可能导致技术债务比如代码评审分支策略导致版本分支混乱。
第四个原因与团队相关。
影响系统发展的一个关键的、经常被忽略的因素是人。需求是人提出的架构是人设计的代码是人编写的系统是人使用的。有很多现实的例子表明团队成员的业务和技术水平对于技术债务的产生至关重要。 经验不足
一般情况下团队中经验较少的队员在编码时更容易产生技术债务。比如缺乏模块化设计、代码复杂度的理解。由于企业内部对员工级别的限制和团队梯队的合理性每个团队中都会有一些初级开发人员因此对初级开发人员的工作结果审核和技能培训是至关重要的。 分布式团队
沟通问题可能会导致对设计决策理解不一致。分布式团队经常会面临着沟通协调的问题。比如广州的团队进行架构设计北京的团队负责代码实现在进行任务沟通时将会是一个很大的挑战。 非专属团队
团队成员横跨多个项目特别是经验丰富的开发人员。多任务并行不仅需要在多个任务间进行切换而且往往团队和个人会将注意力集中在最紧迫的项目上而忽略对其他项目的关注。不能高效、专注地完成任务不可避免的会产生技术债务。
管理技术债务的原则和实践
介绍完技术债务产生的原因下面就要介绍如何有效地管理技术债务。**管理技术债务不是一项一次性活动它是软件开发过程中的一部分。**下面按照避免产生、提前发现和尽快修复的顺序和原则介绍如何有效管理技术债务。
避免产生技术债务
团队成员的综合能力和丰富经验可以识别技术债务以及避免产生技术债务。因此从团队成员来说避免产生技术债务的方法是 让具有丰富经验和能力的人参加到项目中 让具有丰富经验和能力的人把控项目的进度和质量 建立系统化的业务知识和技能的培训提升团队的整体实力。
提前发现技术债务
大多数情况下技术债务都是无意产生的。如果要想尽早发现这些技术债务并不是一件容易的事。目前有大量的免费、开源的工具可以帮助识别代码中的技术债务。 单元测试框架
单元测试是开发人员自己编写测试以验证代码中单个代码单元的正确性。如果单元测试失败团队成员能够立即发现并修复导致失败的代码。单元测试还可以检验当前变更是否对已有功能有影响。目前每一种编程语言都有对应的单元测试框架 xUnit。比如 Java 语言的 JUnitPython 语言的 PyUnit 和 C 语言的 CppUnit 等等。 静态代码分析
静态代码分析工具可以识别代码的编码规范、漏洞和缺陷以及重复代码等问题。这些工具可以方便地与流水线进行集成自动化的执行扫描和生成检查报告。下图是 SonarQube 执行代码检查的结果可以非常清晰的了解当前代码的内部质量和技术债务情况点击上面的数字能够看到产生该问题的具体代码片段对于解决问题非常有帮助。 持续集成
传统软件开发中一般要到每个功能完成后才会进行集成此时会有各种各样的问题如果该问题影响范围较大甚至将设计方案推翻重来那付出的代价将会是巨大的。持续集成是一种不同于传统开发的方法团队每天至少集成一次或者每次提交到代码库时自动执行集成和验证的过程。通过频繁的集成尽早发现集成中遇到的问题降低最终集成时的风险。
尽快偿还技术债务
当我们通过代码扫描工具或者在开发过程中发现技术债务后就要考虑尽快偿还技术债务。根据技术债务的难易、大小、缓急采取不同的偿还策略。 立即偿还技术债务
对于能当时处理的就立即偿还掉。这种方法可能是最有效的方法但也是实施起来难度最大的方法。团队习惯于对当前正在处理的功能进行编码而是把技术债务留到以后去改进即便是“以后”永远也不会到来…无论如何尽快偿还是解决技术债务和使软件更具有可维护性的最有效方法。 标记技术债务
当发现技术债务的代码时如果不能立即处理就先记录一下然后在后面的某个时间点进行处理。之前的做法是添加 TODO 或 FIXME 这样的注释作为临时占位符标记这里是存在技术债务的。但随着时间的推移这些注释不但效果不好也不会阻止有问题的代码提交到代码库。更有效的做法是在发现技术债务的代码中添加运行时异常这样就可以使代码运行时处于中断的状态阻止有问题的代码提交到代码库。
可以看下面的例子在代码中灵活配置门限的阈值。代码片段如下
try {File thresholdConfig new File(c:/threshold.config);FileInputStream fis new FileInputStream(thresholdConfig);Properties infoProperties new Properties();infoProperties.load(fis);String thresholdVal infoProperties.getProperty(threshold);System.out.println(thresholdVal);} catch (IOException e) {e.printStackTrace();}这段代码的问题是以硬编码的方式从本地加载配置文件。开发人员也了解这样写是不对的因为他只是想调试一下代码逻辑的正确性并且不希望分散目前的注意力。那么可以将运行时异常添加到验证成功代码的后面这样既能验证代码逻辑的正确性又不会遗忘此处的技术债务。如下所示
try { File thresholdConfig new File(“c:/threshold.config”); FileInputStream fis new FileInputStream(thresholdConfig); Properties infoProperties new Properties(); infoProperties.load(fis); String thresholdVal infoProperties.getProperty(“threshold”); System.out.println(thresholdVal); throw new RuntimeException(“不要以硬编码的方式加载配置文件”); } catch (IOException e) { e.printStackTrace(); } 运行的结果如下图所示
**对技术债务进行排期**当发现技术债务较大并不能在短时间内解决时就需要将技术债务添加到产品列表Product Backlog中产品经理将技术债务和需求一起排列优先级共享团队的资源和时间并和需求一样进行跟踪和验收保证技术债务确实被偿还。**总结**本课时开篇以如何平衡软件开发进度和软件质量之间的关系引出技术债务。并提出在软件开发过程中技术债务是不可避免的需要有效的管理和控制技术债务的蔓延才能保证软件的健康发展。接下来系统化地介绍了什么是技术债务什么不是技术债务分析了技术债务产生的原因。根据技术债务的生命周期曲线图技术债务产生后在一段时间内会对当前业务有积极作用只是随着时间的推移慢慢会成为阻碍企业发展的绊脚石。因此在管理技术债务部分先是在产生之前能避免则避免不能避免的可以借助工具提前发现对于发现的技术债务尽可能早的偿还掉。有句俗话“勤借勤还再借不难”言简意赅地表明了管理技术债务的策略。针对如何管理技术债务你是否有其他的方法欢迎在评论区分享自己的方法。
