出版社: 人民邮电出版社
出品方: 异步图书
原作名: Clean Code: A Handbook of Agile Software Craftsmanship
译者: 韩磊
出版年: 2020-2
页数: 387
定价: 99.00元
装帧: 平装
丛书: 异步图书-程序员必读经典系列
ISBN: 9787115524133
内容简介 · · · · · ·
软件质量,不但依赖架构及项目管理,而且与代码质量紧密相关。这一点,无论是敏捷开发流派还是传统开发流派,都不得不承认。本书提出一种观点:代码质量与其整洁度成正比。干净的代码,既在质量上较为可靠,也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者,本书作者给出了一系列行之有效的整洁代码操作实践。这些实践在本书中体现为一条条规则(或称“启示”),并辅以来自实际项目的正、反两面的范例。只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量。
本书阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验,涵盖从命名到重构的多个编程方面,虽为一“家”之言,然诚有可资借鉴的价值。
作者简介 · · · · · ·
作者 | Robert C. Martin
世界级软件开发大师,设计模式和敏捷开发先驱,敏捷联盟首任主席,C++ Report前主编,被后辈程序员尊称为“Bob大叔”。20世纪70年代初成为职业程序员,后创办Object Mentor公司并任总裁。Martin还是一名多产的作家,至今已发表数百篇文章、论文和博客文章。除本书外,还著有《代码整洁之道:程序员的职业素养》《敏捷软件开发:原则、模式和实践》《UML:Java程序员指南》等。
译者 | 韩磊
互联网产品与社区运营专家,技术书籍著译者。曾任CSDN及《程序员》杂志副总经理、总编辑,广东二十一世纪传媒新媒体事业部总经理等职。现任AR初创企业亮风台广州公司总经理。除本书外,还译有《梦断代码》《C#编程风格》等书。与刘韧合著《网络媒体教程》,与戴飞合译《Beginning C# Objects中文版:...
作者 | Robert C. Martin
世界级软件开发大师,设计模式和敏捷开发先驱,敏捷联盟首任主席,C++ Report前主编,被后辈程序员尊称为“Bob大叔”。20世纪70年代初成为职业程序员,后创办Object Mentor公司并任总裁。Martin还是一名多产的作家,至今已发表数百篇文章、论文和博客文章。除本书外,还著有《代码整洁之道:程序员的职业素养》《敏捷软件开发:原则、模式和实践》《UML:Java程序员指南》等。
译者 | 韩磊
互联网产品与社区运营专家,技术书籍著译者。曾任CSDN及《程序员》杂志副总经理、总编辑,广东二十一世纪传媒新媒体事业部总经理等职。现任AR初创企业亮风台广州公司总经理。除本书外,还译有《梦断代码》《C#编程风格》等书。与刘韧合著《网络媒体教程》,与戴飞合译《Beginning C# Objects中文版:概念到代码》。
目录 · · · · · ·
1.1 要有代码 2
1.2 糟糕的代码 2
1.3 混乱的代价 3
1.3.1 华丽新设计 4
1.3.2 态度 4
1.3.3 谜题 5
1.3.4 整洁代码的艺术 5
1.3.5 什么是整洁代码 6
1.4 思想流派 10
1.5 我们是作者 11
1.6 童子军军规 12
1.7 前传与原则 12
1.8 小结 13
1.9 文献 13
第2章 有意义的命名 14
2.1 介绍 14
2.2 名副其实 15
2.3 避免误导 16
2.4 做有意义的区分 17
2.5 使用读得出来的名称 18
2.6 使用可搜索的名称 19
2.7 避免使用编码 20
2.7.1 匈牙利语标记法 20
2.7.2 成员前缀 21
2.7.3 接口和实现 21
2.8 避免思维映射 21
2.9 类名 22
2.10 方法名 22
2.11 别抖机灵 22
2.12 每个概念对应一个词 23
2.13 别用双关语 23
2.14 使用解决方案领域名称 24
2.15 使用源自所涉问题领域的名称 24
2.16 添加有意义的语境 24
2.17 不要添加没用的语境 26
2.18 最后的话 27
第3章 函数 28
3.1 短小 31
3.2 只做一件事 32
3.3 每个函数一个抽象层级 33
3.4 switch语句 34
3.5 使用具有描述性的名称 35
3.6 函数参数 36
3.6.1 单参数函数的普遍形式 37
3.6.2 标识参数 37
3.6.3 双参数函数 38
3.6.4 三参数函数 38
3.6.5 参数对象 39
3.6.6 参数列表 39
3.6.7 动词与关键字 39
3.7 无副作用 40
3.8 分隔指令与询问 41
3.9 使用异常替代返回错误码 42
3.9.1 抽离try/catch代码块 42
3.9.2 错误处理就是一件事 43
3.9.3 Error.java依赖磁铁 43
3.10 别重复自己 44
3.11 结构化编程 44
3.12 如何写出这样的函数 45
3.13 小结 45
3.14 SetupTeardownIncluder程序 45
3.15 文献 48
第4章 注释 49
4.1 注释不能美化糟糕的代码 50
4.2 用代码来阐述 51
4.3 好注释 51
4.3.1 法律信息 51
4.3.2 提供信息的注释 51
4.3.3 对意图的解释 52
4.3.4 阐释 53
4.3.5 警示 53
4.3.6 TODO注释 54
4.3.7 放大 55
4.3.8 公共API中的Javadoc 55
4.4 坏注释 55
4.4.1 喃喃自语 55
4.4.2 多余的注释 56
4.4.3 误导性注释 58
4.4.4 循规式注释 59
4.4.5 日志式注释 59
4.4.6 废话注释 60
4.4.7 可怕的废话 62
4.4.8 能用函数或变量时就别用注释 62
4.4.9 位置标记 62
4.4.10 括号后面的注释 63
4.4.11 归属与署名 63
4.4.12 注释掉的代码 64
4.4.13 HTML注释 64
4.4.14 非本地信息 65
4.4.15 信息过多 65
4.4.16 不明显的联系 66
4.4.17 函数头 66
4.4.18 非公共代码中的Javadoc 66
4.4.19 范例 66
4.5 文献 70
第5章 格式 71
5.1 格式的目的 72
5.2 垂直格式 72
5.2.1 向报纸学习 73
5.2.2 概念间垂直方向上的区隔 73
5.2.3 垂直方向上的靠近 74
5.2.4 垂直距离 75
5.2.5 垂直顺序 79
5.3 横向格式 80
5.3.1 水平方向上的区隔与靠近 81
5.3.2 水平对齐 82
5.3.3 缩进 83
5.3.4 空范围 84
5.4 团队规则 85
5.5 “鲍勃大叔”的格式规则 85
第6章 对象和数据结构 88
6.1 数据抽象 88
6.2 数据、对象的反对称性 90
6.3 得墨忒耳律 92
6.3.1 火车失事 92
6.3.2 混杂 93
6.3.3 隐藏结构 93
6.4 数据传送对象 94
6.5 小结 95
6.6 文献 96
第7章 错误处理 97
7.1 使用异常而非返回码 98
7.2 先写try-catch-finally语句 99
7.3 使用未检异常 100
7.4 给出异常发生的环境说明 101
7.5 依调用者需要定义异常类 101
7.6 定义常规流程 103
7.7 别返回null值 104
7.8 别传递null值 105
7.9 小结 106
7.10 文献 106
第8章 边界 107
8.1 使用第三方代码 108
8.2 浏览和学习边界 109
8.3 学习log4j 110
8.4 学习性测试的好处不只是免费 112
8.5 使用尚不存在的代码 112
8.6 整洁的边界 113
8.7 文献 114
第9章 单元测试 115
9.1 TDD三定律 116
9.2 保持测试整洁 117
9.3 整洁的测试 118
9.3.1 面向特定领域的测试语言 120
9.3.2 双重标准 121
9.4 每个测试一个断言 123
9.5 F.I.R.S.T. 125
9.6 小结 125
9.7 文献 126
第10章 类 127
10.1 类的组织 128
10.2 类应该短小 128
10.2.1 单一权责原则 130
10.2.2 内聚 131
10.2.3 保持内聚性就会得到许多短小的类 132
10.3 为了修改而组织 138
10.4 文献 141
第11章 系统 142
11.1 如何建造一个城市 143
11.2 将系统的构造与使用分开 143
11.2.1 分解main 144
11.2.2 工厂 145
11.2.3 依赖注入 145
11.3 扩容 146
11.4 Java代理 149
11.5 纯Java AOP框架 151
11.6 AspectJ的方面 154
11.7 测试驱动系统架构 154
11.8 优化决策 155
11.9 明智使用添加了可论证价值的标准 155
11.10 系统需要领域特定语言 156
11.11 小结 156
11.12 文献 156
第12章 迭进 158
12.1 通过迭进设计达到整洁目的 158
12.2 简单设计规则1:运行所有测试 159
12.3 简单设计规则2~4:重构 159
12.4 不可重复 160
12.5 表达力 162
12.6 尽可能少的类和方法 163
12.7 小结 163
12.8 文献 163
第13章 并发编程 164
13.1 为什么要并发 165
13.2 挑战 166
13.3 并发防御原则 167
13.3.1 单一权责原则 167
13.3.2 推论:限制数据作用域 167
13.3.3 推论:使用数据副本 168
13.3.4 推论:线程应尽可能地独立 168
13.4 了解Java库 168
13.5 了解执行模型 169
13.5.1 生产者-消费者模型 170
13.5.2 读者-作者模型 170
13.5.3 宴席哲学家 170
13.6 警惕同步方法之间的依赖 170
13.7 保持同步区域微小 171
13.8 很难编写正确的关闭代码 171
13.9 测试线程代码 172
13.9.1 将伪失败看作可能的线程问题 172
13.9.2 先使非线程代码可工作 172
13.9.3 编写可插拔的线程代码 173
13.9.4 编写可调整的线程代码 173
13.9.5 运行多于处理器数量的线程 173
13.9.6 在不同平台上运行 173
13.9.7 装置试错代码 174
13.9.8 硬编码 174
13.9.9 自动化 175
13.10 小结 176
13.11 文献 176
第14章 逐步改进 177
14.1 Args的实现 178
14.2 Args:草稿 185
14.2.1 所以我暂停了 196
14.2.2 渐进 197
14.3 字符串类型参数 199
14.4 小结 236
第15章 JUnit内幕 237
15.1 JUnit框架 238
15.2 小结 251
第16章 重构SerialDate 252
16.1 首先,让它能工作 253
16.2 让它做对 255
16.3 小结 268
16.4 文献 268
第17章 味道与启发 269
17.1 注释 270
17.2 环境 271
17.3 函数 271
17.4 一般性问题 272
17.5 Java 288
17.6 名称 291
17.7 测试 295
17.8 小结 296
17.9 文献 296
附录A 并发编程II 297
附录B org.jfree.date.SerialDate 326
结束语 388
· · · · · · (收起)
丛书信息
· · · · · ·
喜欢读"代码整洁之道"的人也喜欢的电子书 · · · · · ·
喜欢读"代码整洁之道"的人也喜欢 · · · · · ·
代码整洁之道的书评 · · · · · · ( 全部 59 条 )

