工作习惯
· 当你拿到需求时,分析下自己的需求功能点的重要性(不同重要程度的需求，重视程度和花费的精力也不一样).
· 设计时多花点时间思考, 编码通常是比较快的
· 单元测试一定要写, 这是底线(除非这个成本非常大)
· findbugs，pmd这些工具在前几年我用的比较多，但近几年用的已经很少了，原因是发现的问题少,误判的几率还高，现在只是少数情况才会使用。但是新人建议还是多使用一下。
· 在团队中寻找比你代码质量要求更高的同学来review自己的代码，一起探讨问题，这能帮自己很快的提升。有疑义的地方一定要达成共识，立刻执行，并告知团队，并形成规范。
· 尽量不要在情绪低落，体力不支的情况下做需要大量思考性的工作(我个人比较喜欢运动,体力不支的情况比较多.哈哈).
· 写代码就难免会有bug/故障发生.另外一种避免故障的方案是如何尽快知道异常情况(比如做好监控), 在用户投诉之前尽快解决掉，或者提前做好预备方案(通常是比较重要的需求).
· 不要因为错小而放置不理，那会成为你的习惯。
· 周四尽量减少发布, 你可能没有足够时间去观察/验证,发布时尤其需要重视.
· 读源码是我比较喜欢做的一件事情。一方面能够熟悉一些技术原理/业务，开发时更胸有成竹，bug的几率当然也越少，当然你花费的时间可能就会多(你得去衡量). 这个做法也是不得已而为之: 一些部门的文档/代码注释都有问题,沟通又可能不便，读源码反而解决问题比较快.
· 当别人向你提建议时, 心胸开阔点, 你会获取他人更多的帮助机会/建议
续
这篇文章被关注的程度远远超出了我的想像, 原本我并不打算在文章里过多去描述一些影响代码质量的现象，但是评论里提到的问题(比如说如何落地)多少都涉及这些。文章里主要是从普通开发的角度去看代码质量，关于如何落地, 我知道落地肯定不容易, 肯定会面临很多来自团队内外的压力.
举几个栗子:
· 你的老板是否能够接受短期工作效率普遍偏低么(如果采用我在文章中提到的codereview方案)?
· 团队成员是否都和你有类似的代码质量理念, 如果没有, 你得不断去影响他们, 得影响你的老板。 如果做不到, 落地也无从说起.
· 每次故障频率比较高的时候, 高层传达的意思是重视用户体验,提升代码质量。到开发这里，可能是采取更安全的编码, 但不一定是合理的. 要不了多长时间，代码一定会变质.
坦白讲, 我没有很完整的, 可量化的, 可复制的方案, 我现在所在的团队也没有达到这个标准,
但我在alibaba经历过这样的团队, 一个让我终身难忘的团队(还有那家外企)。这样更加让我坚信
我上面的这些想法应该是能落地的, 我也正在努力去影响我现在所在的团队, 即使达不到我预想
的那样, 但我相信一定会有改善.
Alibaba一直被认为是业务驱动型公司, 也许哪天整个集团的代码规范统一并严格执行了, 估计成为技术驱动型的公司就不远了
