读书笔记——《clean code》

第一章 《整洁代码》

1. 什么是整洁代码？

*    代码逻辑直截了当，利于纠错

*    尽量减少依赖关系，便于维护

*    依据某种分层战略，处理异常

*    性能调节至最优化，防止混乱

整洁的代码只做好一件事情！

2. 简单代码特点：

*    能通过所有代码

*    没有重复代码

*    体现系统全部设计理念

*    包括尽量少的实体，如类，方法，函数等

（无重复代码、只做一件事情、表达力、小规模抽象等）

第二章    《有意义的命名》

命名规则：

1.名副其实

*    命名应该有足够的表达力，告诉你为什么会存在，做什么事情，该怎么用

2.避免误导

*    避免使用与本意相悖的命名

*    前后命名要一致，避免出现误导

3.做有意义的区分

*    要区分名称，就要以读者能鉴别不同之处的方式来区分

4.使用读得出来的名字

5.使用可搜索的名称

*    长名称胜于短名称

*    名称长短应与其作用域大小相对应

6.避免使用编码

*    把类型或者作用域编进名称里面，徒然增加了编码的负担

*    避免使用成员前缀

*    接口和实现尽量在实现类中加入Imp，而不是在接口前加入I

7.避免思维映射

*    不应该让读者在脑中把你的名称翻译为他们熟知的名称。明确即王道。

8.类名

*    类名和对象名应该是名词或名词短语，如Customer，Account，避免使用Manager，Data这样熟知的类名

9.方法名

*    方法名应该是动词或者动词短语

10.每个概念对应一个词

11.别用双关语

*    不同功能不使用同一个名称

12.使用解决方案领域的名称

13.使用源自所涉问题领域的名称

14.添加有意义的语境

15.不要添加没用的语境

取好名字最难的地方在于需要良好的描述技巧和共有文化背景。

第三章 《函数》

1.短小

*    函数代码应短小，代码行数应尽量小

*    函数的代码块和缩进不该多于一层或者两层、这样更利于阅读

2.只做一件事情

*    函数应该做一件事情，做好这件事情。只做这一件事情

3.每个函数一个抽象层级

*    要让代码拥有自顶而下的阅读顺序

4.switch语句

*    写出短小的switch语句很难，使用多态来实现

5.使用描述性的名称

*    别害怕长名称

*    别害怕花时间取名字

*    命名方式要一致

6.函数参数

*    最理想的参数数量是0，尽量避免3个以上的参数，这样还有利于测试

*    输出参数比输入参数更难以理解

*    尽量不要标识参数

*    当输入参数超过3个，就需要考虑封装成类对象

*    函数名动作后的名词尽量具体

7.无副作用

8.分隔指令与询问

9.使用异常替代返回错误码

*    最好将try/catch语句从代码块中抽离出来

*    错误处理就是一件事

*    Error类是一块依赖磁铁，使用异常替代错误码，新异常就可以从异常类派生出来

10.别重复自己

11.结构化编程

*    禁止出现goto语句，goto只在大函数中才有道理，应避免使用

12.如何写出这样的函数

*    重构

第四章    《注释》

如果编程语言足够有表达力，根本不需要注释

1.注释不能美化糟糕的代码

2.用代码来阐述

3.好注释

*    法律信息，如版权信息

*    提供信息的注释，但如果程序命名或者设计得当也可不需要

*    对意图解释的注释

*    阐释

*    警示

*    TODO注释

*    放大

*    公共API的javadoc

4.坏注释

*    喃喃自语

*    多余的注释

*    误导性注释

*    循规式注释

*    日志式注释

*    废话式注释

*    可怕的废话

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

*    位置标记

*    括号后的注释

*    归属与署名，源代码控制系统是这类信息最好的归属地

*    注释掉的代码

*    HTML注释

*    非本地信息

*    信息过多

*    不明显的联系

*    函数头

*    非公共代码中的javadoc

*    范例

第五章    《格式》

团队应该一致统一采用一套简单的格式规则

1.格式的目的

*    代码格式关乎沟通，而沟通是专业开发者的头等大事

2.垂直格式

*    像报纸学习，从上往下，有头条，第一段是故事的大纲，接着读下去，细节逐渐增加

*    概念间垂直方向向上的区隔，每行展现一个表达式或者句子，思路用空白行隔开

*    垂直方向上的靠近，靠近的代码暗示了之间的紧密关系

*    垂直距离，变量声明应尽可能靠近其使用位置，实体变量应该在类的顶部声明，相关函数应放置在一起，并调用者应该尽可能的放在被调用者上面，概念相关的代码应该放在一起

