第一章 整洁代码
要有代码
阅读本书（书摘）有两种原因，第一，你是个程序员；第二，你想成为更好的程序员；
我们要从各个方向来考察这些代码，从顶向下，从底往上，从里往外；我们的目的是知道这些关于代码的事情，分别好的代码和糟糕代码之间的差异，知道如何写出好的代码，以及如何将糟糕的代码改为好的代码；
有的人也许认为，关于代码的书有点了落后时代——代码将不再是问题；我们应该关注于模型和需求；很快，代码就会自动产生，不需要人工编写；
扯淡！我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被抽象，必须明确。将需求明确到机器可以执行的程度，就是编程要做的事情，而这种规约，就是代码;
即便是特定领域语言的数量继续增加，也终止不了代码。实际上，在较高层次上使用特定领域语言撰写的规范也终将是代码！它也需要严谨、精确、规范和详细，好让机器理解和执行；
如果说需求规约原则交给了我们什么，那就是归置良好的需求就像代码一样正式，也能作为代码的可执行测试来使用；
代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求无限接近的语言，我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而，我们永远也无法抛弃必要的精确性——所以代码永存；
糟糕的代码
我们知道好代码重要，是因为其短缺实在困扰了我们太久；
他们赶着推出产品，代码写的乱起八糟，特性越多，代码也就越烂，最后再也无法管理这些代码了；——这就是混乱代码对创造它的人的回报；
为什么要写糟糕的代码呢？是想快点干完吗？是赶时间吗？或许你只是不耐烦再搞这套程序，期望早一点结束；我们都干过这种事；
我们都曾瞟过一眼自己亲手造成的混乱，但是我们决定弃之不顾，走向新的一天；
我们都曾看到自己的烂程序竟然可以运行，然后断言能运行的程序比什么都没有要强；
我们都曾说过有朝一日再回头清理，当然我们都没有听过勒布朗法则：稍后等于永不！；
混乱的代价
每次添加或者修改代码，都得对那堆扭纹柴了然于心，才能往上扔更多的扭纹柴。这团乱麻越来越大，再也无法清理，最后束手无策；
新人不知道系统设计，不知道什么样的修改符合设计意图，什么样的修改违背设计意图，而且他们背负着提高生产力的可怕压力，于是他们制造更多的混乱；生产力再次趋向零；直到再也无法在这令人生厌的代码基础上做开发，于是推到重来，可是，只有一部分人才能参加到重来的队伍中，其他人仍然需要继续维护旧的系统；
新系统的构建时间很长，到了快完成的时候，原来提出推倒重来的成员已不知去向，而现有的成员则要求重新设计一套新系统，因为现有的系统太烂了；
花时间保持代码整洁不但有关效率，还有关生存；
好代码为什么会这么快变质为糟糕代码？原因有很多。我们抱怨需求的变化背离了设计的初衷，我们哀叹进度很紧张，没法干好活，我们把问题归咎于愚蠢的经理，苛求的用户等，但是实际上，我们是自作自受，我们太不专业了。
经理会奋力维护进度和需求，那是他们该干的，而你应该以同等的热情维护代码；
有那么几年经验的开发者们都知道前期的混乱会拖自己的后腿，但是他们背负期限的压力，于是他们只好制造混乱，简而言之，他们没有花时间让自己做的更快；
然而真正的专业人士明白，上面的话是错误的。制造混乱无助于赶上期限，只会立即拖慢你，。赶上期限的唯一方法就是适中尽量保证代码整洁！
如果你不明白整洁代码的意义，尝试着去写整洁代码就毫无益处；
能分辨整洁代码和脏代码，并不意味着会写整洁代码；
编写整洁代码，需要大量的小技巧，一种贯彻刻苦习得的“整洁感”。这种代码感就是关键所在。
缺乏代码感的程序员，看混乱是混乱，无处着手，但是有代码感的程序员能从混乱中看出其它可能的改进方法；
编写整洁代码的程序员就像是艺术家；
什么是整洁代码？他们这样说：
优雅和高效的代码，代码逻辑应当直截了当，叫缺陷无法隐藏；尽量减少依赖关系，使之便于维护；按照某种分层战略完善错误处理代码；性能做到最优，省得引诱别人做没规矩的优化，搞出一堆混乱。整洁代码只做好一件事。（C++语言的发明者：Bjarne Stroustrup）；
优雅！整洁的代码阅读起来令人愉悦！效率！完善错误处理代码，往深处说是在细节上花心思，敷衍了事的错误处理代码是程序员忽略细节的一种表现；最后，整洁代码只做一件事！糟糕代码想做的事情太多，结果除了混乱，还是混乱；
整洁代码直截了当，如同优美的散文，它们从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句；（Grady Booch，《面向对象分析与设计》一书的作者）；
整洁代码应该由开发者之外的人员阅读和增补。它应有单元测试和验收测试。使用有意义的命名，只提供一种而非多种做一件事的途径，尽量少的API，代码应该通过其字面量表达含义；（Dava Tomas OTI公司创始人）；
整洁代码就像是某位特别在意它的人写的，几乎没有改进余地。代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人的代码；（Michael Feathers，《修改代码的艺术》一书的作者）；
没有重复代码、体现系统中的全部设计理念、包括尽量少的实体，比如类、方法、函数；（Ron Jeffries，《极限编程实施》一书的作者）；不要重复代码、只做一件事、表达力、小规模抽象是其认为的重点；
如果每个程序都让你感到深合己意，那么就是整洁代码，如果代码让编程语言看起来就是专门解决那个问题而存在，就可以称为漂亮代码；（Ward Cunningham，WiKi的发明者，极限编程的创始人之一，Smalltalk 语言和面向对象思想的领袖。所有在意代码者的教父）；
语言是冥顽不灵的，是程序员让语言显得简单；
思想流派
武术家从不认同所谓的最好的武术，也不认同所谓的绝招。武术大师常常创建自己的流派，聚徒而教；
任何门派都并非绝对正确；
本书中列出的建议，乃是我们长久苦思、从数十年的从业经验和无数尝试与试错中得来，无论你同意与否，如果你没有看到或是不尊重我们的观点，就该为自己害臊；
我们是作者
我们是作者，作者都有读者，作者有责任与读者做良好沟通；
新代码时，我们一直在读旧代码。既然读代码的比例占的如此高，我们希望让读的过程变得轻松，哪怕这会使编写的过程变得更难。从另一个角度来说，使之易读实际上也使之易写;
写代码的难度，取决于读周边代码的难度，要想干得快，要想轻松写代码，先让代码易读；
童子军军规
让营地比你来时更干净；
如果每次签入时，代码都比签出的时候整洁，那么代码就不会腐坏；
你想为一个代码随时间流逝而变得更好的项目工作吗？持续改进是专业性的内在组成部分；
前传与原则
从许多角度来看，本书都是《敏捷软件开发：原则、模式与实践（Agile Software Development: principles, patterns and practices），简称PPP》的前传。所以整洁代码也涉及到常见的设计原则，比如：单一职责、开闭原则、依赖倒置原则、里式替换原则、迪米特原则、接口隔离原则
小结
艺术书并不能担保你阅读完后成为艺术家，它只能告诉你艺术家用过的工具、技术和思维过程。同样，这本书也不会给你代码感，它能做的只是展示好程序员的思维过程，还有他们使用的技术、工具；
你会看到一个又一个例子，但最终结果取决于你自己；
你还得练，孩子，还得练！
学习收获
代码是什么？代码是用来描述需求的！它不仅仅是一行“Hello World”。实际上，最早的那一行Hello World也是描述了一种需求，不是吗？作为计算机专业的学生，我们学习了C++、Java、C#等具体编程语言，可是没有老师正式在课堂上解释过什么是代码，似乎我们使用那些编程语言的输出结果就是代码。可是，是那样吗？我们是一群写代码的人，我们其实是一群描述需求的人，只是用户使用人类语言向我们描述需求，而我们将向机器描述我们的需求；
没有什么是绝对正确的，我想也不存在XXX是世界上最好的语言、XXX是最好的工具；如果这样认为，其实只是我们沉浸在这一领域，以其技为善。就像书中所说，各派有其善法，但这并不能否定其他门派所授之法；
说实话，第一次看这本书大概是大二上学期或者大一下学期的时候，看了本书的第一章之后，有很长的一段时间，我不敢写代码，怕写出烂代码，因为学习之初，常常使用 int a=10; int* b=&a;这样的语句，这些带我入门的代码被称为脏代码，感觉自己傻了一样。不过也正是那段时间，开始学习面向对象的相关知识，从而接触到设计模式等知识，既然不敢写代码，那我就先学如何才能写出好代码呗，总不能闲着啊，哈哈哈。现在重新学习总结这本书，有了写烂代码的经验，阅读时也就有了更多的体会，还是蛮不错的。
不过，最后一句话更有启示和鞭策：“你还得练，孩子，还得练！”；
另外，本系列文章中，除了学习收获下面的内容，其余全部观点均来自书中摘录，在此向书的作者致以崇高敬意！