代码整洁之道摘录
本书观念：
代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础。一系列的整洁代码操作实践总结为一条条的规则，只要遵循这些规则，就能写出干净的代码，从而有效提高代码质量。
神在细节
代码猴子(Code Monkey)->童子军规
阐述了命名、函数、注释、代码格式、对象和数据结构、错误处理、边界问题、单元测试、类、系统、并发编程等方面如何做到整洁的经验与最佳实践。
代码感
穷尽应知之事，对其烂熟于心，刻苦实践操作
琢磨代码好在哪里，坏在哪里
第一部分（前几章）：整洁代码的原则、模式和实践
第二部分：案例研究（尤为重要）
第三部分：启示和灵感
编写、阅读、清理代码的思维方式知识库
第1章 整洁代码
糟糕的代码毁一个公司
稍后等于永不
整洁的代码只做好一件事
整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直接了当的控制语句
如何在意代码即是本书主旨根据你写得代码可以看出写的人如何在意代码
简单代码：1）能通过所有测试；2）没有重复代码；3）体现系统中的全部设计理念；4）包括尽量少的实体，比如类、方法、函数等。
Ward Cunningham，Wiki发明者，eXtreme Programming（极限编程）的创始人之一，Smalltalk语言和面向对象的思想领袖。所有在意代码的教父
”一块代码专为解决某个问题而存在“
童子军军规
”让营地比你来时更干净“
第2章 有意义的命名
如果名称需要注释来补充，就不算是名副其实
有意义的区分，读的出来的名称，可搜索名称，避免思维映射
明确是王道
类和对象名：名词或名词短语
方法名：动词或动词短语
命名备好体现的是一种描述技巧和文化背景
第3章 函数
程序和子程序->程序、子程序和函数->函数...函数规则：短小；做好一件事（只做一件事的函数无法被合理切分为多个区段）；函数与抽象层级对应（一个函数对应一个抽象层级）
沃德原则：“如果每个例程都让你感到深合己意，那就是整洁代码”
参数：再一再二，不过三，除非特殊理由
丑陋的标识参数：“标识参数的传入，是在宣布本函数不止做一件事”
一般：参数多余三个，部分参数可封装为类
避免使用输出参数
抽离Try/Catch代码块
写好函数：初稿->一套单元测试->打磨代码（分解函数、修改名称、消除重复）->遵循规则，组装函数
函数：语言的动词；类：语言的名词；系统：精确的讲述一个故事
第4章 注释
Brian W.Kernighan 与 P.J.Plaugher：“别给糟糕的代码加注释——重新写吧。”
注释是弥补我们在用代码表达意图时遭遇的失败
好注释：法律信息；提供基本信息；对意图的注释；阐释；警示；TODO注释；放大不合理；
第5章 格式
一套管理代码格式的简单规则，惯行之实体变量：类的顶部声明
相关函数：放在一起，调用者在被调用者上
概念相关：放在一起
团队规则第一
第6章 对象和数据结构
过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数。面向对象代码便于在不改动既有函数的前提下添加新类。
得墨忒耳律（The Law of Demeter）认为，模块不应该了解它所操作对象的内部情形。
对象暴露行为，隐藏数据。便于添加新对象类型二无需修改既有行为，同时也难以在既有对象中添加新行为。
数据结构暴露数据，没有明显的行为。便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构。
第7章 错误的处理
如果你在方法中抛出异常，而catch语句在三个层级之上，你就得在catch语句和抛出异常处之间的每个方法签名中声明该异常。给出异常发生的环境说明
依调用者需要定义异常类
不返回null值、不传递null值
第8章 边界
第9章 单元测试
TDD三定律：定律一：在编写不能通过的单元测试前，不可编写生产代码；
定律二：只可编写刚好无法？的单元测试，不能编译也算不通过。
定律三：只可编写刚好足以通过当前失败测试的生产代码
测试代码和生产代码一样重要。需要被思考、被设计和被照料。
测试代码：明确、简洁和足够的表达力。
每个测试一个断言
每个测试一个概念
整洁测试5规则：快速，独立，可重复，自足验证和及时。
第10章 类
类：短小（权责）单一权责原则：类或模块应且只有一条加以修改的理由。
（系统应该有许多短小的类而不是少量巨大的类组成，每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同大学横期望的系统行为）
内聚：如果一个类中的每个变量被每个方法所使用，则该类具有最大的内聚性。
隔离修改：借助接口和抽象类来隔离细节的影响
部件解耦：部件之间的解耦代表着系统中的元素相隔离得很好。隔离会使得系统中的每个元素的理解变得更加容易。
第11章 系统
Ray Ozzie（微软公司首席技术官）：”复杂要人命。他消磨开发者的生命，让产品难以规划、构建和测试。“
系统与构造分开（软件系统应将启动过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应用对象，也会存在互相缠结的依赖关系）。
构造与使用分开的方法之一：将全部构造过程搬迁到main或被称之为main的模块中。
抽象工厂模式：让应用自行控制行为，但构造的细节隔离于应用程序代码之外。
依赖注入：分离构造与使用，控制反转（Inversion of Control，IoC）在依赖管理中的一种应用手段。
控制反转：将第二权责从对象中拿出来，转移到另一个专注于此的对象中，从而遵循了单一权责原则。
软件系统与物理系统可以类比。它们的架构都可以递增式地增长，只要我们持续将关注面切分。
：：最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯C++（或其他语言）对象来实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来：：
最佳：可工作的最简单方案
第12章 迭进
Kent Beck 的简单设计四条规则：@运行所有测试；@不可重复；@表达了程序员的意图；@尽可能减少类和方法的数量。
SRP的类；DIP规则
OO低耦合度、高内聚目标
代码重构：提升内聚性，降低耦合度
不可重复；小规模复用->大规模复用
保持函数和类短小的同时，保持系统短小精悍（尽可能少的类和方法）
第13章 并发编程
James O Coplien：“对象是过程的抽象。线程是调度的抽象”
并发：一种解耦策略
分离并发相关代码与其他代码；线程尽可能独立
生产者-消费者模型；读者-作者模型；宴席哲学家
使用一个共享对象的多个方法，3种手段：基于客户端的锁定；基于服务端的锁定；适配服务端
减小同步区域
伪失败；可工作；可插拔；可调整；超线程；多环境；强出错
第14章 逐步改进
草稿->整洁、漂亮修改的原则：保证系统原样工作
代码沼泽->命运失控
第15章 JUnit内幕
模块改进第16章 重构SerialDate
单元测试->覆盖图->测试覆盖率为何命名为某名字（SerialData）？
命名应该暗示一种相应层级的实现
第17章 味道与启发
注释：只应描述有关代码和设计的技术信息；字斟句酌。
环境：可测试
函数：个数少；参数少；无输出参数；无标识参数
边界：追索边界，编写测试
安全：不可忽视
层级：抽象类容纳较高层级，派生类容纳较低层级；较低层级概念放在派生类中，较高层级概念放在基类中。
隐藏数据；隐藏工具函数；隐藏常量；隐藏临时变量。
不要大量方法的类；不要大量实体变量的类；不要为子类创建大量受保护变量和类。
保持接口紧凑；利用限制信息控制耦合度。
不可人为耦合
用多态替代if/Else或Switch/Case
较高层级放置可配置数据
测试边界条件
测试快速