专栏首页IT大咖说三年0故障是如何做到的?

三年0故障是如何做到的?

摘要

近段时间我的团队,其他团队一直在强调代码质量,减少故障。入职快三年半了,距离我上次故障也快三年半了,所以在这方面有些感触和大家分享一下,我从 个人经历 , 代码质量理解,以及针对代码质量这块的 工作习惯三个方面来分析总结一下。

个人经历

对我代码质量影响最大的是在一家外资企业,在这家公司我觉得有以下几个方面做的很不错。

团队编码风格统一

统一到什么程度?不看代码作者,你很难区分代码是谁写的(在目前公司一些团队也能达到这个标准)。

个人观点:这样做有什么好处?团队中每个人阅读代码都很容易,减少很多沟通,维护成本( 代码阅读的次数远远大于变更的次数),并且心情非常愉悦。有人肯定觉得愉悦有点夸张,举个栗子:有一些代码,如果不是由于与工作内容有关联,你是否有种这辈子都不情愿去接触它的感受。但也有一些代码,阅读下来一气呵成,心情舒畅,促使你有种继续阅读下去的冲动(并且你也会有种不想破坏这种统一的想法)。

基础层面越统一,效率越高(不仅仅是指统一编码规范,还有基本的做事的原则).举个栗子:我们团队规定个人周报必须在每周五上班前必须发出来,否则罚款10元。之前团队周报迟发现象比较突出,规则一出,明显改善(开会缺席情况也一样得到明显改善)。罚钱是否不太合理?注释写多少才算合理?与其花大量精力讨论这些不痛不痒的问题,不如及时统一规范(一般制定的规范不会差的),严格执行。后续针对问题即使做调整。关键是统一和严格执行。

代码简洁

能1行解决就不要写2行(不影响可读性的情况下)

多余的代码(比如注释代码or 无实际意义)必须删除

个人观点:大家都懂的, 没啥好说的

codereview

团队的PLA(团队骨干)进行codereview,团队中PLA之间的代码质量意识/以及代码规范非常统一.不会出现一个团队,多个标准的情况

每周五周会会对这周代码review出来的问题进行回顾,得出结论。将例子放在wiki上,以供后续遇到类似问题的一个参照。新同学也可参照此内容学习规范,避免犯同类问题。规范中很多内容就是这么累计起来的。

个人观点:

我在阿里所经历的一个团队中,PLA有3,4位,分别负责各自的一块业务。PLA之间codereview很少,代码质量的意识交流似乎也不多。但团队的普通开发同学在这些PLA之间轮流被codereview,代码质量的评比标准差异较大。这可能会导致2种现象:开发倾向review宽松的同学,因为宽松review发现问题(不仅仅是bug)较少,变动成本不大,不会有改动造成的故障风险,不会影响项目进度(但后续的维护和沟通成本会明显增加);另一种现象,开发向不同的PLA提出疑义,PLA之间统一代码质量标准,在团队内达成共识并形成文档,以作为后续参考。

一个团队的代码质量主要取决于团队几位PLA,建议团队早期先统一PLA的代码质量意识和规范。例如:先由1-2位PLA对整个团队开发做review,这个review工作量初期会很大,并且团队工作效率不高,但后期的review工作量应该会明显减小, 代码质量也会明显提高, 团队的工作效率也会明显提升。

我在外企这家公司刚入职的那一个月是我最痛苦的一个月,被codereview感觉很不适应:和以前编码习惯差异较大,review太严格(变量名,空行,注释有单词语法错误也会纠正),感觉限制编码自由….1个多月后体会到了明显的好处: 编码bug少; 沟通少,代码和注释已经解决了大部分疑问;阅读代码效率高;感觉别人写的代码就像是自己写的一样,非常有亲切感.一个多月后,revew我代码的PLA明显放松了对我review的内容,因为他已经很多次没有review出问题,并且让我在每次review前告知需重点review的内容即可。

执行力和压力

codereview出来的问题一旦得出结论,就会立马执行。如果有疑义,可以继续讨论,一直到得出结论为止。规范中的内容可以改进,但一旦形成规范就必须严格执行。

一旦有不合规范的代码提交上去,就会邮件提醒给团队PLA以及老大,提醒次数多了还是继续犯类似问题,甚至会劝退。