*    垂直顺序，被调用的函数应该放在执行函数下面

3.横向格式

*    使用空格字符将相关性较弱的事物隔开

*    水平不一定要完全对齐

*    缩进

*    注意空范围的缩进

4.团队规则

*    使用统一的规则

第六章    《对象和数据结构》

1.数据抽象

*    暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体

2.数据，对象的反对称性

*    对象与数据结构之间的二分原理：过程式代码便于在不改动既有数据结构的前提下添加新的函数，二面向对象代码便于在不改动既有函数的前提下添加新类

3.得墨忒耳律

*    模块不应了解它所操作对象的内部情形

*    方法不应调用任何函数返回的对象方法，不要使用链式编写代码（火车失事）

4.数据传送对象

*    最为精炼的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或OTO。

第七章    《错误处理》

错误处理很重要，但如果它搞乱了代码逻辑，那就是错误的做法。

1.使用异常而非返回码

2.先写Try-Catch-Finally语句

3.使用不可控异常

4.给出异常发生的环境说明

5.依调用者需要定义异常类

6.定义常规流程

7.别返回null值

8.别传递null值

第八章    《边界》

1.使用第三方代码

2.浏览和学习边界

*    不要在生产代码中试验新东西，而是编写测试来遍览和理解第三方代码（学习性测试）

3.学习log4j

4.学习性测试的好处不仅仅是免费

*    编写测试则是获得这些知识的容易二不会影响其他工作的途径

5.使用尚不存在的代码

6.整洁的边界

第九章    《单元测试》

1.TDD三定律

*    在编写不能通过的单元测试前，不可编写生产代码

*    只可编写刚好无法通过的单元测试，不能编译也算不通过

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

2.保持测试整洁

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

3.整洁的测试

*    可读性：明确，简洁，有足够的表达力

4.每个测试一个断言

5.F.I.R.S.T

*    快速Fast：测试应该够快

*    独立Independent：测试应该相互独立

*    可重复Repeatable：测试应当在任何花姐重复通过

*    自我验证Self-Validating：测试应该有布尔值输出

*    及时Timely：测试应及时编写

第十章    《类》

1.类的组织

*    类应该具有封装性

2.类应该短小

*    类或者模块应有且只有一条加以修改的理由

*    系统应该由许多短小的类而不是少量巨大的类组成

*    类应该只有少量实体变量

*    保持内聚性就会得到许多短小的类

3.为了修改而组织

*    类应该对扩展开放，对修改封闭

第十一章    《系统》

1.如何建造一个城市（抽象层级——系统层级）

2.将系统的构造与使用分开

*    分解main

*    工厂

*    依赖注入

3.扩容

4.JAVA代理

5.纯JAVA AOP框架

6.AspectJ的方面

7.测试驱动系统架构

*    没必要先做大设计

8.优化策略

*    延迟策略至最后一刻也是好手段

9.明智使用添加了可论证价值的标准

10.系统需要领域特定语言

第十二章    《迭代》

1.通过迭进设计达到整洁目的

*    运行所有测试

*    不可重复

*    表达了程序员的意图

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

2.简单设计规则1：运行所有测试

3.简单设计规则2：重构

4.不可重复

5.表达力

6.尽可能少的类和方法

第十三章 《并发编程》

1.为什么要并发

• 帮助我们把做什么和何时做分解开
• 并发总能改进性能
• 编写并发程序无需修改设计
• 在采用Web或EJB容器的时候，理解并发问题并不重要

2.挑战

• 并发会引起数据安全性问题

3.并发防御原则

• 单一权责原则：并发相关代码有子的开发，修改和调优生命周期，开发相关代码有自己要对付的挑战，和非并发相关代码不同
• 限制数据作用域
• 会用数据副本：有额外的开销
• 线程应尽可能独立

4.了解java库

• 使用类库提供的线程安全群集
• 使用executor框架执行无关任务
• 尽可能使用非锁定解决方案
• 有几个类并非线程安全

5.了解执行模型

• 生产者-消费者模式
• 读者-作者模型
• 宴席哲学家

6.警惕同步方法之间的依赖

7.保持同步区域微小

8.很难编写正确的关闭代码

9.测试线程代码

• 将伪失败看作可能的线程问题
• 先使非线程代码可工作
• 编写可插拔的线程代码
• 编写可调整的线程代码
• 运行多于处理器数量的线程
• 在不同平台运行
• 装置试错代码
• 硬编码
• 自动化

0人点赞

日记本