《Clean Code》读后感

代码维护一直是软件开发中比较重要的一块内容。尤其是需要多次开发，更新频繁的项目。如何保证项目团队保证高

 

效的生产力？保持代码Clean是一个有效的途径。看了Bob大叔的《Clean Code》，受益匪浅。里面详细地描述了Clean

 

Code的特征，从命名，到函数，到类，到系统。既抓出了一些常见的问题，也提供的很多解决方案。保持Code Clean，

 

并在团队中实施，是每个团队管理人员的责任。

 

我在这里就不多介绍了，只是摘录了一些片段，希望大家看后，能够去读读这本书。也欢迎一起谈论Clean Code

 

 

 

5S标准

Sort 分类排序，搞清楚事物之所在，通过恰当的命名

Systematize 系统化，每段代码都该在你希望的地方，否则，就该重构了

Shine 清理一些已经腐烂的代码，除之而后快

Standardization 标准化，一个team应该有一个代码标识，每个成员应该遵循

Self-discipline 自律 在实践中贯彻标准，并时时体现在个人工作上，要乐于改进

 

学写整洁代码很难。看完书只能是“感觉不错”。关键是形成一种意识，在日常工作中贯彻，每个类的命名，函数的定义，每个层次的抽象过程。

 

Later equals never。稍后等于永不。我们都曾经瞟一眼自己亲手造成的混乱，断言能运行的烂程序总比什么都没有强，我们都曾经说过有朝一日回头再清理

 

随着混乱的增加，团队的生产力也持续下降，趋向于0。生产力下降时，管理层就只有一件事可以做了，增加人手。《人月神话》中有详细描述这个项目管理的过程。新人不熟悉系统设计，通常会制造更多的混乱

 

推到重新设计

 

态度。一处小修改，却涉及到上百个模块。理由：产品需求违背了最初的设计，进度紧张，心情

 

混乱只会拖慢期限。赶上期限的唯一方法-始终保持代码的整洁

 

代码逻辑直截了当，缺陷无法隐藏，尽量减少依赖关系，使之便于维护，整洁的代码只做好一件事

 

整洁的代码从不隐藏设计者的意图

 

代码应该通过其字面表达含义

 

能够通过所有的测试，没有重复代码，体现系统中的全部设计理念，尽量少的实体（类、方法，函数）

 

童子军军规：让营地比你来时跟干净。每次签入，代码都比签出时干净。都是一些很微小的东西，改好一个变量名，拆分一个有点长的函数，消除一点点重复代码，清理一个嵌套的if语句

 

体现本意的名称 int d

 

避免误导 accountList 除非真的是List  l 1 和 0 O

 

做有意义的区分 x1，x2

Product 和 ProductInfo 和ProductData

getActiveAccount（） getActiveAccountInfo（）

 

使用读得出的名称，方便交流

 

使用可以搜索的名称 单字母和数字常量

 

成员前缀

 

避免思维映射

不应该让读者在脑中把你的名称翻译成他们熟知的名称。

 

类名 名词或者名词短语，避免使用Manager Processor Data Info等类名

 

方法名 动词或者动词短语

 

不要装清纯扮可爱，别人不一定有你的幽默和喜感，可能会误会你的意图

 

每个概念对应一个词，团队中最后有一个规范命名

 

别用双关语，add append

 

让人一目了然，让人觉得就应该是那样写

 

使用解决方案领域名称

 

问题域名称

 

添加有意义的语境，不要添加无意义的语境

 

短小

 

只做一件事

 

每个函数一个抽象层级

 

自顶向下写代码：向下规则

 

Switch 用多态代替

 

使用描述性的名称

别害怕长名字，别害怕花时间取名字

 

函数参数尽量少

 

标识参数是恶劣的

 

无副作用

 

输出参数

 

查询 与 操作 分离

 

使用异常代替返回错误

 

别重复自己 重复时软件中一切邪恶的根源

 

结构化编程 一个入口一个出口，只要保持短小，偶尔出现的return break或continue都没有坏处，goto就不要用了

 

如何写出clean 函数

一开始都是冗长而复杂的，有太多的缩进嵌套，有过长的参数列表，名称是随意取的，也会有重复代码

 

注释不能美化糟糕的代码

 

用代码来阐述

 

注释说明的是为什么这么做。做什么应该在代码中体现

 

多余的注释，误导性的注释，过时的注释，循规式，日志，废话，位置标识，括号后面的注释

注释掉的代码 html注释 信息过多 不明显的联系

 

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

类C的方法f只应该调用以下对象的方法

C，由f创建的对象，参数 c持有的对象

 

别传递null，别返回null

 

类应该尽量小，计算 权责

 

单一权责-只有一条修改的理由

 

内聚

 

保持内聚性会得到很多短小的类

 

为了修改而组织

运行所有的测试

不可重复

表达程序员的意图

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

 

If（）优于if（！）

多条件的，要放在一个函数里面说明

 

死函数，永远不被调用

 

基类依赖于派生类

 

--附件是我在团队中分享时用到的部分ppt