谈谈技术债（六-1）如何处理技术债

　　作者：DevOps阿伦

　　来自：DevOps探路者

　　6、如何处理技术债

　　在分析了技术债的概念、产生原因、特点类型和影响后，我们会发现，技术债广泛存在而且难以清除，纵观整个软件工程发展史，可以说就是在研究如何处理技术债。那么技术债到底该怎么处理呢？是否有办法将技术债彻底消灭呢？如何控制技术债的影响呢？带着这几个问题，我们开始这一章的分享。

　　6.1、解决技术债的工具体系

　　从技术债的成因来看，低质量的代码、有限的研发资源、紧张的工期是主要原因，同时另外一个原因就是，研发过程作为一个黑箱，无法让缺少技术背景的决策者看到交付情况，从而做出会导致技术债的决策。技术圈里为了解决这些问题，研发出了大量工具。然而，技术债的一个结构性问题，那么，也就不存在一款能够包打天下，解决所有技术债的工具，解决技术债需要的一套工具体系，从而解决代码质量、测试效能、研发资源供给、研发过程可视化等一系列问题 。

　　这里，我个人推荐一下DevOps工具体系的理念，通过高度工具化、高度自动化的工具体系，实现提高交付质量和交付效能，快速获得系统、用户、市场的多维反馈，从而提高运营效率，决策准确性。简单说，就是，依托一条持续集成流水线，搭配需求管理工具、代码扫描工具、自动化测试工具、自动化部署工具、数据采集工具、可视化数据分析工具等，来结构化的解决技术债。

　　

　　6.1.1、代码扫描工具

　　市场上有多种代码扫描工具，sonarcube、findbugs、checkstyle、PMD等等，有开源的，也有商业版的，网上介绍文章很多，这里不再赘述，大家可根据自身情况进行选用，所以说如何获取工具不是最大的问题，如何使用代码扫描工具才是最大的问题。

　　

　　代码扫描分为增量扫描和全量扫描，个人的经验，增量扫描要左移至研发本地，实现代码提交的同时就进行扫描，也就是说，代码扫描不通过，不允许代码提交至代码库，垃圾代码不要浪费代码库的存储空间和传输流量，同时，增量代码扫描结果要记录，以分析开发人员的代码能力和效率，提交的次数多但通过的少，我完全可以认定其代码水平一般或不尊重研发规范。全量代码扫描定期批量执行，不要占用研发高峰期的资源，全量代码扫描出来的问题，一要追踪，自动建立改进工单，提醒相关负责人/团队进行解决，二要记录，将每次全量扫描的结果都存档，从而分析技术债的发展确实和解决成效。

　　6.1.2、自动化测试工具

　　自动化测试工具相较代码扫描工具而言，要复杂的多，一方面是因为测试工作复杂，另一方面是依赖工具复杂。

　　在研发交付过程中，从测试类型来讲，有单元测试、SIT测试、UAT测试、非功能测试、安全测试、UI-UE测试、准生产测试、生产验收测试等，从测试层级来说，有函数级、类级、接口级、服务级、功能级测试，不同的测试类型所依赖的自动化测试工具不同。

　　从测试依赖角度讲，高度的自动化测试，依赖于测试数据的自动化生成，测试案例的自动执行、测试环境的自动供给和回收、测试对象的自动部署、测试结果的自动分析、测试晋级的自动管控。

　　这方面，很难说有一套万能的打法，我也只能描绘一下我根据DevOps理念，对自动化测试的一个愿景。当开发人员提交一段代码扫描通过的代码后，自动进入单元测试工具，执行单测，达不到单测质量要求的代码会和测试结果、修改意见被一道退回至开发人员处修改，通过单元测试的代码合入代码库，进行同行评审，评审通过自动触发构建，构建完毕根据测试方案自动供给相应测试所需的测试环境并部署完毕，自动化测试平台根据测试计划自动执行测试案例，并输出自动化测试结果，如结果达到测试晋级标准，则自动生成测试报告，并根据测试方案的约束，判断是否需要手工测试，需要则流转至测试人员处进行手工测试，不达标则带着测试结果、修改意见退回至开发人员处，每一个测试类型执行之前，根据测试案例自动生成初始测试数据，每测试出一个缺陷，自动录制测试执行过程，每次执行完毕，系统就自动回收该测试环境。这就是我理想中的自动化测试工具体系。

　　6.1.3、最高效率的资源调度

　　如果两个研发人员水平相当，所面对的需求相当，实现的技术难度相当，那么决定两人研发效能的是什么呢？答：研发资源供给效率。如果一个研发人员需要跟别人抢资源，排队等资源，另外一个研发人员全程有充足的资源供给，或者说资源等研发人员，那么双方的研发效能，不问可知。

　　在DevOps的理念中，可以在总资源不变的情况下，通过自动化的资源调度，为每一位研发人员提供一套专属自己的从编译、打包、测试环境供给、投产上线的研发资源，从而为其形成局部的资源冗余、饱和覆盖来保障其研发效能。

　　比如说编译资源池化管理，每次提交代码，即自动的根据代码量从资源池内分配编译虚机，编译完立刻回收资源，放回池内。可根据整个组织的资源使用节奏，阶段性扩充和收缩资源池大小，高峰时从别的地方借来资源，低谷时将资源借出，这样就可以实现资源的最大化利用和最大周转速度。

　　同理，所有的资源供给都是服务化、自动化、标准化的。而且，有赖于现在云计算、容器技术的发展，理论上，通过云可以实现资源的无限【相对于单一企业的需求】供给，高度弹性的快速扩缩。

　　

　　6.1.4、打破黑箱的可视化监控

　　制造业流水线上的工件，资源从哪里来，用到哪里去，做出了个什么东西【哪怕是半成品】都是可见的。而研发过程不同于制造业，制品没有部署到相应的环境执行之前，是无法看到制品是什么样的，及时部署的相应环境里，很多后台应用因为其性质，仍然不可见，只能有具备相应知识的人员通过一些指标和操作反馈来识别制品的成效。同时，可悲的现实是，做产品、业务、计划决策的管理人员，大多没有相应的知识和技能，使他们的眼光可以穿透黑箱，来看到研发过程、进度、质量，所以他们心里也没底，难免会做决策的时候拍脑袋，出问题的时候拍大腿。

　　DevOps强调端到端全流程、全维度、全量的监控，并将监控指标可视化，通过对研发交付流程各个阶段设置相应的指标，并将指标有机组合，形成监控视图，可以让对研发一窍不通的人也能准确识别研发进度、质量和问题，从而对其决策形成心理上和数据上的支撑。类似的视图工具有很多，既可以使用如tableau这样的BI软件，自行配置指标，也可以将如grafana等开源监控工具组合使用，甚至自研自建视图页面都可以。