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

发布于:2020 年 5 月 29 日 15:31

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

该文章来自于云栖社区 ,作者不闻,就职于阿里巴巴。此文章发布于 2015 年,小编觉得仍然有其现实意义,所谓 “年年岁岁错相似,岁岁年年人不同”,又道太阳底下无新事。对于作者的不少观点,小编深感认同,比如严格遵守代码 review 规约、严格执行 review 制度,不因为工期而妥协、对于 pmd 这些检查工具,小编还是提倡采用,代码 review 的精力放在逻辑和设计上去,对于可以规则化定义的内容,交给工具。至于工具规则过多或者少,进行定制即可。

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

个人经历

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

团队编码风格统一

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

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

基础层面越统一,效率越高 (不仅仅是指统一编码规范,还有基本的做事的原则). 举个栗子: 我们团队规定个人周报必须在每周五上班前必须发出来,否则罚款 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 经历过这样的团队, 一个让我终身难忘的团队 (还有那家外企)。这样更加让我坚信我上面的这些想法应该是能落地的, 我也正在努力去影响我现在所在的团队, 即使达不到我预想的那样, 但我相信一定会有改善.

阅读数:3 发布于:2020 年 5 月 29 日 15:31

评论

发布
暂无评论