软件质量不但依赖于整体的项目架构及项目管理，而且与代码质量紧密相关。书中有一个观点我觉得很对：代码质量与代码整洁度成正比。干净的代码，既在质量上较为可靠，也为后期的项目维护、迭代奠定了良好的基础。
一、糟糕的代码
作者用一个故事讲述了糟糕的代码造成的后果：
有家公司写了个很流行的应用，推出后很多专业人士都买来用。但是好景不长，慢慢的迭代周期开始拉长，bug总是不能修复，崩溃的几率越来越大。以至于所有的用户都抛弃了这款应用，然后这家公司倒闭了。后来，作者遇到该公司的工程师时向他了解当年的情况，那位工程师说，当时他们赶着推出产品，代码没有规范，写的乱七八糟，特性越加越多，代码也越来越烂，最后再没有办法管理这些代码了。最终糟糕的代码致使这家公司倒闭，由此可见糟糕的代码带来的危害。
你是否有过这样的经历：在自认为没有问题的模块或者功能上战战兢兢的调试自己之前认为没有问题的代码？经理们是否把我们盯得如芒刺在背？
你是否曾为糟糕的代码困扰过吗？答案我想是肯定的。那么为什么还要写糟糕的代码呢？
是想快点完成吗？是要赶项目周期吗？有可能，或许你觉得自己要干好所需时间很长；或许你觉得如果花时间清理代码，从而拖延了开发进度就会导致经理或者老板大发雷霆；或许你只是不耐烦再搞这套程序，期望尽早结束这个项目；或许你手上还积压着别的工作，让你意识到赶紧弄完手上的东西，然后进行下一项工作。凡此种种，我想大家都经历过。
作者也提出了一个有意思的比喻，即嘲笑低水平编码者为Code Monkey(代码猴子)。“是的，我们就是一群代码猴子，上蹿下跳，自以为领略了编程的真谛。可惜，当我们抓着几个酸桃子就得意洋洋的坐在树枝上，却对自己造成的混乱熟视无睹，那堆‘可以运行’的乱麻程序，就在我们眼皮底下慢慢腐坏。
我们都曾瞟了一眼自己亲手造成的混乱，觉得还能运行没有明显bug，然后决定弃之不顾，走向新一天。我们都曾看到自己写的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有要强。我们都说过先放一放再回头处理，但是通常不出问题的时候我们再也不会回头。勒布朗法则说：稍后等于永不。就是这样的。
二、混乱的代价
有过几年编程经验的人都应该被糟糕的代码困扰过，遇到这种代码的时候有可能就会严重拖延项目进度。因为你每次修改的时候都会影响到其他几处代码。代码无小事，每次添加或者修改代码，你都得对之前的代码了然于心，然后才能添加或者修改，然后这团乱麻就会越来越大，直到再也无法清理，无法维护，束手无策。
随着混乱的增加，团队的生产效率也逐渐下降，甚至趋向于零。当生产力下降，管理层能做的只是增加人手进入到这个项目中，期望能够提升生产效率，但是新人对系统业务不熟悉，不知道怎么改才符合设计，怎么改算违背设计。然后还背负着提升效率的责任，最后只能越来越混乱。
最后的最后，开发团队要求管理层重新写一个新系统，做全新的设计，不但要实现老系统的所有功能，并且能够持续迭代。这时大家都想离开这糟糕的老系统，加入到新系统的开发中，认为新系统一定不会有这些问题。然后留下剩下的人在新系统出来之前继续维护老系统，直到新系统能够与老系统抗衡或者超越，才会把老系统替换为新系统。但是等到新系统上线了，要逐步迭代的时候突然发现，新系统也存在同样的问题。
三、专业的做法
当产品经理提出需求你做一个功能时，一定要站在开发的角度好好考虑一下可能性，如果你认为不能实现或者有更好的方式就可以明确的拒绝他，并告诉他你的理由。并且一定要把所有的功能规划和改动都在文档中体现出来，保持文档的一致性，以防以后相互扯皮。这样是对你的项目负责，对你负责，是专业的做法。
四、谜题
程序员面临一道基础价值谜题。有几年开发经验的人有时会遇到这样的问题，因为以前的代码造成的混乱而拖延了你现在的开发进度的时候，开发人员通常都会基于糟糕的代码继续制造混乱。 但是你要明白即使这次你在制造混乱的同时完成了开发进度，但是下次再改呢，下下次再改呢，越来越多的混乱只会立刻拖慢你，让你无从下手，而保证在开发周期内完成进度的唯一办法就是始终保持代码的整洁。
五、什么是整洁代码
- 认真的对待每个变量名，当用给自己孩子起名般赋予恰当的命名，最好见名知意
- 代码逻辑直截了当，叫缺陷无处隐藏
- 尽量减少依赖关系，尽量使程序解耦合，使之便于维护
- 将代码性能调到最优，省的引诱别人做不合理的优化而搞出一堆混乱
- 几乎没有改进的余地，代码作者什么都想到了，如果你企图改进它，总是会回到原点
- 能通过所有的测试
- 没有重复的代码
- 每段代码都应该在你希望他在所在的地方，如果不在那里，就需要重构了
- 对于那种四处遗弃的被注释的代码除之而后快
- 使用一致的代码风格。
六、童子军军规
美国童子军的一条简单军规，应用到我们的专业领域： 让营地比你来时更干净。
对于我们来说就是，每次修改或者添加代码后要比你修改或添加前要干净整洁；代码迁入之后要比迁入之前干净(也许只是改好一个变量名，拆分一个过长的函数，消除一些重复的代码)。
要想写出整洁代码很难。特别是开头很难，这需要遵循大量的技巧和实践，但是这就是一个质变到量变的过程，等到了临界点突破了那个度，一切就都豁然开朗了。
