一、糟糕的代码
作者用一个故事讲述了糟糕的代码造成的后果：
有家公司写了个很流行的应用，推出后很多专业人士都买来用。但是好景不长，慢慢的发布周期开始拉长，bug总是不能修复，装载的时间越来越久，崩溃的几率越来越大。以至于所有的用户都抛弃了这款应用，然后这家公司倒闭了。后来，作者遇到该公司的雇员时向他了解当年的情况，那位雇员说，当时他们赶着推出产品，代码写的乱七八糟，特性越加越多，代码也越来越烂，最后再没有办法管理这些代码了。最终糟糕的代码致使这家公司倒闭，由此可见糟糕的代码带来的危害。
那么你曾为糟糕的代码困扰过吗？答案我想是肯定的。那么为什么还要写糟糕的代码呢？
是想快点完成吗？是要赶项目周期吗？有可能，或许你觉得自己要干好所需时间不够，或许你如果花时间清理代码，从而拖延了项目周期就会导致经理或者老板大发雷霆；或许你只是不耐烦再搞这套程序，期望尽早结束这个项目；或许你手上还积压着别的工作，让你意识到赶紧弄完手上的东西，然后进行下一项工作。凡此种种，我想大家都经历过。我们都曾瞟了一眼自己亲手造成的混乱，然后决定弃之不顾，走向新一天。我们都曾看到自己写的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有要强。我们都说过先放一放再回头处理，当然，在那日子里我们都没听过勒布朗法则：稍后等于永不。
二、混乱的代价
有过几年编程经验的人都应该被糟糕的代码困扰过，遇到这种代码的时候有可能就会严重拖延项目进度。因为你每次修改的时候都会影响到其他几处代码。代码无小事，每次添加或者修改代码，你都得对之前的代码了然于心，然后才能添加或者修改，然后这团乱麻就会越来越大，直到再也无法清理，无法维护，束手无策。随着混乱的增加，团队的生产效率也逐渐下降，甚至趋向于零。当生产力下降，管理层能做的只是增加人手进入到这个项目中，期望能够提升生产效率，但是新人对系统业务不熟悉，不知道怎么改才符合设计，怎么改算违背设计。然后还背负着提升效率的责任，最后只能越来越混乱。最后的最后，开发团队要求管理层重新写一个新系统，做全新的设计，不但要实现老系统的所有功能，并且能够持续改动。然后在新系统出来之前继续维护老系统，知道新系统能够与老系统抗衡或者超越，才会把老系统替换为新系统。
三、专业的做法
当产品经理要求你做一个功能时，一定要站在开发的角度好好考虑一下可能性，如果你认为不能实现或者有更好的方式就可以明确的拒绝他，并告诉你的理由。这样是对你的项目负责，对你负责，是专业的做法。
四、谜题
程序员面临一道基础价值谜题。有几年开发经验的人都知道，之前的混乱拖了自己的后腿，但开发者背负期限的压力，只好基于糟糕的代码继续制造混乱。 但是你要明白制造混乱无助于赶上期限，混乱只会立刻拖慢你，叫你错误期限，赶上期限的唯一办法就是始终保持代码的整洁。
五、什么是整洁代码
- 代码逻辑直截了当，叫缺陷无处隐藏
- 尽量减少依赖关系，使之便于维护
- 将性能调制最优，省的引诱别人做不合理的优化而搞出一堆混乱
- 几乎没有改进的余地，代码作者什么都想到了，如果你企图改进它，总是会回到原点
- 能通过所有的测试
- 没有重复的代码
- 体现系统中全部的设计理念
- 运用尽量少的实体，比如类、方法、函数等
六、童子军军规
美国童子军的一条简单军规，应用到我们的专业领域： 让营地比你来时更干净。
对于我们来说就是，每次修改或者添加代码后要比你修改或添加前要干净整洁；代码迁入之后要比迁入之前干净(也许只是改好一个变量名，拆分一个过长的函数，消除一些重复的代码)。