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