《代码简洁之道》读书笔记之六：并发编程、逐步改进、注释

第十三章讲的是我是在看不懂的并发编程，可能是因为基本上没有用到。编写整洁的并发程序很难--非常难。编写在单线程中执行的代码简单得多。
13.1 为什么要并发。并发是一种解耦策略。它帮助我们把做什么和何时做分解开。

13.2 解耦的目的与时机能明显得改进应用程序的吞吐量和结构。

第十四章说的是对代码的逐步改进，不该满足于现状。代码能工作还不够。能工作的代码经常会严重崩溃。满足于仅仅让代码能工作的程序员不够专业。他们会害怕没时间改进代码的结构和设计，没有什么能比糟糕的代码给开发项目带来更深远和长期的损害了。

十五章讲的十分有趣，味道和启发，要我们在写代码的时候时刻注意这些可能坏了代码味道的代码，有点多。。。

15.1 注释。
15.1.1 不恰当的信息。注释只应该描述有关代码和设计的技术性信息。
15.1.2 废弃的注释。过时、无关或不正确的注释就是废弃的注释。
15.1.3 冗余注释。如果注释描述的是某种充分自我描述了的东西，那么注释就是多余的。
15.1.4 糟糕的注释。值得编写的注释，也值得好好写。如果要编写一条注释，就花时间保证写出最好的注释，字斟句酌。
15.1.5 注释掉的代码。看到被注释掉的代码会令我抓狂。看到注释掉的代码，就删除它！别担心，源代码控制系统还有记得它。
15.2 函数。
15.2.1 过多的参数。函数的参数量应该少。没有参数最好。
15.2.2 输出参数。输出参数违反直觉。读者期望参数用于输入而非输出。如果函数非要修改什么东西的状态不可，就修改它所在的对象的状态好了。
15.2.3 标识参数。布尔值参数大声宣告函数做了不止一件事。
15.2.4 死函数。永不被调用的方法应该丢弃。
15.3 一般性问题。
15.3.1 一个源文件中存在多种语言。
15.3.2 明显的行为未被实现。函数或类应该实现其他程序员有理由期待的行为。
15.3.3 不正确的边界行为。函数应该有正确行为。开发者常常写出他们以为能工作的函数，信赖自己的直觉，而不是努力去证明代码在所有的角落和边界情形下真能工作。
15.3.4 忽视安全。
15.3.5 重复。每次看到重复代码，都代表遗漏了抽象。重复的代码可能成为子程序或干脆是另一个类。将重复代码叠放进类似的抽象，增加了你的设计语言的词汇量。重复最明显的形态是你不断看到明显一样的代码，可以用单一方法来替代之。较隐蔽的形态是在不同模块中不断重复出现、检测同一组条件的switch/case或if/else链。可以用多态来替代之。更隐蔽的形态是采用类似算法但具体代码行不同的模块。
15.3.6 在错误的抽象层级上的代码。
15.3.7 基类依赖于派生类。将概念分解到基类和派生类的最普遍的原因是较高层级基类概念可以不依赖于较低层级派生类概念。
15.3.8 信息过多。设计良好的模块有着非常小的接口。
15.3.9 死代码。死代码就是不执行的代码。可以在检查不会发生的条件的if语句中找到。
15.3.10 垂直分隔
15.3.11 前后不一致。
15.3.12 混淆视听。没有实现的默认构造器有何用处呢？它只会用无意义的杂碎搞乱对代码的理解。没有用到的变量，从不调用的函数，没有信息量的注释，等等，这些都是应该移除的废物。
15.3.13 人为耦合。不互相依赖的东西不该耦合。人为耦合是指两个没有直接目的之间的模块的耦合。
15.3.14 特性依恋。类的方法只应对其所属类中的变量和函数感兴趣。不该垂青其他类中的变量和函数。当方法通过某个其他变量的访问器和修改器来操作该对象内部数据，则它就依恋于该对象所属类的范围。
15.3.15 选择算子参数。
15.3.16 晦涩的意图。代码要尽可能具有表达力。
15.3.17 位置错误的权责。软件开发者做出的最重要决定之一就是在哪里放代码。最小惊异原则在这里起作用了。
15.3.18 不恰当的静态方法。
15.3.19 使用解释性变量。让程序可读的最有力方法之一就是将计算过程打散成在用有意义的单词命名的变量中放置的中间值。
15.3.20 函数名称应该表达其行为。
15.3.21 理解算法。
15.3.22 把逻辑依赖改为物理依赖。如果某个模块依赖于另一个模块，依赖就该是物理上的而不是逻辑上的。依赖者模块不应该对被依赖者模块有假定。
15.3.23 用多态替代if/else 或 switch/case。
15.3.24 遵循标准约定。
15.3.25 用命名变量替代魔术数。有些变量与非常具有自我解释能力的代码协同工作时，如此易于识别，也就不必总是需要命名常量来隐藏。
15.3.26 准确。期待某个查询的第一次匹配就是唯一匹配可能过于天真。用浮点数表示货币几近于犯罪。
15.3.27 结果基于约定。坚守结构基于约定的设计决策。
15.3.28 封装条件。如果没有if或while语句的上下文，布尔逻辑就难以理解。应该把解释了条件意图的函数抽离出来。
15.3.29 避免否定性条件。否定式要比肯定式难明白一点。所以，尽可能将条件表示为肯定形式。
15.3.30 函数只该做一件事情。编写执行一系列操作的包括多段代码的函数常常是诱人的。这类函数做了不只一件事情，应该转换为多个更小的函数，每个只做一件事。
15.3.31 掩蔽时序耦合。
15.3.32 别随意。构建代码需要理由，而且理由应与代码相契合。如果结构显得太随意，其他人就会想修改它。如果结构自始自终保持一致，其他人就会使用它，并且遵循其约定。
15.3.33 封装边界条件。边界条件难以追踪。把处理边界条件的代码集中到一处，不要散落于代码中。
15.3.34 函数应该只在一个抽象层级上，该层级应该是函数名所示操作的下一层。这可能是最难理解和遵循的启发。
15.3.35 避免传递浏览。通常我们不想让某个模块了解太多其协作者的信息。
15.4 名称。
15.4.1 采用描述性名称。不要太快取名，确认名称具有描述性。记住，事物的意义随着软件的演化而变化，所以，要经常性地重新估量名称是否恰当。