• 0
  • 0
分享
  • 的提高代码质量的方法有哪些?有什么经验和技巧?——软件测试圈
  • 恬恬圈 2024-04-03 16:50:00 字数 1869 阅读 701 收藏 0

  想要做好代码质量,我们不得不提什么是代码质量?本次回答中讨论的代码质量一般是指代码的风格、重复率和复杂度等,代码是技术团队的价值产物,是宝贵的财富,同样代码质量的好坏可以直接体现出团队的重视程度和技术管理水平。

  代码质量的下降是内在原因,通常会恶性循环,主要表现出以下两个特性:

  感染性:坏代码总能在部门渲染着只要业务交付达成,代码质量不重要的负面气氛,严重减低了研发人员的技术热情,破坏工作氛围,导致更多的坏代码出现。

  心理暗示性:在坏代码基础上继续生产坏代码的"罪过"减轻。

  为什么会产生这样的结果,这里我与你举个生活中的栗子,我在上个周日收拾房间,发现一个房间衣柜中的衣服很乱,花了很长时间才叠放好,过两天晚上下班回家,我发现客厅沙发上也很乱,衣服、电脑、背包、零食几乎日常的小物件都会有,两件事情合在一起想,这确实是一个很有趣的思考,为什么会是这样的?在一个相对封闭的空间中,任其无意识地随着时间的发展,房间和沙发也一定很乱,注意,这里我说的是无意识,也就是我并没有刻意放,或者去刻意整理。带着这个思考的结果,我又观察了大家的工位、园区内景观,一段时间内一定会出现乱象,不过通过一顿治理之后很快恢复到有秩序,好,大家可以猜到这是什么定律,就是熵增定律,不了解的可以自行网络科普,那么在质量域中依然存在这样的定律,不然熵增定律也不会被古今中外的物理学家所推崇备至,它的定义是:在一个孤立系统里,如果没有外力做功,其总混乱度(即熵)会不断增大。

  代码质量在软件项目是一种有序的状态,自然总是向着无序发展的,要想保持这种有序,需要主动投入资源,就像整理房间,花草修剪一样。

  回到我们的多数开发工作中,我们面临的现状是这样的:

  1、业务交付压力大,需求优先上线,业务逻辑实现优先级最高,没时间没精力关注代码质量,甚至终极目标就是需求上线,导致坏代码产生,开发效率逐步下降,随着后续版本的迭代,业务交付压力越来越大。

  2、出现了1的情况后,我们意识到压力越来越大,为了应付这种交付压力,常见的手段就是增加人力,但是一味的增加人数,沟通成本及风格的一致性无法得到保障,这将进一步产生更多的坏代码。

  针对以上2个现状,我们该怎么着手解决。

  我的建议方案是多渠道,系统性解决问题,首先控制人力的大量投入,主动发起对代码质量进行管控,其次持续提升技术升级。但是,从减轻业务交付压力的结果来看,人们往往倾向于增加人力来快速解决问题,技术升级需要靠长期的投入才能有所收获,所以,我们需要在质量方面增加强有力的管控。

  如果做好代码质量管控?

  代码质量管控首先应解决两个问题,库存坏代码和增量坏代码。

  想解决这两个问题,我们要对现有的系统、人员、工具、流程整合形成一套体系化的方案。

2-1.png

  对代码质量管控,通过在部门内工程实践,我认为需要经历以下这四个过程,部门内建立代码规范制度(EOS)、检查代码问题的自动化工具(bamboo平台)、代码质量检查与代码流动过程绑定(质量门禁)、部门视角下,集中管理代码规范和质量状况的透明(代码质量评测系统)。

  过程一:代码质量的基础是规范,包括代码风格的规范、长期一线代码实践规范、与业务需求相关的特殊规范,例如风控文案、异常托底文案等。

  过程二:实现自动化的检查能力是在规范基础之上,通过自动化工具进行检查,包括对代码重复率、圈复杂度、单测case通过率、静态规则扫描等。

  过程三:实现质量检查与代码流动过程绑定,在编辑-构建-提交-发布各个时段部署检查能力保障上线代码必须经过机器和人工的多环节检查。

  过程四:团队规模逐步扩大,各业务线项目快速发展,实现规范管理统一、项目要求一致、各项目质量状况透明、对比,建立统一的评测体系。

  为了让你有一个很直观的认识,我在下面画了一个张图,希望可以帮助快速理解。

