浅谈保证软件工程质量的一些心得体会

前言:

质量这个词究竟有多重要,没有切身体会真的很难说的出来,从毕业到进入华为工作马上就要满1.5年了,现在这个词理解更加深刻了些。这么说吧,质量在华为的研发领域几乎可以说是重过其他一切,开发进度来不及可以延期,方案搞不定可以变更,裁决不做,唯有质量不可妥协。为什么质量这么重要?简单说几点:

(1)              质量是一个企业的代名词,质量都做不好,客户肯定会有不好的体验,并质疑你的能力。

(2)              对于大型的软件工程活动,如果前期版本到处挖坑,那么后期版本将会越做越痛苦,而且定位和解决问题所消耗的时间和金钱将会更多(这点感触颇深)。

(3)              从软件开发的角度来看,越早引入问题,带来的人力消耗和经济损失就越大,具体多大呢?据说有专门的团队研究过是成指数形式增长的(具体数字我不记得了,但是从切身体会来讲我是深信不疑的),举个例子,如果开发阶段,引入一个和其他地方关联性比较强问题,一直没被发现,然后几个版本之后发现,那么可能很多代码都是基于这个错误的逻辑继续开发的,到时候修改起来,很可能会牵一发而动全身。再比如,需求分析没做好,或软件架构设计不合理,开发完之后才发现,那代价就会更大。

(4)              。。。。。。

正文:

既然质量这么重要,那么管理团队和开发代码,才能保证软件工程的质量呢?下面结合我工作中的一点体会,还有最近读的一本书《代码大全2》的一些感悟罗列我认为比较重要的几点,也欢迎大家补充。

1、  质量意识的培养

之所以把这点放在第一位,真的是人为这点是最重要也是最难做到的,可能你自己有质量意识,但是要让整个团队甚至整个公司都有质量意识还是非常难的,首先要建立大家共有的质量价值观,从企业文化中将质量意识植入人心,不然以中国人的“聪明”总是上有政策,下有对策。所以我认为意识和价值观的建立是一切的基础,有了共同的价值才能更好的执行规则。

2、  有清晰的质量目标和向导

   有了意识,还需要有目标,要用清晰可见的目标来推动大家为质量负责,量化好什么样的代码是质量好的,比如每千行代码少于多少个bug,bug要根据影响划分出不同级别。质量一定要作为一个评价研发人员工作或绩效的重要因素。

3、 重要的地方请重要的人把关

  假设你现在有一个10个普通级别的人的开发团队,我建议换成一个1个大牛级别+5个普通级别的团队,哪怕花5倍的工资请一个大牛,然后要他做核心的框架、系统设计、重点问题公关和保证其他人开发的质量把控。有些地方如果做的不好修改代价可能会比较小,比如某个程序写的不好,或某个独立的功能有问题,但是有的地方代价会很大,比如架构设计不合理,或系统设计有问题。而且如前言所说,软件开发越是靠前的步骤出问题,带来的代价就会越大,而且会大的明显。

4、  编程规范

这点刚工作的时候体会不深,随着工作的深入,体会越来越明显,大型软件的编写不是一个人的事,定位、修改问题,也不是只改自己的部分,我们甚至定位的大部分问题都是老版本和别人的问题,这个时候,如果大家没有一个统一格式的编程规范,就会很难读懂别人的逻辑,只能到处骂娘了。而且好的编程规范确实能让我们的程序可读性更好,更少的犯错误。

5、  管理好复杂度

人类在同时面临更多更复杂的东西的时候,往往就会显得更加吃力,也更容易犯错误。一开始部门老大给我们设定函数圈复杂度标准的时候,我也是有些不解,特别是修改别人圈复杂度很高的函数,有时候甚至是一种负担,但后来越发体会到,合理的复杂度确实能要我们少犯些错误,而且定位问题和走读代码也会更加清晰。代码大全的作者甚至认为软件的首要技术使命就是管理复杂度。

6、  测试甚至调试之前就要保证代码质量

