《代码整洁之道》阅读总结（1）

> Later equals never.
> 
> But the fault, dear Brutus, is not in our stars, but in ourselves, that we are underlings.
> 
> 我喜欢优雅和高效的代码。代码逻辑应当直截了当，令缺陷难以隐藏；尽量减少依赖关系，使之使于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。
> ——Bjarne Stroustrup
> 
> 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了千净利落的抽象和直截了当的控制语句。
> ——Grady Booch
> 
> 整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系，而且要明确地定义和提供清晰的、尽量少的 API。 代码应通过其字面表达含义，因为不同的语言导致并非所有必需的信息均可通过代码自身清晰表达。
> ——Dave Thomas
> 
> 我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有政进的余地。代码的作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。
> ——Micheal Feathers
>
>近年来，我开始研究贝克的简单代码规则，差不多也都琢磨透了。简单代码，依其重要顺序：
>能通过所有测试;
>没有重复代码；
>体现系统中的全部设计理念；
>包括尽量少的实体，比如类、方法、函数等。
>在以上诸项中，我最在意代码重复。如果同一段代码反复出现，就表示某种想法未在代码中得到良好的体现。我尽力去找出那到底是什么，然后再尽力将其更清晣地表达出来。
>在我看来，有意义的命名是体现表达力的一种方式，我往往会修改好几次才会定下名字来。借助 Eclipse 这样的现代编码工具，重命名代价极低，所以我无所顾忌。
>然而，表达力还不只体现在命名上。我也会检查对象或方法是否想做的事太多。
>如果对象功能太多，最好切分为两个或多个对象。如果方法功能太多，我总是使用抽取手段（Extract Method）重构之，从而得到一个能较为清晣地说明其自身功能的方法，以及另外数个说明如何实现这些功能的方法。
>消除重复和提高表达力让我在整洁代码方面获益良多，只要铭记这两点，改进脏代码时就会大为改观。不过，我时常关注的另一规则就不太好解释了。
>这么多年下来，我发现所有程序都由极为相似的元素构成。例如“在集合中查找某物”。不管是雇员记录数据库还是键值对哈希表，或者某类条目的数组，我们都会发现自己想要从集合中找到某一特定条目。一旦出现这种情况，我通常会把实现手段封装到更抽象的方法或类中。这样做好处多多。
>可以先用某种简单的手段，比如哈希表来实现这一功能，由于对搜索功能的引用指向了我那个小小的抽象，因此能随需应变，修改实现手段。这样既能快速前进，又能为末来的修改预留余地。
>另外，该集合抽象常常提醒我留意 “真正”在发生的事，避免随意实现集合行为，因为我真正需要的不过是某种简单的查找手段。
>減少重复代码，提高表达力，提早构建简单抽象。这就是我写整洁代码的方法。
>——Ron Jeffries
>
>如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在的，就可以称之为漂亮的代码。
>——Ward Cunningham