在本篇文章中,我们主要介绍重构风险的内容,自我感觉有个不错的建议和大家分享下
1. Clean Code that works, 让代码工作，让代码干净，即把事件做对和做好。
写代码就像写文章，是要给别人看的，不仅仅是运行而已，所以要给人看得懂，不能让人看了后直骂娘。
2. KISS(keep it simple stupid) , 让代码简单直接，要做到这个就一定要有责任心，要一直的重构，并且有重构的方法，比如小步前进，用单元测试保障重构的品质，增加风险，我们要相信没有谁能一次写出好的代码，90%的代码须要通过重构来进步品质。
3. 童子军军规"要让分开时的营地比进去时更干净"，在修改别人的代码时，即使不要求你重写别人的代码，最少你的代码不能让本来的代码更混乱，如果时间允许那重构原有的代码更好，但是一定要记得重构的方法，并且要有充足的测试来保障重构的品质。
4. 如果你存眷品质，那长时间来看，品质会回升，成本会下降; 反之，如果你存眷成本，那长时间来看，品质会下降，成本会回升。
5. 不要对烂代码写注释，而是直接重写它。
最为值得珍惜的是今天，因为最容易流逝的就是今天，把握今天就是把握希望，分分秒秒只是瞬间，而所乘载的分分秒秒就叫做一天，时间的流逝往往是在不经意之间，人生几回，青春更珍贵，对于我们这个年龄的青少年来说，青春已不足二十载，在学习的生活中我们必须靠自己的力量，驾驭着自己的小船驶向希望的彼岸。
我们在做管理的培训时，我记得有讲到说，如果到了项目的前期，发现代码比较烂，项目经理要不要让团队去重构代码呢? 讲师说如果客户不给更多的时间或是付更多的钱就不要去修改已经可以上线的代码，因为修改代码有风险，而且要付出成本。从成本的角度来说是对的，但是我们想想，如果发现代码很烂，且很有重构的必要的时候，说明我们的代码很难维护，或者隐含着重大的品质风险，那么上线后可以碰到更严峻的问题，致使客户损失惨重，我们也可能因为付出大的价值。
那是不是说我们应当重构的，我觉得这不是绝对的，要看具体的情况，比如说，如果最后的期限已到，而又没有发现重大缺陷，只是代码难以维护，或者可读性很差，或是性能有点问题，那么我们可以先上线，然后继续重构，并发布更新给客户，这样既不致使项目延期，又保障了品质。
如果项目时间还够，那么就要果断的重构，不要因为怕成本回升，后面说了只有存眷品质才能最终保障成本。但是重构不是随意停止的， 如果没有好的单元测试，集成测试，那么重构的风险过大，不如不重构，所以一开始就要保障一定要有良好的单元测试。另外重构一定要小步停止，不能一次改大量的代码，然后集成测试，这样的风险是很大的，容易失控，所以每次改一小部分，然后马上单元测试，每天都要集成测试，如果有CI就更好了。
摘一段微博：我从去年底开始在腾迅搜搜里勉励工程师写单元测试，每周写得好的都能取得现金奖励，不到一年上去，很多工程师的代码品质和品质意识上了一个台阶，省下的测试人员的工资，比发的资金多得多，品质问题首先是当头的意识问题。
部分内容摘自迅速一千零一夜发的微博
文章结束给大家分享下程序员的一些笑话语录： 腾讯的动作好快，2010年3月5日19时28分58秒，QQ同时在线人数1亿！刚刚看到编辑发布的文章，相差才2分钟，然后连专题页面都做出来了，他们早就预料到了吧？（其实，每人赠送10Q币，轻轻松松上两亿！）
--------------------------------- 原创文章 By
重构和风险
---------------------------------