第一章 整洁代码

赶上期限的唯一方法:始终尽可能保持代码整洁。

整洁的代码只做好一件事。

整本书的主旨,不要重复代码,只做一件事,表达力,小规模抽象。

要想干得快,要想快点做完,要想轻松写代码,先让代码易读吧。

让每次签入时,代码都比签出时干净。

第二章,有意义的命名

1、名副其实

如果名称需要注释来补充,那就不算是名副其实。

2、避免误导

别用xxxList来指称一组账号,除非它真的是List类型。(用xxxGroup/bunchOfxxx/xxxs代替更好)

3、做有意义的区分

不要使用数字区分变量/函数命名。如a1,a2,…

不要添加废话区分命名。如:ProductInfo和ProductData

4、使用读得出来的名称

比如日期:用generationTimestamp,而不要使用genymdhms。

5、使用可搜索的名称

单字母和数字常量很难搜出。使用宏或者变量命名这类数据。

6、避免使用编码

不必用前缀表示成员变量。

7、避免思维映射

8、类名

类名和对象应该是名词或名词短语。

9、方法名

方法名应该是动词或动词短语。

10、别扮可爱

11、每个概念对应一个词

12、别用双关语

避免将同一个单词用于不同目的。

13、使用解决方案领域名称

尽可能使用IT类术语

14、使用源自所涉问题领域的名称

15、使用有意义的语境

如:使用addrState代替state

16、不要添加没用的语境

如:不要用GSD代替GasStationDeluxe这样类似的短语。

第三章 函数

函数的第一规则是要短小,第二规则是还要更短小。

函数的缩进层数不该多于一层或两层。

函数应该做一件事,做好这件事,只做这一件事。

要判断函数是否不止做了一件事,看是否能再拆出一个函数,该函数不仅是单纯地重新诠释其实现。

函数参数,最理想的参数是0,其次是1,再次是2.尽量避免3个。有足够特殊的理由才能用3个以上函数。

如果函数看起来需要两个,三个或三个以上参数,就说明其中一些参数应该封装成类了。

函数不应有副作用,如,检查密码的函数不应该有初始化Session的步骤。

把指令和询问分隔开来。

别重复自己。

如何做到:先想些什么就写什么,然后再打磨它。

第四章 注释

注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。

注释会撒谎,因为修改代码后并不会让注释随之变动。

注释不会美化糟糕的代码。

与其花时间美化代码,不如花时间清洁代码。

好注释:

1、法律信息

2、提供信息的注释

3、对意图的注释

4、阐释

5、警示

6、TODO

7、放大:放大某种看起来不合理之物的重要性

8、公共API中的javadoc

坏注释:

1、喃喃自语

2、多余的注释

3、误导性注释

4、循规式注释

5、日志式注释

6、废话注释

7、可怕的废话

8、能用函数或变量时就别用注释

9、位置标记

10、括号后面的注释

11、归属和署名

12、注释掉的代码(别这么干)

13、html注释

14、非本地信息

15、信息过多

16、不明显的联系

17、函数头

18、非公共代码中的javadoc

第五章 格式

代码格式很重要,关乎沟通。

实体变量应该在类的顶部声明。

相关函数。若某个函数调用了另一个,就应该把它们放到一起。而且调用着应该尽可能放在被调用着上面。

四则运算时,运算级较高的符号可以不用空格隔开。

每个程序员都有自己喜欢的格式规则,但如果在一个团队中工作,就是团队说了算。

第六章 对象和数据结构

隐藏实现并非只是变量之间放上一个函数层那么简单。隐藏实现关乎抽象。类并不简单地用取值器和赋值器将变量推向外间,而是暴露抽象接口,以便用户无需了解数据的实现便能操作数据本体。

要以最好的方式呈现某个对象包含的数据,需要做严肃的思考。

过程式代码便于在不改动既有函数的前提下添加新类。

得墨耳律:模块不应了解它所操作对象的内部情形。

例如:类C的f方法只应调用以下对象的方法:

C 由f创建的对象

由C的实体变量持有的对象

即:方法不应调用由任何函数返回的对象的方法。

第七章 错误处理

使用异常而非返回码。 先写try、catch、finally语句

使用不可控异常

给出异常发生的环境说明。

应创建信息充分的错误信息,并和异常一起传递出去。在消息中,包括失败的操作和失败的类型。如果你的应用程序由日志系统,传递足够的信息给catch块,并记录下来。

依调用者需要定义异常类。

定义常规流程。

别返回null值。

别传递null值。

第九章 单元测试

TDD三定律

1、在编写不能通过的单元测试前,不可编写生产代码。

2、只可编写刚好无法通过的单元测试,不能编译也不算通过。

3、只可编写刚好足以通过当前失败测试的生产代码。

保持测试整洁。

脏测试等同于没测试。

测试代码和生产代码一样重要。

整洁的测试三要素:可读性,可读性和可读性。

每个测试一个断言。

每个测试只测试一个概念。

F.I.R.S.T.

Fast(快速)、Independent(独立)、Repeatable(可重复)、Self-Validating(自足验证)、Timely(及时)

第十章 类

类应该短小。

用权责衡量类的大小。

如果无法为某个类命以精确的名称,这个类大概太长了。

SRP,单一权责原则,类或模块应有且只有一条加以修改的理由。

系统应该有许多短小的类而不是少量巨大的类组成。每个小雷封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为。

内聚:如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性。

第十一章 系统

将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中,设计系统的其他部分时,假设所有对象都已正确构造和设置。

使用工厂方法,让程序负责确定何时创建对象。

AOP 切面编程

第十二章 迭进

简单设计四条规则:

运行所有测试;

不可重复;

表达了程序员的意图;

尽可能减少类和方法的数量。

极其雷同的代码就是重复。

要想实现大规模复用,必须理解如何实现小规模复用。

模板方法模式是一种移除高层级重复的通用技巧

第十三章 并发编程

对象是过程的抽象,线程是调度的抽象。

并发是一种解耦策略,帮助我们把做什么(目的)和何时(时间)做分解开。

并发会在性能和编写额外代码上增加一些开销。

正确的并发是复杂的,即便对于简单的问题也是如此。

并发缺陷并非总能重现,所以常被看做偶发事件而忽略,未被当作真的缺陷对待。

并发常常需要对设计策略的根本性修改。

并发防御原则:

1、SRP,分离并发相关代码和其他代码。

2、推论:限制数据作用域。

3、推论:使用数据复本,避免共享数据的好方法之一就是一开始就避免共享数据。

4、推论:线程应尽可能独立。尝试将数据分解到可独立线程(可能在不同处理器上)操作的独立子集。

并发执行模型

生产者-消费者

读者-作者

宴席哲学家

学习这些基础算法,理解其解决方案。

在你认为自己完成某个函数之前,确认自己理解了它是怎么工作的。通过全部测试还不够好。你必须知道解决方案是正确的。获得这种知识和理解的最好途径,往往是重构函数,得到某种整洁而足具表达力、清楚呈示如何工作的东西。

用多态替代If/Else或Switch/Case

总结

看了这本书,得到了很多新的指导,建议。这确实是一本好书,作者表达很清晰,说明白了该怎么做。虽然知道了,但是还是得要根据当中的理论多去实践才能体会当中的精髓。

分享到: 微信 更多