Recently my boss and other teams have been emphasizing code quality and reducing failures (the frequency of failures seems to be a bit high recently). It has been almost three and a half years since I joined the company, and it has been almost three and a half years since my last failure, so I would like to share with you some feelings in this regard. From my personal experience , my understanding of code quality , and my work habits for code quality are three To analyze and summarize.
Personal experience
The biggest influence on my code quality is in a foreign-funded company. In this company, I think the following aspects are very good.
- Unified team coding style
- How unified is it? Without looking at the author of the code, it is difficult for you to distinguish who wrote the code (some teams in the current company can also meet this standard).
personal opinion:
- What's the benefit of doing this? It is easy for everyone in the team to read the code, reducing a lot of communication, maintenance costs ( the number of code readings is far greater than the number of changes ), and the mood is very happy. Some people must think that the pleasure is a bit exaggerated, for example: there is some code, if it is not related to the work content, do you have a feeling that you are reluctant to touch it in your life. But there is also some code that you can read in one go, feel good, and give you the urge to keep reading (and you also have the idea that you don't want to break the unity).
- The more unified the basic level, the higher the efficiency (not only refers to the unified coding standards, but also the basic principles of doing things) . For example: our team stipulates that the personal weekly report must be sent out before going to work every Friday, otherwise a fine of 10 yuan . Previously, the team's weekly report was relatively late, and as soon as the rules came out, it was significantly improved (the situation of absenteeism from meetings was also significantly improved). Are fines unreasonable? How much is a reasonable comment? Instead of spending a lot of energy discussing these innocuous issues, it is better to unify the norms in a timely manner (generally formulated norms are not bad) and strictly implement them. Follow-up even if you make adjustments to the problem. The key is uniformity and strict enforcement.
- code concise
- Don't write 2 lines if you can solve it in 1 line (without affecting readability)
- Redundant code (such as commented code or meaningless) must be removed
Personal opinion: Everyone knows it, nothing to say
- code review
- 团队的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经历过这样的团队, 一个让我终身难忘的团队(还有那家外企)。这样更加让我坚信
我上面的这些想法应该是能落地的, 我也正在努力去影响我现在所在的团队, 即使达不到我预想
的那样, 但我相信一定会有改善.
Alibaba一直被认为是业务驱动型公司, 也许哪天整个集团的代码规范统一并严格执行了, 估计成为技术驱动型的公司就不远了(O(∩_∩)O~~)。