个人经历
　　对我代码质量影响大的是在一家外资企业，在这家公司我觉得有以下几个方面做的很不错。
　　团队编码风格统一
　　统一到什么程度? 不看代码作者，你很难区分代码是谁写的(在目前公司一些团队也能达到这个标准)。
　　个人观点:
　　1、这样做有什么好处？团队中每个人阅读代码都很容易，减少很多沟通，维护成本( 代码阅读的次数远远大于变更的次数)，并且心情非常愉悦。有人肯定觉得愉悦有点夸张，举个栗子: 有一些代码，如果不是由于与工作内容有关联，你是否有种这辈子都不情愿去接触它的感受。但也有一些代码，阅读下来一气呵成，心情舒畅，促使你有种继续阅读下去的冲动(并且你也会有种不想破坏这种统一的想法).
　　2、基础层面越统一，效率越高(不仅仅是指统一编码规范，还有基本的做事的原则). 举个栗子: 我们团队规定个人周报必须在每周五上班前必须发出来，否则罚款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以及老大，提醒次数多了还是继续犯类似问题，甚至会劝退。
　　个人观点:
　　1、我在阿里所经历的几个部门规范都很不错，但有的执行起来却比较宽松。因为项目进度一紧， 代码质量容易妥协， 常见的现象 "我下个版本会改过来的"， "这个应该暂时没有问题"， "这个代码是没有按规范来做，但改动风险太大，出故障怎么办". 这时候， 如果你在这妥协， 基本以后代码规范很难维持了。因为一旦ugly的代码上线， 这代码很可能会在项目里扩散开来(和破窗效应类似).
　　2、很多人对代码质量/规范有强烈的意识，但少数人可能感受不那么明显或者还没有体会到这些带来的益处，或者和自己已有习惯差异而产生排斥心里，这时候得用外部压力刺激一下。比如上面提到的每周五 review当周的问题--没人会愿意自己的代码经常被拎出来作反面教材。迫使他朝正向发展， 做到对事不对人可以了。新人对压力可能感触更明显，压力会促使你做事更谨慎， 也有可能让你做事畏首畏尾， 这时候对新人要多加关注。
　　代码质量理解
　　· 代码的可读性放在第一位， 代码尽量做到don't make me think( 这里对集团中间件的开发同学提个建议，希望你们继续提高代码的可读性，因为你们的代码被阅读了无数遍了，你们提高一点可读性，将节约很多人的时间， 你们的代码很可能被很多同学模仿)
　　· 没有bug的代码不一定是高质量的代码， 写代码不能紧紧满足于功能
　　· 你的代码规范不一定要达到开源规范标准(能达到好)，但不要低(松)于团队的代码规范.
　　· 写代码要有敬畏之心。想想如果让你开发载人火箭的程序，你敢随意去写么? 网站一样需要重视.
　　· 团队的代码质量重要程度高于个人代码质量。如果只满足个人代码质量提高，而不去帮助团队提高代码质量，你很可能会踩上别人留下的坑，你在工作中很可能遇到各种不便(当然你也要避免给其他人留坑)。
　　· 良好的代码规范不一定会让你避免bug.但可以帮助你/他人提升找到bug的速度， 以及提升工作效率
　　· 读的源码(书籍)，关注一些细节，对代码质量提升非常有帮助.
　　· codereview不仅仅是为了review出bug。这也是知识分享的一个过程， 团队更有经验的同学会对你的代码提出建议;review人员可以从中获取业务/技术相关信息;被review人员因为有人会review你的代码，而不得不提升自己的代码质量，以及代码的熟悉程度。
　　· 代码规范不会影响开发效率， 你的开发效率应该通过其他的方式去提升。 相反，他会节省你很多成本(阅读，沟通)
　　· 故障多少和自己的技术能力关系其实不是很大，和自身的工作习惯非常大(我看了很多故障案例，绝大多数不是开发同学没有相应的技术能力)
　　· 对自己擅长什么，不擅长什么要有清楚的认识.有的故障产生的原因是对自己某方面能力太过自信.在不擅长的地方去咨询其他有经验的同学，这不会显得自己能力差， 反而给他人的印象是你很重视你的工作，工作谨慎.
　　· 代码有bug是正常现象， 关键是找到有效方法预防和避免再次出现类似问题