不要过分的依赖测试,测试当然很重要,但这是保证我们质量的最后一道关口,代码大全的作者也认为测试不是改进质量的方法,要从代码源头进行把控,好的代码应该不需要调试或很少需要调试的。当然不需要代码的代码几乎是不存在的,但是意识上一定是要这样的。就好比找到初中那会儿做数学卷子的状态,交卷之前就要确保自己能得满分,这样成绩出来即使不是满分,成绩也应该不会差。

确保调试前就有高质量代码的一些手段:

(1)     使用静态检查工具,清除一切警告。

(2)     代码检视,这点是一定要做的。首先自检是必须要有的,然后互检也可以开展,对应风险需求,除此之外还可以会议集体检视。

7、  严格控制修改引入

对于大型软件项目来说,修改问题引入新问题是一件非常可怕的事,这样除了让你的团队有改不完的问题之外,还很容易把新引入的问题遗留到更后端,造成更大损失,所以修改问题一定要谨慎评估影响,有其他人把控检视,测试也要发散测试,总之修改引入是一件非常严重的事。

8、  改正bug定位根因,且举一反三

首先不能在没定位出根因的情况下去规避,因为这样不仅可能解决不了问题,还可能会带来更大的隐患。不能只改bug本身,要培养发起排查改进的习惯。

9、  测试都没有发现的问题一定要回溯

测试是质量的最后一道保障,如果测试都把问题遗漏了,一定要回溯,寻找遗漏原因,排查改进。

10、 构建自动化测试环境

这点不比多说,如果每天都有自动化在跑测试用例,起码一些基本的问题不会往后遗留,前面已经多次提到,越早发现问题,解决问题的代价就会越小。

11、 改进改进

再好的规则和团队都有不足,所以更好的办法就是与时俱进,实时改进,发现不足就及时总结改进,可以跌倒一次,但绝不在同一个地方跌倒两次。

12、更多方法欢迎大家补充

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏海天一树

云技术简介

一、概念 ? “云计算”概念由Google提出,一如其名,这是一个美丽的网络应用模式。云计算是是分布式处理(Distributed Computing)、并...

72510
来自专栏大数据文摘

GitHub迎来史上最大产品变革:发布可直接运行代码的GitHub Actions

10月16日,全球最大开发者社区GitHub Universe开发者大会在旧金山召开,会议持续两天,在刚刚顺利闭幕。本次大会主题为“认可开发者集体的成果以及增强...

1444
来自专栏鹅厂网事

互联网时代需要怎样的网管

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

2115
来自专栏企鹅号快讯

跟小编来体验一下微信小程序

今天微信小程序刷爆了整个朋友圈。微信小程序在2017年1月9日凌晨正式上线,用户可以通过二维码、搜索使用开发者提供的小程序。 笔者晚上也迫不及待的体验了一把这个...

2545
来自专栏后端技术探索

漫谈大型网站架构

作者介绍:陈康贤(花名龙隆),淘宝技术部技术专家,著有《大型分布式网站架构设计与实践》一书,在分布式系统架构设计、高并发系统设计、系统稳定性保障等领域积累了较为...

911
来自专栏知晓程序

深度体验了 50 个小程序之后,我的一些冷思考

1002
来自专栏云计算D1net

云计算:拼的是运维

云计算的IaaS、PaaS、SaaS最后那个S都是Service。就是说,无论你云计算长成什么样,都得要向用户提供“服务”而不仅仅是软硬件和各种资源。 【云计算...

7369
来自专栏DevOps时代的专栏

业务安全与 DevSecOps 的最佳实践

2982
来自专栏即时通讯技术

阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

本文原题“阿里数据库十年变迁,那些你不知道的二三事”,来自阿里巴巴官方技术公号的分享。

3915
来自专栏FreeBuf

GitHub 2017年支付漏洞赏金100多万元,超出去年一倍多

程序员最爱的 GitHub 在 2014 年开展了一项为期 4 年的漏洞奖励计划,到 2017 年已经是第四年。这四年间,累计发放的漏洞赏金约 35 万美元(按...

3367

扫码关注云+社区

领取腾讯云代金券