第一章：
1.混乱的代码难以维护，导致生产力越来越低。糟糕的代码引发混乱，越改越烂。
2.整洁的代码：优雅，高效，少依赖，性能优，命名规范，清晰尽量少的api
3.破窗理论：窗户破损的建筑让人觉得无人照管，于是别人也无心看管，任其继续破损，最终自己也参加破坏活动。
第二章 有意义的命名
1.使用可搜索的名称
2.避免编码,避免把类型作用域编进名称：消除成员前缀m_,接口前缀I
3.类名应该是名词，名词短语，不能是动词
4.方法名是动词，动词短语，get set is前缀
5.别用双关语言，一个命名表示一种行为。比如add方法，增加一个元素到列表就不要在用add,使用insert,append
第三章 函数
1.短小，只做好一件事，函数中保持同一抽象层级
2.使用异常代替返回错误码
第五章 格式
第六章 对象和数据结构
1.二分原理：过程式代码（使用数据结构的代码）便于在不改变数据结构的前提下添加函数，面向对象的代码便于在
不改变既有函数的前提下添加新类。
第七章 错误处理
1.别返回null，返回特例对象，能够统一处理
第八章 边界
1.使用尚不存在的代码，编写我们想要的接口，再使用适配器
第九章 单元测试
1.TDD三定律
2.测试代码要和生产代码一样整洁。测试代码和生产代码一样的重要。
3.每个测试一个断言：每个测试函数只测试一个概念。
4.F.I.R.S.T：快速(Fast) 测试应该够快、 独立(Independent) 测试之间应该相互独立、可重复(Repeatable) 测试应该可在任何环境重复通过、自足验证(Self-validating) 测试应该有布尔值输出 、及时(Timely) 测试应及时编写
第十章 类
1.类应该短小，单一权责。系统应有许多短小的类而不是少量巨大的类组成。
2.一个类的每个变量都被每个方法所以，内聚越高。类越短小，内聚越高，不然就该拆分
第十二章 迭进
简单设计的四条规则
1.运行所有测试，使系统如预期般工作。测试消除了对清理代码就会破坏代码的恐惧
2.不可重复
3.表达程序员的意图，好的命名，良好的测试起到文档的作用
4.尽可能少的类和方法
第十三章 并发
对象是过程的抽象，线程是调度的抽象。 ----
并发防御原则：
1.限制数据作用域，谨记封装，严格限制共享
2.使用数据副本，最后在单线程中合并
3.线程尽可能独立，减少数据共享和同步需求
建议:
1.偶发错误看作可能是线程问题
2.编写可插拔的线程代码,在不同配置环境下运行
3.编写可调整的线程代码，线程数可调
4.插入试错代码：硬编码，自动化