出版社: 人民邮电出版社
出品方: 异步图书
原作名: 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
· · · · · · (收起)
丛书信息
喜欢读"代码整洁之道"的人也喜欢的电子书 · · · · · ·
喜欢读"代码整洁之道"的人也喜欢 · · · · · ·
代码整洁之道的书评 · · · · · · ( 全部 56 条 )

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


又一本被过于抬高的普通之作
这篇书评可能有关键情节透露
总有一些书籍会被大家奉为经典, 也总有一些所谓的经典会让我失望, 不得不说, 代码整洁之道 就是其一. 这么说可能有些刻薄了, 毕竟代码整洁之道还是有些内容, 算是一本不错的书, 但是, 远远称不上经典. 写出更好的代码, 这应该是每个有追求的程序员永无止境的追求, 为写出更好... (展开)> 更多书评 56篇
-
选择这本书的时候,我其实内心还是有些矛盾之处,关键原因是自己并不是一个专业程序员,甚至说编程爱好者都有些难承其重。所以这本书我能从中有什么收获让我还是很不安。 收到这本书之后,内心是由小兴奋小激动逐渐变为✌️自己的选择是对的大满足,变成快速浏览之后的心有戚戚收获颇丰之感,而这一切的变化只是来自于第一章内容的阅读。 当然这本书的读者还是需要和编程搭界,远如我这样的IT从业人员都能从中拾得吉光片羽...
2022-06-18 09:10:35 1人喜欢
选择这本书的时候,我其实内心还是有些矛盾之处,关键原因是自己并不是一个专业程序员,甚至说编程爱好者都有些难承其重。所以这本书我能从中有什么收获让我还是很不安。
收到这本书之后,内心是由小兴奋小激动逐渐变为✌️自己的选择是对的大满足,变成快速浏览之后的心有戚戚收获颇丰之感,而这一切的变化只是来自于第一章内容的阅读。
当然这本书的读者还是需要和编程搭界,远如我这样的IT从业人员都能从中拾得吉光片羽,那些以编程为生的从业人员更应该能收获颇丰,因为我们可以从这里看到具体的示例来告诉我们写代码的规则、方法、思路、还有理念或者信念。但是这一切来的并不是那么教条和死板,作为作家Bob大叔行文有趣语言活泼风趣,所以读起来并不让人有觉得枯燥无味读而却步。
总结而言,这本书可以反复阅读,读者可以是编程小白,业内大佬,或者八杆子才能打到的IT从业人员。 阅读目的,可以简单从“术”的层面获得具体指导,或是从“道”的层面来俯视写代码这件事,甚至大而扩至自己的工作自己的人生如何能够“简洁”-- 此为本笔记的标题由来。
按照自己目前的读书做笔记的习惯,呈现一下本书章节和部分金句,以供他人管中窥豹。
章节目录我们永远无法放弃必要的精确性----所以代码永存。 引自 1.1 要有代码 2 Later equals never. 引自 1.2 糟糕的代码 2 多数经理想要知道实情,即便他们看起来不喜欢实情。多数经理想要好代码,即便他们他们总是纠缠于进度。 引自 1.3.2 态度 4 写整洁代码,需要遵循大量的小技巧,贯彻刻苦习得的“整洁感”。这种“代码感”就是关键所在。 引自 1.3.4 整洁代码的艺术 5 整洁代码总是看起来像是某位特别在意它的人写的.....赞叹某人留给你的代码---全心投入的某人留下的代码。 引自 1.3.5 什么是整洁代码 6 光把代码写好可不够。必须时时保持代码整洁。 引自 1.6 童子军军规 12 回应 2022-06-18 09:10:35 -
我的思考: 好的命名 编码规范 持续重构 设计思想、设计原则、设计模式 第 2 章:有意义的命名 名副其实; 使用可搜索的名称,名称长短应与其作用域大小相对应; 第 3 章:函数 短小、只做一件事; 每个函数一个抽象层级; 使用描述性的名称; 使用异常替代返回错误码; 抽离 try catch 代码块; 第 4 章:注释 提供信息; 解释意图; 警示; 第 5 章:格式 垂直格式; 横向格式;
2022-07-01 00:43:23
-
你的代码在哪道门后面?你的团队或公司在哪道门后面?为什么会在那里?只是一次普通的代码评审。还是产品面世后才发现一连串严重问题?我们是否在战战兢兢地调试自己错以为没问题的代码?客户是否在流失?经理们是否把我们盯得如芒刺在背?当事态变得严重起来时,如何保证我们在那道正确的门后做补救工作?答案是:技艺(craftsmanship)。 习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对...
2022-06-23 16:41:47
(经Thom Holwerda允许复制上图)你的代码在哪道门后面?你的团队或公司在哪道门后面?为什么会在那里?只是一次普通的代码评审。还是产品面世后才发现一连串严重问题?我们是否在战战兢兢地调试自己错以为没问题的代码?客户是否在流失?经理们是否把我们盯得如芒刺在背?当事态变得严重起来时,如何保证我们在那道正确的门后做补救工作?答案是:技艺(craftsmanship)。
习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对其了如指掌,通过刻苦实践掌握它。
我可以教你骑自行车的物理学原理。实际上,经典数学的表达方式相对而言确实简洁明了。重力、摩擦力、角动量、质心等,用一页写满方程式的纸就能说明白。有了这些方程式,我可以为你证明出骑车完全可行,而且还可以告诉你骑车所需的全部知识。即便如此,你在初次骑车时还是会跌倒在地。
编码亦同此理。我们可以写下整洁代码的所有“感觉良好”的原则,放手让你去干(换言之,让你从自行车上摔下来)。那样的话,我们算是哪门子老师?而你又会成为怎样的学生呢?
不!本书可不会这么做。
学写整洁代码很难。它可不止于要求你掌握原则和模式,你得在这上面花工夫。你须自行实践,且体验自己的失败。你须观察他人的实践与失败。你须看看别人是怎样蹒跚学步,再转头研究他们的路数。你须看看别人是如何绞尽脑汁做出决策,又是如何为错误决策付出代价的。
阅读本书要多用心思。这可不是那种降落前就能读完的“感觉不错”的“飞机书”。本书要让你用功,而且是非常用功。如何用功?阅读代码-——大量代码。而且你要去琢磨某段代码好在什么地方,坏在什么地方。在我们分解然后组合模块时,你得亦步亦趋地跟上。这会花些工夫,不过值得一试。 本书大致可分为3个部分。第一部分介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码,读起来颇具挑战性。读完这几章,就为阅读第二部分做好了准备。如果你就此止步,只能祝你好运啦!
第二部分最需要花工夫,这部分包括几个复杂性不断增加的案例研究,每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码,琢磨每次修改的来龙去脉。
你付出的劳动将在第三部分得到回报。这部分只有一章,列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时,我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应,尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。
如果你在阅读第二部分的案例研究时没有好好用功,那么这套知识库对你来说可能所值无几。在这些案例研究中,每次修改都仔细注明了相关启示的标号。这些标号用方括号标出,如[H22]。由此你可以看到这些启示在何种环境下被应用和编写。启示本身没有价值,启示与案例研究中清理代码的具体决策之间的关系才有价值。
如果你跳过案例研究部分,只阅读了第一部分和第三部分,那就不过是又看了一本关于写出好软件的“感觉不错”的书。但如果你肯花时间琢磨那些案例,亦步亦趋——站在作者的角度,迫使自己以作者的思维路径考虑问题,就能更深刻地理解这些原则、模式、实践和启示。这样的话,就像一个人熟练地掌握了骑车的技术后,自行车就如同其身体的延伸部分那样:对你来说,本书所介绍的整洁代码的原则,模式,实践和启示就成为你本身具有的技艺,而不再是“感觉不错”的知识。
回应 2022-06-23 16:41:47 -
月光捕手王亮 (你吃菠萝的同时,)
7.2 先写 try-catch-finally 语句 有人说,JavaScript的异常捕获机制很耗性能,所以尽量不要使用它。那么事实上确实如此,在ECMAScript规范中,异常处理需要把当前的context和作用域全部分别添加到catch和finally块里(上古时代甚至jser甚至利用这个机制创建局部变量),所以它一定是有性能损耗的。但是,现代浏览器其实针对try-catch-finally做了相当多的性能优化,我在chorme下实测用与不用try-catch基本是无感知的,上千次才...2022-05-29 18:41:52
7.2 先写 try-catch-finally 语句 引自 第7章 错误处理 97 有人说,JavaScript的异常捕获机制很耗性能,所以尽量不要使用它。那么事实上确实如此,在ECMAScript规范中,异常处理需要把当前的context和作用域全部分别添加到catch和finally块里(上古时代甚至jser甚至利用这个机制创建局部变量),所以它一定是有性能损耗的。但是,现代浏览器其实针对try-catch-finally做了相当多的性能优化,我在chorme下实测用与不用try-catch基本是无感知的,上千次才有毫秒级的差异。所以,该用就用吧。
那么什么时候该用呢?作者也说了“错误处理固然重要,但如果它搞乱了代码逻辑就是错误的做法”。好用不代表滥用。对于异常捕获,红宝书上的观点是“自己无法控制的代码才需要try-catch”。以我的经验来说,异步最好加上异常捕获,因为你不知道接口会不会给你返回null。另外就是第三方库提供的API,如果我们对它不够熟悉那最好也加上异常捕获。
你抛出的每个异常,都应当提供足够的环境说明,以便判断错误的来源和位置。 引自 7.4 给出异常发生的环境说明 101 在JavaScript代码、尤其是所谓业务代码中,我确实很少见到主动抛出异常的情况,更别提自定义错误类型了。这是非常正常的现象,我个人认为,最好在应用的底层库或者工具方法来抛出异常。举例来说,一个json校验器方法,其参数如果不是json那就可以抛出异常,并携带上模块、方法、异常原因等详细数据便于调用方去定位、调试、修复。
在方法中返回null值是糟糕的做法,将null值传递给其他方法就更糟糕了。 引自 7.8 别传递null值 105 据(我个人)统计,JavaScript中最常见的错误类型当属ReferenceError和TypeError。而null值是造成这俩异常的重要原因。所以,不要在方法里返回null或者undefined,除非这个方法真的只有你自己在用、并且null或undefined在你的代码里有业务意义(真有这么扯的场景我也认了)。
BTW,已经将这一条加入我的CR check list 并且置顶了。
回应 2022-05-29 18:41:52
-
我的思考: 好的命名 编码规范 持续重构 设计思想、设计原则、设计模式 第 2 章:有意义的命名 名副其实; 使用可搜索的名称,名称长短应与其作用域大小相对应; 第 3 章:函数 短小、只做一件事; 每个函数一个抽象层级; 使用描述性的名称; 使用异常替代返回错误码; 抽离 try catch 代码块; 第 4 章:注释 提供信息; 解释意图; 警示; 第 5 章:格式 垂直格式; 横向格式;
2022-07-01 00:43:23
-
你的代码在哪道门后面?你的团队或公司在哪道门后面?为什么会在那里?只是一次普通的代码评审。还是产品面世后才发现一连串严重问题?我们是否在战战兢兢地调试自己错以为没问题的代码?客户是否在流失?经理们是否把我们盯得如芒刺在背?当事态变得严重起来时,如何保证我们在那道正确的门后做补救工作?答案是:技艺(craftsmanship)。 习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对...
2022-06-23 16:41:47
(经Thom Holwerda允许复制上图)你的代码在哪道门后面?你的团队或公司在哪道门后面?为什么会在那里?只是一次普通的代码评审。还是产品面世后才发现一连串严重问题?我们是否在战战兢兢地调试自己错以为没问题的代码?客户是否在流失?经理们是否把我们盯得如芒刺在背?当事态变得严重起来时,如何保证我们在那道正确的门后做补救工作?答案是:技艺(craftsmanship)。
习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对其了如指掌,通过刻苦实践掌握它。
我可以教你骑自行车的物理学原理。实际上,经典数学的表达方式相对而言确实简洁明了。重力、摩擦力、角动量、质心等,用一页写满方程式的纸就能说明白。有了这些方程式,我可以为你证明出骑车完全可行,而且还可以告诉你骑车所需的全部知识。即便如此,你在初次骑车时还是会跌倒在地。
编码亦同此理。我们可以写下整洁代码的所有“感觉良好”的原则,放手让你去干(换言之,让你从自行车上摔下来)。那样的话,我们算是哪门子老师?而你又会成为怎样的学生呢?
不!本书可不会这么做。
学写整洁代码很难。它可不止于要求你掌握原则和模式,你得在这上面花工夫。你须自行实践,且体验自己的失败。你须观察他人的实践与失败。你须看看别人是怎样蹒跚学步,再转头研究他们的路数。你须看看别人是如何绞尽脑汁做出决策,又是如何为错误决策付出代价的。
阅读本书要多用心思。这可不是那种降落前就能读完的“感觉不错”的“飞机书”。本书要让你用功,而且是非常用功。如何用功?阅读代码-——大量代码。而且你要去琢磨某段代码好在什么地方,坏在什么地方。在我们分解然后组合模块时,你得亦步亦趋地跟上。这会花些工夫,不过值得一试。 本书大致可分为3个部分。第一部分介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码,读起来颇具挑战性。读完这几章,就为阅读第二部分做好了准备。如果你就此止步,只能祝你好运啦!
第二部分最需要花工夫,这部分包括几个复杂性不断增加的案例研究,每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码,琢磨每次修改的来龙去脉。
你付出的劳动将在第三部分得到回报。这部分只有一章,列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时,我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应,尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。
如果你在阅读第二部分的案例研究时没有好好用功,那么这套知识库对你来说可能所值无几。在这些案例研究中,每次修改都仔细注明了相关启示的标号。这些标号用方括号标出,如[H22]。由此你可以看到这些启示在何种环境下被应用和编写。启示本身没有价值,启示与案例研究中清理代码的具体决策之间的关系才有价值。
如果你跳过案例研究部分,只阅读了第一部分和第三部分,那就不过是又看了一本关于写出好软件的“感觉不错”的书。但如果你肯花时间琢磨那些案例,亦步亦趋——站在作者的角度,迫使自己以作者的思维路径考虑问题,就能更深刻地理解这些原则、模式、实践和启示。这样的话,就像一个人熟练地掌握了骑车的技术后,自行车就如同其身体的延伸部分那样:对你来说,本书所介绍的整洁代码的原则,模式,实践和启示就成为你本身具有的技艺,而不再是“感觉不错”的知识。
回应 2022-06-23 16:41:47 -
选择这本书的时候,我其实内心还是有些矛盾之处,关键原因是自己并不是一个专业程序员,甚至说编程爱好者都有些难承其重。所以这本书我能从中有什么收获让我还是很不安。 收到这本书之后,内心是由小兴奋小激动逐渐变为✌️自己的选择是对的大满足,变成快速浏览之后的心有戚戚收获颇丰之感,而这一切的变化只是来自于第一章内容的阅读。 当然这本书的读者还是需要和编程搭界,远如我这样的IT从业人员都能从中拾得吉光片羽...
2022-06-18 09:10:35 1人喜欢
选择这本书的时候,我其实内心还是有些矛盾之处,关键原因是自己并不是一个专业程序员,甚至说编程爱好者都有些难承其重。所以这本书我能从中有什么收获让我还是很不安。
收到这本书之后,内心是由小兴奋小激动逐渐变为✌️自己的选择是对的大满足,变成快速浏览之后的心有戚戚收获颇丰之感,而这一切的变化只是来自于第一章内容的阅读。
当然这本书的读者还是需要和编程搭界,远如我这样的IT从业人员都能从中拾得吉光片羽,那些以编程为生的从业人员更应该能收获颇丰,因为我们可以从这里看到具体的示例来告诉我们写代码的规则、方法、思路、还有理念或者信念。但是这一切来的并不是那么教条和死板,作为作家Bob大叔行文有趣语言活泼风趣,所以读起来并不让人有觉得枯燥无味读而却步。
总结而言,这本书可以反复阅读,读者可以是编程小白,业内大佬,或者八杆子才能打到的IT从业人员。 阅读目的,可以简单从“术”的层面获得具体指导,或是从“道”的层面来俯视写代码这件事,甚至大而扩至自己的工作自己的人生如何能够“简洁”-- 此为本笔记的标题由来。
按照自己目前的读书做笔记的习惯,呈现一下本书章节和部分金句,以供他人管中窥豹。
章节目录我们永远无法放弃必要的精确性----所以代码永存。 引自 1.1 要有代码 2 Later equals never. 引自 1.2 糟糕的代码 2 多数经理想要知道实情,即便他们看起来不喜欢实情。多数经理想要好代码,即便他们他们总是纠缠于进度。 引自 1.3.2 态度 4 写整洁代码,需要遵循大量的小技巧,贯彻刻苦习得的“整洁感”。这种“代码感”就是关键所在。 引自 1.3.4 整洁代码的艺术 5 整洁代码总是看起来像是某位特别在意它的人写的.....赞叹某人留给你的代码---全心投入的某人留下的代码。 引自 1.3.5 什么是整洁代码 6 光把代码写好可不够。必须时时保持代码整洁。 引自 1.6 童子军军规 12 回应 2022-06-18 09:10:35 -
月光捕手王亮 (你吃菠萝的同时,)
7.2 先写 try-catch-finally 语句 有人说,JavaScript的异常捕获机制很耗性能,所以尽量不要使用它。那么事实上确实如此,在ECMAScript规范中,异常处理需要把当前的context和作用域全部分别添加到catch和finally块里(上古时代甚至jser甚至利用这个机制创建局部变量),所以它一定是有性能损耗的。但是,现代浏览器其实针对try-catch-finally做了相当多的性能优化,我在chorme下实测用与不用try-catch基本是无感知的,上千次才...2022-05-29 18:41:52
7.2 先写 try-catch-finally 语句 引自 第7章 错误处理 97 有人说,JavaScript的异常捕获机制很耗性能,所以尽量不要使用它。那么事实上确实如此,在ECMAScript规范中,异常处理需要把当前的context和作用域全部分别添加到catch和finally块里(上古时代甚至jser甚至利用这个机制创建局部变量),所以它一定是有性能损耗的。但是,现代浏览器其实针对try-catch-finally做了相当多的性能优化,我在chorme下实测用与不用try-catch基本是无感知的,上千次才有毫秒级的差异。所以,该用就用吧。
那么什么时候该用呢?作者也说了“错误处理固然重要,但如果它搞乱了代码逻辑就是错误的做法”。好用不代表滥用。对于异常捕获,红宝书上的观点是“自己无法控制的代码才需要try-catch”。以我的经验来说,异步最好加上异常捕获,因为你不知道接口会不会给你返回null。另外就是第三方库提供的API,如果我们对它不够熟悉那最好也加上异常捕获。
你抛出的每个异常,都应当提供足够的环境说明,以便判断错误的来源和位置。 引自 7.4 给出异常发生的环境说明 101 在JavaScript代码、尤其是所谓业务代码中,我确实很少见到主动抛出异常的情况,更别提自定义错误类型了。这是非常正常的现象,我个人认为,最好在应用的底层库或者工具方法来抛出异常。举例来说,一个json校验器方法,其参数如果不是json那就可以抛出异常,并携带上模块、方法、异常原因等详细数据便于调用方去定位、调试、修复。
在方法中返回null值是糟糕的做法,将null值传递给其他方法就更糟糕了。 引自 7.8 别传递null值 105 据(我个人)统计,JavaScript中最常见的错误类型当属ReferenceError和TypeError。而null值是造成这俩异常的重要原因。所以,不要在方法里返回null或者undefined,除非这个方法真的只有你自己在用、并且null或undefined在你的代码里有业务意义(真有这么扯的场景我也认了)。
BTW,已经将这一条加入我的CR check list 并且置顶了。
回应 2022-05-29 18:41:52
-
我的思考: 好的命名 编码规范 持续重构 设计思想、设计原则、设计模式 第 2 章:有意义的命名 名副其实; 使用可搜索的名称,名称长短应与其作用域大小相对应; 第 3 章:函数 短小、只做一件事; 每个函数一个抽象层级; 使用描述性的名称; 使用异常替代返回错误码; 抽离 try catch 代码块; 第 4 章:注释 提供信息; 解释意图; 警示; 第 5 章:格式 垂直格式; 横向格式;
2022-07-01 00:43:23
-
你的代码在哪道门后面?你的团队或公司在哪道门后面?为什么会在那里?只是一次普通的代码评审。还是产品面世后才发现一连串严重问题?我们是否在战战兢兢地调试自己错以为没问题的代码?客户是否在流失?经理们是否把我们盯得如芒刺在背?当事态变得严重起来时,如何保证我们在那道正确的门后做补救工作?答案是:技艺(craftsmanship)。 习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对...
2022-06-23 16:41:47
(经Thom Holwerda允许复制上图)你的代码在哪道门后面?你的团队或公司在哪道门后面?为什么会在那里?只是一次普通的代码评审。还是产品面世后才发现一连串严重问题?我们是否在战战兢兢地调试自己错以为没问题的代码?客户是否在流失?经理们是否把我们盯得如芒刺在背?当事态变得严重起来时,如何保证我们在那道正确的门后做补救工作?答案是:技艺(craftsmanship)。
习艺之要有二:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且要对其了如指掌,通过刻苦实践掌握它。
我可以教你骑自行车的物理学原理。实际上,经典数学的表达方式相对而言确实简洁明了。重力、摩擦力、角动量、质心等,用一页写满方程式的纸就能说明白。有了这些方程式,我可以为你证明出骑车完全可行,而且还可以告诉你骑车所需的全部知识。即便如此,你在初次骑车时还是会跌倒在地。
编码亦同此理。我们可以写下整洁代码的所有“感觉良好”的原则,放手让你去干(换言之,让你从自行车上摔下来)。那样的话,我们算是哪门子老师?而你又会成为怎样的学生呢?
不!本书可不会这么做。
学写整洁代码很难。它可不止于要求你掌握原则和模式,你得在这上面花工夫。你须自行实践,且体验自己的失败。你须观察他人的实践与失败。你须看看别人是怎样蹒跚学步,再转头研究他们的路数。你须看看别人是如何绞尽脑汁做出决策,又是如何为错误决策付出代价的。
阅读本书要多用心思。这可不是那种降落前就能读完的“感觉不错”的“飞机书”。本书要让你用功,而且是非常用功。如何用功?阅读代码-——大量代码。而且你要去琢磨某段代码好在什么地方,坏在什么地方。在我们分解然后组合模块时,你得亦步亦趋地跟上。这会花些工夫,不过值得一试。 本书大致可分为3个部分。第一部分介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码,读起来颇具挑战性。读完这几章,就为阅读第二部分做好了准备。如果你就此止步,只能祝你好运啦!
第二部分最需要花工夫,这部分包括几个复杂性不断增加的案例研究,每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码,琢磨每次修改的来龙去脉。
你付出的劳动将在第三部分得到回报。这部分只有一章,列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时,我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应,尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。
如果你在阅读第二部分的案例研究时没有好好用功,那么这套知识库对你来说可能所值无几。在这些案例研究中,每次修改都仔细注明了相关启示的标号。这些标号用方括号标出,如[H22]。由此你可以看到这些启示在何种环境下被应用和编写。启示本身没有价值,启示与案例研究中清理代码的具体决策之间的关系才有价值。
如果你跳过案例研究部分,只阅读了第一部分和第三部分,那就不过是又看了一本关于写出好软件的“感觉不错”的书。但如果你肯花时间琢磨那些案例,亦步亦趋——站在作者的角度,迫使自己以作者的思维路径考虑问题,就能更深刻地理解这些原则、模式、实践和启示。这样的话,就像一个人熟练地掌握了骑车的技术后,自行车就如同其身体的延伸部分那样:对你来说,本书所介绍的整洁代码的原则,模式,实践和启示就成为你本身具有的技艺,而不再是“感觉不错”的知识。
回应 2022-06-23 16:41:47 -
选择这本书的时候,我其实内心还是有些矛盾之处,关键原因是自己并不是一个专业程序员,甚至说编程爱好者都有些难承其重。所以这本书我能从中有什么收获让我还是很不安。 收到这本书之后,内心是由小兴奋小激动逐渐变为✌️自己的选择是对的大满足,变成快速浏览之后的心有戚戚收获颇丰之感,而这一切的变化只是来自于第一章内容的阅读。 当然这本书的读者还是需要和编程搭界,远如我这样的IT从业人员都能从中拾得吉光片羽...
2022-06-18 09:10:35 1人喜欢
选择这本书的时候,我其实内心还是有些矛盾之处,关键原因是自己并不是一个专业程序员,甚至说编程爱好者都有些难承其重。所以这本书我能从中有什么收获让我还是很不安。
收到这本书之后,内心是由小兴奋小激动逐渐变为✌️自己的选择是对的大满足,变成快速浏览之后的心有戚戚收获颇丰之感,而这一切的变化只是来自于第一章内容的阅读。
当然这本书的读者还是需要和编程搭界,远如我这样的IT从业人员都能从中拾得吉光片羽,那些以编程为生的从业人员更应该能收获颇丰,因为我们可以从这里看到具体的示例来告诉我们写代码的规则、方法、思路、还有理念或者信念。但是这一切来的并不是那么教条和死板,作为作家Bob大叔行文有趣语言活泼风趣,所以读起来并不让人有觉得枯燥无味读而却步。
总结而言,这本书可以反复阅读,读者可以是编程小白,业内大佬,或者八杆子才能打到的IT从业人员。 阅读目的,可以简单从“术”的层面获得具体指导,或是从“道”的层面来俯视写代码这件事,甚至大而扩至自己的工作自己的人生如何能够“简洁”-- 此为本笔记的标题由来。
按照自己目前的读书做笔记的习惯,呈现一下本书章节和部分金句,以供他人管中窥豹。
章节目录我们永远无法放弃必要的精确性----所以代码永存。 引自 1.1 要有代码 2 Later equals never. 引自 1.2 糟糕的代码 2 多数经理想要知道实情,即便他们看起来不喜欢实情。多数经理想要好代码,即便他们他们总是纠缠于进度。 引自 1.3.2 态度 4 写整洁代码,需要遵循大量的小技巧,贯彻刻苦习得的“整洁感”。这种“代码感”就是关键所在。 引自 1.3.4 整洁代码的艺术 5 整洁代码总是看起来像是某位特别在意它的人写的.....赞叹某人留给你的代码---全心投入的某人留下的代码。 引自 1.3.5 什么是整洁代码 6 光把代码写好可不够。必须时时保持代码整洁。 引自 1.6 童子军军规 12 回应 2022-06-18 09:10:35 -
月光捕手王亮 (你吃菠萝的同时,)
7.2 先写 try-catch-finally 语句 有人说,JavaScript的异常捕获机制很耗性能,所以尽量不要使用它。那么事实上确实如此,在ECMAScript规范中,异常处理需要把当前的context和作用域全部分别添加到catch和finally块里(上古时代甚至jser甚至利用这个机制创建局部变量),所以它一定是有性能损耗的。但是,现代浏览器其实针对try-catch-finally做了相当多的性能优化,我在chorme下实测用与不用try-catch基本是无感知的,上千次才...2022-05-29 18:41:52
7.2 先写 try-catch-finally 语句 引自 第7章 错误处理 97 有人说,JavaScript的异常捕获机制很耗性能,所以尽量不要使用它。那么事实上确实如此,在ECMAScript规范中,异常处理需要把当前的context和作用域全部分别添加到catch和finally块里(上古时代甚至jser甚至利用这个机制创建局部变量),所以它一定是有性能损耗的。但是,现代浏览器其实针对try-catch-finally做了相当多的性能优化,我在chorme下实测用与不用try-catch基本是无感知的,上千次才有毫秒级的差异。所以,该用就用吧。
那么什么时候该用呢?作者也说了“错误处理固然重要,但如果它搞乱了代码逻辑就是错误的做法”。好用不代表滥用。对于异常捕获,红宝书上的观点是“自己无法控制的代码才需要try-catch”。以我的经验来说,异步最好加上异常捕获,因为你不知道接口会不会给你返回null。另外就是第三方库提供的API,如果我们对它不够熟悉那最好也加上异常捕获。
你抛出的每个异常,都应当提供足够的环境说明,以便判断错误的来源和位置。 引自 7.4 给出异常发生的环境说明 101 在JavaScript代码、尤其是所谓业务代码中,我确实很少见到主动抛出异常的情况,更别提自定义错误类型了。这是非常正常的现象,我个人认为,最好在应用的底层库或者工具方法来抛出异常。举例来说,一个json校验器方法,其参数如果不是json那就可以抛出异常,并携带上模块、方法、异常原因等详细数据便于调用方去定位、调试、修复。
在方法中返回null值是糟糕的做法,将null值传递给其他方法就更糟糕了。 引自 7.8 别传递null值 105 据(我个人)统计,JavaScript中最常见的错误类型当属ReferenceError和TypeError。而null值是造成这俩异常的重要原因。所以,不要在方法里返回null或者undefined,除非这个方法真的只有你自己在用、并且null或undefined在你的代码里有业务意义(真有这么扯的场景我也认了)。
BTW,已经将这一条加入我的CR check list 并且置顶了。
回应 2022-05-29 18:41:52
当前版本有售 · · · · · ·
-
限时抢
这本书的其他版本 · · · · · · ( 全部8 )
-
人民邮电出版社 (2010)8.6分 2178人读过
-
Prentice Hall (2008)8.9分 510人读过
-
人民邮电出版社 (2011)9.1分 131人读过
-
人民邮电出版社 (2009)8.2分 41人读过
以下书单推荐 · · · · · · ( 全部 )
- “Uncle Bob“的Clean系列(整洁之道) (旸谷)
- 专业 (Imagine Dragons)
- java书籍 (胡锐杰)
- 软件工程 (Ausfuhrung)
- 我的书单 (会划水的鱼)
谁读这本书?
二手市场
订阅关于代码整洁之道的评论:
feed: rss 2.0
0 有用 SETH 2022-01-07 13:28:41
似乎专业到有些偏执了,但是这种工作态度值得肯定
0 有用 飞天小懒猫 2021-07-21 21:40:28
我一直觉得代码是一种艺术,即便最终得出的结果没什么区别,艺术也是需要美的
0 有用 没有折角的书 2021-06-10 23:27:04
为啥第一板评分那么高,我感觉我读了个寂寞。读到十章,读不下去了。可能我太菜了吧,有点不适合我。
0 有用 馬老山深 2022-05-16 15:04:39
代码简洁,同时易读易维护可拓展,都是学问,也是艺术。
0 有用 异步君 2022-07-01 15:10:03
这本书可是经典中的经典,很多博主推荐,适合刚入门的程序员必读书籍,里面讲了很多简化,如何写出优美的代码的方法,对比下来自己以前写的代码简直太差......好的代码质量才能体现扎实的基本功,才能构建健壮的系统,好好学一下吧!
0 有用 异步君 2022-07-01 15:10:03
这本书可是经典中的经典,很多博主推荐,适合刚入门的程序员必读书籍,里面讲了很多简化,如何写出优美的代码的方法,对比下来自己以前写的代码简直太差......好的代码质量才能体现扎实的基本功,才能构建健壮的系统,好好学一下吧!
0 有用 喜欢雨夜 2022-05-29 16:37:32
其实在写了两三年代码后,才可看或者可以理解的层次,如何写更好的代码? 这里的好,不只是编写可以正常运行解决功能的代码,而是更容易让其他人读懂的代码 有些人把写代码比作写文章,其实写代码就是写文章。也就是在你学会了用一个编程语言表达之后,如何超越自己的境界,写的更漂亮。以此来证明你的能力和境界。 其实书的名字也就代表了一个核心内涵,整洁,有太多同学的代码写的可以运行,但是乱七八糟。因此整洁可以作为第... 其实在写了两三年代码后,才可看或者可以理解的层次,如何写更好的代码? 这里的好,不只是编写可以正常运行解决功能的代码,而是更容易让其他人读懂的代码 有些人把写代码比作写文章,其实写代码就是写文章。也就是在你学会了用一个编程语言表达之后,如何超越自己的境界,写的更漂亮。以此来证明你的能力和境界。 其实书的名字也就代表了一个核心内涵,整洁,有太多同学的代码写的可以运行,但是乱七八糟。因此整洁可以作为第一的杀手锏。 当然,在此基础上,还有很多经验和技巧可以采用,其实这些也是在看其他人的好代码的过程中或者自己思考如何写的更好中潜移默化会形成的技巧和习惯。 不要把重构想的那么神圣,当然也不要嗤之以鼻。 尊重代码,尊重用心整理代码的人。 遵守童子军原则,不要让你的改动让整个代码更乱,事情要做漂亮! (展开)
0 有用 馬老山深 2022-05-16 15:04:39
代码简洁,同时易读易维护可拓展,都是学问,也是艺术。
0 有用 江上书月生 2022-05-15 15:27:10
游戏开发
0 有用 Mext 2022-05-01 17:18:04
珍爱生命,拥抱代码整洁,远离屎山。