2-2.png

  总结:

  在日常开发工作中,大家都会想到通过增加人手来缓解项目交付的压力,这是可以理解,但是从整体角度看,人员的增加会产生越来越多的坏代码,使整体的效率下降,这又进而加剧了后续项目交付的压力,在这种压力下,又通过增加人手缓解......让代码质量变的越来越差,这也是房间为什么会越来越乱,是熵增定律在软件质量域的生动体现。

  为了抑制这种恶性循环,我们意识到了通过有效的手段和资源投入进行各项工程实践,逐步完善代码质量的管控体系,积累很多方法和工具。


作者:京东云    

来源:http://www.51testing.com/html/80/n-7797580.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 突变测试突变测试是一种白盒测试,其中一个程序的源代码被更改并验证现有的测试用例是否可以识别系统中的这些缺陷。程序源代码的变化很小,不会影响整个应用程序,只有有影响的特定区域和相关的测试用例才能识别出系统中的那些错误。负面测试测试人员的心态是“打破系统/应用程序”,它是通过负面测试来实现的。使用不正确的数据、无效数据或输入执行否定测试技术。它验证系统是否抛出无效输入错误并按预期运行。加载任何页面或系统不应花费太多时间,并且应在峰值负载期间持续。不同的性能和负载工具用于执行此测试。恢复测试这是一种测试,用于验证应用程序或系统从崩溃或灾难中恢复的程度。恢复测试确定系统在灾难后是否可以继续运行。假设应...
            0 0 1432
            分享
          • 命令执行漏洞一般查看home目录,挖掘用户信息:ls -alh /home查看具体用户的目录:ls -alh /home/用户名/查看系统信息:uname -a利用ssh命令执行root权限命令使用ssh 用户名@localhost通过ssh登录服务器是不需要身份验证的;比如查看bill用户sudo命令的权限:ssh bill@localhost sudo -lubuntu自带防火墙,所以关闭防火墙方便后面的操作。ssh bill@localhost sudo ufw disable反弹shell攻击机启动监听netcatnc -nlvp&nb...
            14 14 3348
            分享
          • 快速迭代测试中经常遇到这种场景:假设今天17号周三,接到测试任务26号(周五)必须发布现场,22号(周一)给版本,能测试完成么?下周一:研发延期,周三才能给出,能测试完成么,周五必须发布现场........思路:测试这些功能+环境的工作量测试预估多少,现在可以安排几个人,根据人员、时间确定测试那些测试以及测试颗粒度。版本发布现象需要哪些测试:1、每个(dev--->test--->stage--->prod)环境冒烟测试—各2H;2、Bug验证,根据Bug数量、复现难易程度来确定;3、每个环境测试,详细测试(安装部署+功能详细测试+异常+专项等)预计两周;4、上版本服务器(必...
            1 2 3668
            分享
          •   据彭博社报道,美国两党参议院都打消了推进TikTok“不卖就禁”法案的念头,从而降低了相关提案成为法律的可能性。  来自康涅狄格州的民主党参议员Richard Blumenthal声称,他并不是反对消除TikTok的影响力,但告诫说提案给出的六个月出售时间太过仓促。  皮尤研究中心去年12月的一项民调显示,38%的美国人支持禁止TikTok,比例低于3月的50%。  在特朗普站出来反对这项禁令后,他的共和党同僚的态度就更加微妙了。  此前,美国前财政部长姆努钦在接受CNBC采访时说:“这是一家伟大的公司,应该由一家美国企业所有。作者:佚名原文链接:国际财闻汇(finance.ifeng.c...
            0 0 747
            分享
          • 导出json文件方便使用jenkins集成环境管理,导出python的话方便在linux系统下运行脚本。1、postman导出json文件:目前postman支持V1(逐渐弃用),V2,V2.1(推荐使用),只有客户端支持导出功能,chrome插件不支持选择要导出的版本号即可2、postman导出Python脚本生成后复制代码新建.py文件即可作者:笑笑就好90原文链接:https://www.cnblogs.com/xulinmei/p/10719231.html
            0 0 1052
            分享
      • 51testing软件测试圈微信