为什么要写糟糕的代码？
- 赶时间完成任务 ，期望后面再清理.
- 勒布朗法则：稍后等于永不（Later equals never）
混乱的代价：
- 代码变的无法管理，团队生产力下降，
- 增加人力？Brooks定律(人月神话)：向进度落后的项目中增加人手，只会使进度更加落后。
- 破窗理论：假如原来的代码很优秀，新加入的代码会害怕破坏这美妙的整体而变的更好，反之则不会去在意。
开始新设计:
- 新系统设计与旧系统维护竞赛，时间可持续十年之久，完成时成员早不知去向
- 花时间保持代码整洁不但关乎效率，还关乎生存
- 制造混乱无助于赶上工期，只会拖累，唯一方法就是始终尽可能保持代码整洁
什么是整洁代码？
Bjarne stroustrup：
我喜欢优雅和高效的代码，代码逻辑应直截了当，叫缺陷难以隐藏；尽量减少依赖，使之便于维护；依据某种分成战略完善错误代码处理；性能调至最优，省的引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。
Michael Feathers(修改代码的艺术作者)：
我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代码总是看起来像是某位特别在意它的人写的，几乎没有什么改进的余地，代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码———全心头人的某人留下的代码。
Ron（c#极限编程探险作者）:
不要重复的代码（表示某种想法未在代码中得到良好的体现），只做一件事，提早构建简单抽象（在集合中查找某物）
美国童子军军规：让营地比你来时更干净。
改好一个变量名，拆分一个过长的函数，消除一点点重复代码
