三年0故障总结,提升代码质量的秘诀

个人经历

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

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

个人观点:

  1. 这样做有什么好处?团队中每个人阅读代码都很容易,减少很多沟通,维护成本( 代码阅读的次数远远大于变更的次数),并且心情非常愉悦。有人肯定觉得愉悦有点夸张,举个栗子: 有一些代码,如果不是由于与工作内容有关联,你是否有种这辈子都不情愿去接触它的感受。但也有一些代码,阅读下来一气呵成,心情舒畅,促使你有种继续阅读下去的冲动(并且你也会有种不想破坏这种统一的想法).
  2. 基础层面越统一,效率越高(不仅仅是指统一编码规范,还有基本的做事的原则). 举个栗子: 我们团队规定个人周报必须在每周五上班前必须发出来,否则罚款10元。之前团队周报迟发现象比较突出,规则一出,明显改善(开会缺席情况也一样得到明显改善)。罚钱是否不太合理?注释写多少才算合理?与其花大量精力讨论这些不痛不痒的问题,不如及时统一规范(一般制定的规范不会差的),严格执行。后续针对问题即使做调整。关键是统一和严格执行。
  • 代码简洁
    • 能1行解决就不要写2行(不影响可读性的情况下)
    • 多余的代码(比如注释代码 or 无实际意义)必须删除

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

  • codereview
    • 团队的PLA(团队骨干)进行codereview, 团队中PLA之间的代码质量意识/以及代码规范非常统一.不会出现一个团队,多个标准的情况
    • 每周五周会会对这周代码review出来的问题进行回顾,得出结论。将例子放在wiki上,以供后续遇到类似问题的一个参照。新同学也可参照此内容学习规范,避免犯同类问题。规范中很多内容就是这么累计起来的。

个人观点:

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

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

  3. 阅读全文请点击:http://click.aliyun.com/m/8717/

转载于:https://my.oschina.net/u/3161071/blog/812862

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值