1. Clean Code that works, 让代码工作，让代码洁净，即把事情做对和做好。
写代码就像写文章，是要给别人看的，不仅仅是运行而已，所以要给人看得懂，不能让人看了后直骂娘。
2. KISS(keep it simple stupid) , 让代码简单直接，要做到这个就一定要有责任心，要不断的重构，并且有重构的方法，比如小步前进，用单元测试保证重构的质量，减少风险，我们要相信没有谁能一次写出好的代码，90%的代码需要通过重构来提高质量。
3. 童子军军规"要让离开时的营地比进去时更干净"，在修改别人的代码时，即使不要求你重写别人的代码，至少你的代码不能让原本的代码更混乱，如果时间允许那重构原有的代码更好，但是一定要记得重构的方法，并且要有足够的测试来保证重构的质量。
4. 如果你关注质量，那长期来看，质量会上升，成本会下降; 反之，如果你关注成本，那长期来看，质量会下降，成本会上升。
5. 不要对烂代码写注释，而是直接重写它。
我们在做管理的培训时，我记得有讲到说，如果到了项目的后期，发现代码比较烂，项目经理要不要让团队去重构代码呢? 讲师说如果客户不给更多的时间或是付更多的钱就不要去修改已经可以上线的代码，因为修改代码有风险，而且要付出成本。从成本的角度来说是对的，但是我们想想，如果发现代码很烂，且很有重构的必要的时候，说明我们的代码很难维护，或者隐含着重大的质量风险，那么上线后可以遇到更严重的问题，导致客户损失惨重，我们也可能因为付出大的代价。
那是不是说我们应该重构的，我觉得这不是绝对的，要看具体的情况，比如说，如果最后的期限已到，而又没有发现重大缺陷，只是代码难以维护，或者可读性很差，或是性能有点问题，那么我们可以先上线，然后继续重构，并发布更新给客户，这样既不导致项目延期，又保证了质量。
如果项目时间还够，那么就要果断的重构，不要因为怕成本上升，前面说了只有关注质量才能最终保证成本。但是重构不是随便进行的， 如果没有好的单元测试，集成测试，那么重构的风险过大，不如不重构，所以一开始就要保证一定要有良好的单元测试。另外重构一定要小步进行，不能一次改大量的代码，然后集成测试，这样的风险是很大的，容易失控，所以每次改一小部分，然后马上单元测试，每天都要集成测试，如果有CI就更好了。
摘一段微博：我从去年底开始在腾迅搜搜里鼓励工程师写单元测试，每周写得好的都能获得现金奖励，不到一年下来，很多工程师的代码质量和质量意识上了一个台阶，省下的测试人员的工资，比发的资金多得多，质量问题首先是当头的意识问题。
部分内容摘自敏捷一千零一夜发的微博