规范的重要性---《Clean Code》读后感


又一本被过于抬高的普通之作
这篇书评可能有关键情节透露
总有一些书籍会被大家奉为经典, 也总有一些所谓的经典会让我失望, 不得不说, 代码整洁之道 就是其一. 这么说可能有些刻薄了, 毕竟代码整洁之道还是有些内容, 算是一本不错的书, 但是, 远远称不上经典. 写出更好的代码, 这应该是每个有追求的程序员永无止境的追求, 为写出更好... (展开)> 更多书评 59篇
论坛 · · · · · ·
在这本书的论坛里发言这本书的其他版本 · · · · · · ( 全部8 )
-
人民邮电出版社 (2010)8.6分 2236人读过
-
Prentice Hall (2008)8.9分 524人读过
-
人民邮电出版社 (2011)9.0分 136人读过
-
人民邮电出版社 (2009)8.2分 41人读过
以下书单推荐 · · · · · · ( 全部 )
- “Uncle Bob“的Clean系列(整洁之道) (旸谷)
- 技术提升 (BigWhiteCat)
- 书单|代码质量 (豆友DU2SgO31oM)
- 编程语言 (4Fires)
- 计算机 (astronaut)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
- 在豆瓣转让 有572人想读,手里有一本闲着?
订阅关于代码整洁之道的评论:
feed: rss 2.0
2 有用 SETH 2022-01-07 13:28:41
似乎专业到有些偏执了,但是这种工作态度值得肯定
0 有用 夜空守望者 2020-12-27 00:43:26
第二次读,感受又有不同
0 有用 戒慎恐惧 2022-03-06 06:44:57
编写易读的代码,有指导意义
0 有用 lightnine 2023-01-12 13:12:51 四川
一般般吧。可能是我之前读过相关内容的书籍
0 有用 雨夜赶路人 2022-08-01 12:35:30
感触良多,相见恨晚,看完觉得写代码可以写成艺术品。已买了英文版,打算再中英对照再看一遍。
0 有用 渔夫 2023-03-15 21:41:56 北京
并没有夸得那么神,罗列了很多Java代码,还是得先多写代码,多改自己的代码。
0 有用 浍钰 2023-03-15 18:05:30 北京
8-10章分别从如何调用第三方API和封装自己API的整洁性, 以及从保持UT代码整洁、如何组织类代码保持代码的可读性和可维护性; 11章,从系统架构设计及系统管理(AOP等手段)保持整个系统整体的整洁性; 12章,主要讲系统通过迭代的方式, 遵循简单设计原则不断重构,达到提升系统代码的整洁性; 13章,进阶级讲关于并发编码,并发的带来的代码维护性及debug的问题, 以及并发模式下的保持代码整洁... 8-10章分别从如何调用第三方API和封装自己API的整洁性, 以及从保持UT代码整洁、如何组织类代码保持代码的可读性和可维护性; 11章,从系统架构设计及系统管理(AOP等手段)保持整个系统整体的整洁性; 12章,主要讲系统通过迭代的方式, 遵循简单设计原则不断重构,达到提升系统代码的整洁性; 13章,进阶级讲关于并发编码,并发的带来的代码维护性及debug的问题, 以及并发模式下的保持代码整洁性开发指导和建议。 (展开)
0 有用 oskdk 2023-02-18 17:36:19 湖北
相当优秀的一本书。丰富的细节标准便于实操,同时也为“代码感”的形成提供了切实的框架。
0 有用 写字的心情 2023-01-28 21:39:39 北京
测试驱动开发。 我写函数时,一开始都冗长而复杂。有太多缩进和嵌套循环。有过长的参数列表。名称是随意取的,也会有重复的代码。不过我会配上一套单元测试,覆盖每行丑陋的代码。 整洁的测试有什么要素?有三个要素:可读性,可读性和可读性。在单元测试中,可读性甚至比在生产代码中还重要。测试如何才能做到可读?和其他代码中一样:明确,简洁,还有足够的表达力。 记住沃德原则:“如果每个例程都让你感到深合己意,... 测试驱动开发。 我写函数时,一开始都冗长而复杂。有太多缩进和嵌套循环。有过长的参数列表。名称是随意取的,也会有重复的代码。不过我会配上一套单元测试,覆盖每行丑陋的代码。 整洁的测试有什么要素?有三个要素:可读性,可读性和可读性。在单元测试中,可读性甚至比在生产代码中还重要。测试如何才能做到可读?和其他代码中一样:明确,简洁,还有足够的表达力。 记住沃德原则:“如果每个例程都让你感到深合己意,那就是整洁代码。” (展开)
0 有用 鵼人 2023-01-18 09:14:11 四川
入行的导师跟我说,他对代码的坏味道很敏感。事实上也是如此,早些时候在提交队列在中被打回的以及在代码评审中被直接指出来重构的代码非常多。我觉得相当麻烦。一件事非要拆成两件做。 一年半过去了,写了几万行代码。赶着年关前的空闲我看完了这本《Clean Code》。原来这里的clean不仅是形容词,还是动词。这种潜移默化去养成的习惯,让我不自觉地开始指出其他同事代码里坏味道的时候,我才知道自己终究还是变... 入行的导师跟我说,他对代码的坏味道很敏感。事实上也是如此,早些时候在提交队列在中被打回的以及在代码评审中被直接指出来重构的代码非常多。我觉得相当麻烦。一件事非要拆成两件做。 一年半过去了,写了几万行代码。赶着年关前的空闲我看完了这本《Clean Code》。原来这里的clean不仅是形容词,还是动词。这种潜移默化去养成的习惯,让我不自觉地开始指出其他同事代码里坏味道的时候,我才知道自己终究还是变成了自己当初“相当排斥”的样子。 作者马丁说:“对高瞻远瞩的练习业己结束,我要去清理自己的书桌了。” 习惯的改变还真的不知不觉。 (展开)