个人观点:

我在阿里所经历的几个部门规范都很不错,但有的执行起来却比较宽松。因为项目进度一紧, 代码质量就容易妥协, 常见的现象"我下个版本会改过来的", "这个应该暂时没有问题", "这个代码是没有按规范来做,但改动风险太大,出故障怎么办". 这时候,如果你在这妥协, 基本以后代码规范就很难维持了。因为一旦ugly的代码上线,这代码很可能就会在项目里扩散开来(和破窗效应类似)。

很多人对代码质量/规范有强烈的意识,但少数人可能感受不那么明显或者还没有体会到这些带来的益处,或者和自己已有习惯差异而产生排斥心里,这时候得用外部压力刺激一下。比如上面提到的每周五review当周的问题--没人会愿意自己的代码经常被拎出来作反面教材。迫使他朝正向发展,做到对事不对人就可以了。新人对压力可能感触更明显,压力会促使你做事更谨慎, 也有可能让你做事畏首畏尾,这时候对新人要多加关注。

代码质量理解

代码的可读性放在第一位,代码尽量做到don't make me think(这里对集团中间件的开发同学提个建议,希望你们继续提高代码的可读性,因为你们的代码被阅读了无数遍了,你们提高一点可读性,将节约很多人的时间,你们的代码很可能被很多同学模仿)

没有bug的代码不一定是高质量的代码, 写代码不能紧紧满足于功能。

你的代码规范不一定要达到开源规范标准(能达到最好),但不要低(松)于团队的代码规范。

写代码要有敬畏之心。想想如果让你开发载人火箭的程序,你敢随意去写么? 网站一样需要重视。

团队的代码质量重要程度高于个人代码质量。如果只满足个人代码质量提高,而不去帮助团队提高代码质量,你很可能会踩上别人留下的坑,你在工作中很可能遇到各种不便(当然你也要避免给其他人留坑)。

良好的代码规范不一定会让你避免bug.但可以帮助你/他人提升找到bug的速度, 以及提升工作效率。

读优秀的源码(书籍),关注一些细节,对代码质量提升非常有帮助。

codereview不仅仅是为了review出bug。这也是知识分享的一个过程,团队更有经验的同学会对你的代码提出建议;review人员可以从中获取业务/技术相关信息;被review人员因为有人会review你的代码,而不得不提升自己的代码质量,以及代码的熟悉程度。

代码规范不会影响开发效率,你的开发效率应该通过其他的方式去提升。 相反,他会节省你很多成本(阅读,沟通)

故障多少和自己的技术能力关系其实不是很大,和自身的工作习惯非常大(我看了很多故障案例,绝大多数不是开发同学没有相应的技术能力)

对自己擅长什么,不擅长什么要有清楚的认识.有的故障产生的原因是对自己某方面能力太过自信.在不擅长的地方去咨询其他有经验的同学,这不会显得自己能力差,反而给他人的印象是你很重视你的工作,工作谨慎。

工作习惯

当你拿到需求时,分析下自己的需求功能点的重要性(不同重要程度的需求,重视程度和花费的精力也不一样)。

设计时多花点时间思考,编码通常是比较快的

单元测试一定要写,这是底线(除非这个成本非常大)

findbugs,pmd这些工具在前几年我用的比较多,但近几年用的已经很少了,原因是发现的问题少,误判的几率还高,现在只是少数情况才会使用。但是新人建议还是多使用一下。

在团队中寻找比你代码质量要求更高的同学来review自己的代码,一起探讨问题,这能帮自己很快的提升。有疑义的地方一定要达成共识,立刻执行,并告知团队,并形成规范。

尽量不要在情绪低落,体力不支的情况下做需要大量思考性的工作(我个人比较喜欢运动,体力不支的情况比较多.哈哈)。

写代码就难免会有bug/故障发生.另外一种避免故障的方案是如何尽快知道异常情况(比如做好监控),在用户投诉之前尽快解决掉,或者提前做好预备方案(通常是比较重要的需求)。

不要因为错小而放置不理,那会成为你的习惯。

周四尽量减少发布,你可能没有足够时间去观察/验证,发布时尤其需要重视。

读源码是我比较喜欢做的一件事情。一方面能够熟悉一些技术原理/业务,开发时更胸有成竹,bug的几率当然也越少,当然你花费的时间可能就会多(你得去衡量).这个做法也是不得已而为之: 一些部门的文档/代码注释都有问题,沟通又可能不便,读源码反而解决问题比较快。

当别人向你提建议时,心胸开阔点, 你会获取他人更多的帮助机会/建议

这篇文章被关注的程度远远超出了我的想像,原本我并不打算在文章里过多去描述一些影响代码质量的现象,但是评论里提到的问题(比如说如何落地)多少都涉及这些。文章里主要是从普通开发的角度去看代码质量,关于如何落地,我知道落地肯定不容易, 肯定会面临很多来自团队内外的压力。

举几个栗子:

你的老板是否能够接受短期工作效率普遍偏低么(如果采用我在文章中提到的codereview方案)?

团队成员是否都和你有类似的代码质量理念, 如果没有, 你得不断去影响他们, 得影响你的老板。 如果做不到, 落地也无从说起。

每次故障频率比较高的时候,高层传达的意思是重视用户体验,提升代码质量。到开发这里,可能是采取更安全的编码, 但不一定是合理的.要不了多长时间,代码一定会变质。

坦白讲, 我没有很完整的, 可量化的, 可复制的方案, 我现在所在的团队也没有达到这个标准,但我在alibaba经历过这样的团队,一个让我终身难忘的团队(还有那家外企)。这样更加让我坚信我上面的这些想法应该是能落地的, 我也正在努力去影响我现在所在的团队,即使达不到我预想的那样, 但我相信一定会有改善。

以上为今天的分享内容,谢谢大家!

本文分享自微信公众号 - IT大咖说(itdakashuo)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-17

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何写出优质干净的代码

    先列举出编写干净代码的一些好处,再提出6个技巧用于编写干净代码,供开发者进行参考学习。

    IT大咖说
  • 将JavaScript代码转换为漂亮的SVG流程图——js2flowchart

    js2flowchart 是一个可视化库,可将任何JavaScript代码转换为漂亮的SVG流程图。你可以轻松地利用它学习其他代码、设计你的代码、重构代码、解释...

    IT大咖说
  • 为你揭秘全球最大软件公司的代码评审机制

    微软代码评审是一种被广泛采用的工程实践。成千上万的工程师认为这是一个伟大的最佳实践。大多数高绩效团队花费大量时间进行代码评审。

    IT大咖说
  • GitHub不为人知的小秘密…让你的工作更高效

    本文经机器之心(微信公众号:almosthuman2014)授权转载,禁止二次转载

    abs_zero
  • GitHub不为人知的小秘密…让你的工作更高效

    近日,GitHub 宣布将无限制地开放私有代码库,这让我们能够在几分钟之内就将那些不想让人别人看到的代码传到云端,还确保我们可以充分利用 GitHub 所提供的...

    昱良
  • GitHub不为人知的小秘密…让你的工作更高效

    近日,GitHub 宣布将无限制地开放私有代码库,这让我们能够在几分钟之内就将那些不想让人别人看到的代码传到云端,还确保我们可以充分利用 GitHub 所提供的...

    机器之心
  • 测试开发工程师工作技巧

    这里有一些工作技巧,从编写代码和工作任务清单到工作自动化,可以使帮助测试工程师成为更好的测试开发工程师。

    FunTester
  • 一个程序员的自我修养

    一天晚上,我和老婆聊天,说部门要我写个“大咖谈软件”的文章,老婆斜了我一眼,淡淡地说:“Linus大神21岁就写出了Linux内核的雏形,缔造了一个自由主义的开...

    Fundebug
  • 我在华为写了13年代码的一些感悟

    本文来自《华为人》,作者:徐宏伟 原标题:写了十几年代码,我为什么还没有被拿去“祭天”?

    Java帮帮
  • 毁掉你代码的35个不良习惯

    近日web开发专家Christian Maioli总结了导致程序猿效率低下,代码像意大利面条一样难以维护的35条恶习(归为代码组织、团队工作、写代码、测试与维护...

    华章科技

扫码关注云+社区

领取腾讯云代金券