#每日一书#
6.21 程序员修炼之道
程序员修炼之道
第一版,我都忘了是什么时候读的。大概10多年前吧,第二版云风翻译的,纠正了不少第一版的错误翻译。
这本书值得所有程序员读,特别是需要自我提升的程序员。以前公众号也写过这本书的内容,我放下链接。
1. 投资与编程——低买高卖 mp.weixin.qq.com
2. 投资与编程——定期投资 mp.weixin.qq.com
3. 投资与编程——多样化mp.weixin.qq.com
4. 投资与编程——风险管理 mp.weixin.qq.com
5. 投资与编程——重新评估 mp.weixin.qq.com
这本书主要就是100个tips,是分类讲解的,包括很多内容,像编程语言,debug技巧,软件工程中的很多东西,算法,架构,沟通技巧各种程序员在自我提升道路上会遇到的问题。
我把100个提示列在下面,你需要的是找本书读完它, 找另外的书来扩展它。
提示1:关注你的技艺
如果你不关心怎么做好,为什么还要花时间去开发软件呢?
提示2:思考!思考你的工作
关掉辅助驾驶,由自己掌控,持续不断地评估所做的工作。
提示3:你有权选择
人生是自己的。把握住人生,让它如你所愿。
提示4:提供选择,别找借口
提供选择而不是去找理由。不要只说做不到;解释一下都能做些什么。
提示5:不要放任破窗 7
只要看到不好的设计、错误的决策、糟糕的代码,就赶紧去纠正。
提示6:做推动变革的催化剂 10
你无法强迫人们去改变,但可以展示美好未来,并帮助他们参与创造。
提示7:牢记全景 10
不要过度沉浸于细枝末节,以免察觉不到周围正在发生的事情。
提示8:将质量要求视为需求问题 12
让用户参与对项目真实质量需求的确定。
提示9:对知识组合做定期投资
养成学习的习惯。
提示10:批判性地分析你读到和听到的东西
不要受供应商、媒体炒作或教条的影响,根据自身和项目的实际情况来分析信息。
提示11:英语就是另一门编程语言
将英语视作一门编程语言。写文档和编程一样要遵循 DRY 原则、ETC、自动化等。
提示12:说什么和怎么说同样重要
如果无法有效交流,任何伟大的想法都是没有意义的。
提示13:把文档嵌进去,而不要栓在表面
与代码隔离的文档,很难保持正确并及时更新。
提示14:优秀的设计比糟糕的设计更容易变更 28
适合使用者的事物,都已经过良好设计。对代码来说,这意味着必须适应变化。
提示15:DRY——不要重复自己
系统中的每一条知识,都必须有单一且无歧义的权威陈述。
提示16:让复用变得更容易
只要复用方便,人们就会去做。创建一个支持复用的环境。
提示17:消除不相关事物之间的影响 41
设计的组件,需要自成一体、独立自主,有单一的清晰定义的意图。
提示18:不设最终决定 50
不要把决定刻在石头上,而要将其视为写在沙滩上的东西,时刻准备应变。
提示19:放弃追逐时尚
尼尔·福特说过:“昨日之最佳实践,即明日之反模式。”要基于基本原则去选择架构,而不应盲从于流行。
提示20:使用曳光弹找到目标 53
通过不断尝试并看清着弹点,曳光弹可确保你最终击中目标。
提示21:用原型学习 58
制作原型旨在学习经验,其价值不在于过程中产生的代码,而在于得到的教训。
提示22:靠近问题域编程 61
用问题领域的语言来做设计和编程。
提示23:通过估算来避免意外 67
开始之前做估算,能提前发现潜在问题。
提示24:根据代码不断迭代进度表 72
利用实施过程中获得的经验来精细化项目的时间尺度。
提示25:将知识用纯文本保存 76
纯文本不会过时。它能够让你的工作事半功倍,并能简化调试和测试工作。
提示26:发挥 Shell 命令的威力 80
当图形化界面无法胜任时,使用 Shell。
提示27:游刃有余地使用编辑器 82
既然编辑器是至关重要的工具,不妨了解一下如何用它更快更准确地实现需求。
提示28:永远使用版本控制 87
版本控制为你的工作创造了一个时间机器,可以用它重返过去。
提示29:去解决问题,而不是责备 91
Bug 到底来自你的失误还是别人的失误真的不重要——它终究是你的问题,需要你来修复。
提示30:不要恐慌 91
不管是对银河系搭车客,还是对开发者来说,都应这样。
提示31:修代码前先让代码在测试中失败 93
在你修 Bug 前,先创建一个聚焦于该 Bug 的测试。
提示32:读一下那些该死的出错信息 93
大多数异常都能告诉失败之物与失败之处。如果足够幸运,你甚至能得到具体的参数值。
提示33:“select”没出问题 97
在操作系统或编译器中发现 Bug 非常罕见,甚至在第三方产品或库中也是如此。Bug 大多出现在应用程序中。
提示34:不要假设,要证明 97
在真实环境中证实你的假设——要依赖真实的数据及边界条件。
提示35:学习一门文本处理语言 99
既然每天都要花大量的时间与文本打交道,何不让计算机帮你分担一二?
提示36:你无法写出完美的软件 103
软件不可能是完美的。对于在所难免的错误,要保护代码和用户免受其影响。
提示37:通过契约进行设计 107
代码是否不多不少刚好完成它宣称要做的事情,可以使用契约加以校验和文档化。
提示38:尽早崩溃 114
彻底死掉的程序通常比有缺陷的程序造成的损害要小。
提示39:使用断言去预防不可能的事情 115
如果一件事情不可能发生,那么就用断言来确保其的确不会发生。断言在校验你的假设,要使用断言在不确定的世界中将你的代码保护起来。
提示40:有始有终 119
只要有可能,对资源进行分配的函数或对象就有责任去释放该资源。
提示41:在局部行动 122
将易变的变量维持在一个范围内,打开资源的过程要短暂且明显可见。
提示42:小步前进——由始至终 127
永远小步前进,不断检查反馈,并且在推进前先做调整。
提示43:避免占卜 129
只在你能看到的范围内做计划。
提示44:解耦代码让改变更容易 132
耦合使事物紧紧绑定在一起,以至于很难只改变其中之一。
提示45:只管命令不要询问 133
不要从对象中取出值,在加以变换后再塞回去,让对象自己来完成这些工作。
提示46:不要链式调用方法 135
当访问某事物时,使用的点号不要超过一个。
提示47:避免全局数据 137
最好给每个方法增加一个额外的参数。
提示48:如果全局唯一非常重要,那么将它包装到API 中 137
……但是,仅限于你真的非常希望它是全局的。
提示49:编程讲的是代码,而程序谈的是数据 151
所有的程序都在变换数据——将输入转换为输出。开始用变换式方法来设计吧!
提示50:不要囤积状态,传递下去 156
不要把数据保持在函数或模块的内部,拿出来传递下去。
提示51:不要付继承税 165
考虑一下能更好满足需求的替代方案,比如接口、委托或mixin。
提示52:尽量用接口来表达多态 167
无需继承引入的耦合,接口就能明确描述多态性。
提示53:用委托提供服务:“有一个”胜过“是一个” 167
不要从服务中继承,应该包含服务。
提示54:利用 mixin 共享功能 169
mixin 不必承担继承税就可以给类添加功能,而与接口结合可以让多态不再令人痛苦。
提示55:使用外部配置参数化应用程序 170
如果代码对一些在应用程序发布后还有可能改变的值有所依赖,那么就在应用外部维护这些值。
提示56:通过分析工作流来提高并发性 176
利用用户工作流中的并发性。
提示57:共享状态是不正确的状态 180
共享状态会带来无穷的麻烦,而且往往只有重启才能解决。
提示58:随机故障通常是并发问题 186
或许时间和上下文的变化能暴露并发Bug,但并发Bug无法始终保持一致,也很难重现。
提示59:用角色实现并发性时不必共享状态 188
使用角色来管理并发状态,可以避免显式的同步。
提示60:使用黑板来协调工作流 195
使用黑板来协调不相关的事实和代理人,能同时保持参与者之间的独立性和孤立性。
提示61:倾听你内心的蜥蜴 201
当编程举步维艰时,其实是潜意识在告诉你有什么地方不对劲。
提示62:不要依赖巧合编程 207
只能依赖可靠的事物。注意偶然事件的复杂性,不要混淆快乐的巧合与有目的的计划。
提示63:评估算法的级别 214
在开始编程前,对这件事情大概会花多长时间要有概念。
提示64:对估算做测试 214
针对算法的数学分析无法说明所有问题,尝试在目标环境中测试一下执行代码的耗时。
提示65:尽早重构,经常重构 219
像除草和翻整花园那样,只要有需要就对代码进行重新编写、修订和架构,以便找到问题的根源并加以修复。
提示66:测试与找 Bug 无关 221
测试是观察代码的一个视角,可以从中得到针对设计、接口和耦合度的反馈。
提示67:测试是代码的第一个用户 222
用测试的反馈来引导工作。
提示68:既非自上而下,也不自下而上,基于端对端构建 225
创建一小块端到端的功能,从中获悉问题之所在。
提示69:为测试做设计 228
写下代码之前先从测试角度思考。
提示70:要对软件做测试,否则只能留给用户去做 230
无情地测试,不要等用户来帮你找 Bug。
提示71:使用基于特性的测试来校验假设 231
基于特性的测试将会进行你从未想过的尝试,并会以你不曾打算采用的方式操练你的代码。
提示72:保持代码简洁,让攻击面最小 241
复杂的代码给 Bug 以滋生之沃土,给攻击者以可趁之机。
提示73:尽早打上安全补丁 243
攻击者会尽可能快地部署攻击,你必须快上加快。
提示74:好好取名;需要时更名 249
用名字向读者表达你的意图,并且在意图改变时及时更名。
提示75:无人确切知道自己想要什么 252
他们或许知道大概的方向,但不会了解过程的曲折。
提示76:程序员帮助人们理解他们想要什么 253
软件开发更像是一种由用户和程序员协同创造的行为。
提示77:需求是从反馈循环中学到的 254
理解需求需要探索和反馈,因此决策的结果可以用来完善最初的想法。
提示78:和用户一起工作以便从用户角度思考 255
这是看透系统将如何被真正使用的最佳方法。
提示79:策略即元数据 256
不要将策略硬编码进系统,而应该将其表达为系统的一组元数据。
提示80:使用项目术语表 259
为项目的所有特定词汇创建一张术语表,并且在单一源头维护。
提示81:不要跳出框框思考——找到框框 261
在面对无法解决的难题时,识别出真正的约束。可以问自己:“必须这样做才能搞定吗?必须搞定它吗?”
提示82:不要一个人埋头钻进代码中 267
编程往往困难又费力,找个朋友和你一起干。
提示83:敏捷不是一个名词;敏捷有关你如何做事 267
敏捷是一个形容词,有关如何做事情。
提示84:维持小而稳定的团队 272
团队应保持稳定、小巧,团队中的每个人都应相互信任、互相依赖。
提示85:排上日程以待其成 274
如果你不把事情纳入日程表,它们就不会发生。反思、实验、学习、提高技能,这些事都应放入日程表。
提示86:组织全功能的团队 276
围绕功能而不是工作职能组织团队。不要将 UI/UX 设计者从程序员中分离出去,也不要分开前端和后端;不要区分数据建模者和测试人员,以及开发和设计。构建一个团队,这样你就可以渐进地不断迭代端到端的代码。
提示87:做能起作用的事,别赶时髦 279
不要仅仅因为别的公司正在那么干就采纳一项技术或采用一个开发方法,而是要采用自己所处环境中对团队有效的东西。
提示88:在用户需要时交付 281
不要卡着流程要求,刻意等到几周甚至几个月后才交付。
提示89:使用版本控制来驱动构建、测试和发布 282
利用提交或推送来触发构建、测试、发布,利用版本控制的标签来进行生产部署。
提示90:尽早测试,经常测试,自动测试 283
每次构建都跑一下的测试,要比束之高阁的测试计划有效得多。
提示91:直到所有的测试都已运行,编码才算完成 283
无须多言。
提示92:使用破坏者检测你的测试 285
在一个单独的源码副本中特意引入 Bug,验证测试能否将其捕获。
提示93:测试状态覆盖率,而非代码覆盖率 286
要识别并测试重要的程序状态,只测试一行行的代码是不够的。
提示94:每个 Bug 只找一次 286
只要人类测试者找到一个 Bug ,就应该是该 Bug 最后一次被人类发现。从此之后,自动化测试完全可以发现它。
提示95:不要使用手动程序 287
计算机能一次又一次,按照同样的次序,执行相同的指令。
提示96:取悦用户,而不要只是交付代码 289
为用户开发能够带来商业价值的解决方案,并让他们每天都感到愉快。
提示97:在作品上签名 290
过去的工匠在为他们的作品签名时非常自豪,你也应该这样。
提示98:先勿伤害 293
犯错在所难免,确保犯错后没人会因此受难。
提示99:不要助纣为虐 294
因为这样做你也有变成纣王的风险。
提示100: 你要为自己的人生做主。
6.21 程序员修炼之道
程序员修炼之道
第一版,我都忘了是什么时候读的。大概10多年前吧,第二版云风翻译的,纠正了不少第一版的错误翻译。
这本书值得所有程序员读,特别是需要自我提升的程序员。以前公众号也写过这本书的内容,我放下链接。
1. 投资与编程——低买高卖 mp.weixin.qq.com
2. 投资与编程——定期投资 mp.weixin.qq.com
3. 投资与编程——多样化mp.weixin.qq.com
4. 投资与编程——风险管理 mp.weixin.qq.com
5. 投资与编程——重新评估 mp.weixin.qq.com
这本书主要就是100个tips,是分类讲解的,包括很多内容,像编程语言,debug技巧,软件工程中的很多东西,算法,架构,沟通技巧各种程序员在自我提升道路上会遇到的问题。
我把100个提示列在下面,你需要的是找本书读完它, 找另外的书来扩展它。
提示1:关注你的技艺
如果你不关心怎么做好,为什么还要花时间去开发软件呢?
提示2:思考!思考你的工作
关掉辅助驾驶,由自己掌控,持续不断地评估所做的工作。
提示3:你有权选择
人生是自己的。把握住人生,让它如你所愿。
提示4:提供选择,别找借口
提供选择而不是去找理由。不要只说做不到;解释一下都能做些什么。
提示5:不要放任破窗 7
只要看到不好的设计、错误的决策、糟糕的代码,就赶紧去纠正。
提示6:做推动变革的催化剂 10
你无法强迫人们去改变,但可以展示美好未来,并帮助他们参与创造。
提示7:牢记全景 10
不要过度沉浸于细枝末节,以免察觉不到周围正在发生的事情。
提示8:将质量要求视为需求问题 12
让用户参与对项目真实质量需求的确定。
提示9:对知识组合做定期投资
养成学习的习惯。
提示10:批判性地分析你读到和听到的东西
不要受供应商、媒体炒作或教条的影响,根据自身和项目的实际情况来分析信息。
提示11:英语就是另一门编程语言
将英语视作一门编程语言。写文档和编程一样要遵循 DRY 原则、ETC、自动化等。
提示12:说什么和怎么说同样重要
如果无法有效交流,任何伟大的想法都是没有意义的。
提示13:把文档嵌进去,而不要栓在表面
与代码隔离的文档,很难保持正确并及时更新。
提示14:优秀的设计比糟糕的设计更容易变更 28
适合使用者的事物,都已经过良好设计。对代码来说,这意味着必须适应变化。
提示15:DRY——不要重复自己
系统中的每一条知识,都必须有单一且无歧义的权威陈述。
提示16:让复用变得更容易
只要复用方便,人们就会去做。创建一个支持复用的环境。
提示17:消除不相关事物之间的影响 41
设计的组件,需要自成一体、独立自主,有单一的清晰定义的意图。
提示18:不设最终决定 50
不要把决定刻在石头上,而要将其视为写在沙滩上的东西,时刻准备应变。
提示19:放弃追逐时尚
尼尔·福特说过:“昨日之最佳实践,即明日之反模式。”要基于基本原则去选择架构,而不应盲从于流行。
提示20:使用曳光弹找到目标 53
通过不断尝试并看清着弹点,曳光弹可确保你最终击中目标。
提示21:用原型学习 58
制作原型旨在学习经验,其价值不在于过程中产生的代码,而在于得到的教训。
提示22:靠近问题域编程 61
用问题领域的语言来做设计和编程。
提示23:通过估算来避免意外 67
开始之前做估算,能提前发现潜在问题。
提示24:根据代码不断迭代进度表 72
利用实施过程中获得的经验来精细化项目的时间尺度。
提示25:将知识用纯文本保存 76
纯文本不会过时。它能够让你的工作事半功倍,并能简化调试和测试工作。
提示26:发挥 Shell 命令的威力 80
当图形化界面无法胜任时,使用 Shell。
提示27:游刃有余地使用编辑器 82
既然编辑器是至关重要的工具,不妨了解一下如何用它更快更准确地实现需求。
提示28:永远使用版本控制 87
版本控制为你的工作创造了一个时间机器,可以用它重返过去。
提示29:去解决问题,而不是责备 91
Bug 到底来自你的失误还是别人的失误真的不重要——它终究是你的问题,需要你来修复。
提示30:不要恐慌 91
不管是对银河系搭车客,还是对开发者来说,都应这样。
提示31:修代码前先让代码在测试中失败 93
在你修 Bug 前,先创建一个聚焦于该 Bug 的测试。
提示32:读一下那些该死的出错信息 93
大多数异常都能告诉失败之物与失败之处。如果足够幸运,你甚至能得到具体的参数值。
提示33:“select”没出问题 97
在操作系统或编译器中发现 Bug 非常罕见,甚至在第三方产品或库中也是如此。Bug 大多出现在应用程序中。
提示34:不要假设,要证明 97
在真实环境中证实你的假设——要依赖真实的数据及边界条件。
提示35:学习一门文本处理语言 99
既然每天都要花大量的时间与文本打交道,何不让计算机帮你分担一二?
提示36:你无法写出完美的软件 103
软件不可能是完美的。对于在所难免的错误,要保护代码和用户免受其影响。
提示37:通过契约进行设计 107
代码是否不多不少刚好完成它宣称要做的事情,可以使用契约加以校验和文档化。
提示38:尽早崩溃 114
彻底死掉的程序通常比有缺陷的程序造成的损害要小。
提示39:使用断言去预防不可能的事情 115
如果一件事情不可能发生,那么就用断言来确保其的确不会发生。断言在校验你的假设,要使用断言在不确定的世界中将你的代码保护起来。
提示40:有始有终 119
只要有可能,对资源进行分配的函数或对象就有责任去释放该资源。
提示41:在局部行动 122
将易变的变量维持在一个范围内,打开资源的过程要短暂且明显可见。
提示42:小步前进——由始至终 127
永远小步前进,不断检查反馈,并且在推进前先做调整。
提示43:避免占卜 129
只在你能看到的范围内做计划。
提示44:解耦代码让改变更容易 132
耦合使事物紧紧绑定在一起,以至于很难只改变其中之一。
提示45:只管命令不要询问 133
不要从对象中取出值,在加以变换后再塞回去,让对象自己来完成这些工作。
提示46:不要链式调用方法 135
当访问某事物时,使用的点号不要超过一个。
提示47:避免全局数据 137
最好给每个方法增加一个额外的参数。
提示48:如果全局唯一非常重要,那么将它包装到API 中 137
……但是,仅限于你真的非常希望它是全局的。
提示49:编程讲的是代码,而程序谈的是数据 151
所有的程序都在变换数据——将输入转换为输出。开始用变换式方法来设计吧!
提示50:不要囤积状态,传递下去 156
不要把数据保持在函数或模块的内部,拿出来传递下去。
提示51:不要付继承税 165
考虑一下能更好满足需求的替代方案,比如接口、委托或mixin。
提示52:尽量用接口来表达多态 167
无需继承引入的耦合,接口就能明确描述多态性。
提示53:用委托提供服务:“有一个”胜过“是一个” 167
不要从服务中继承,应该包含服务。
提示54:利用 mixin 共享功能 169
mixin 不必承担继承税就可以给类添加功能,而与接口结合可以让多态不再令人痛苦。
提示55:使用外部配置参数化应用程序 170
如果代码对一些在应用程序发布后还有可能改变的值有所依赖,那么就在应用外部维护这些值。
提示56:通过分析工作流来提高并发性 176
利用用户工作流中的并发性。
提示57:共享状态是不正确的状态 180
共享状态会带来无穷的麻烦,而且往往只有重启才能解决。
提示58:随机故障通常是并发问题 186
或许时间和上下文的变化能暴露并发Bug,但并发Bug无法始终保持一致,也很难重现。
提示59:用角色实现并发性时不必共享状态 188
使用角色来管理并发状态,可以避免显式的同步。
提示60:使用黑板来协调工作流 195
使用黑板来协调不相关的事实和代理人,能同时保持参与者之间的独立性和孤立性。
提示61:倾听你内心的蜥蜴 201
当编程举步维艰时,其实是潜意识在告诉你有什么地方不对劲。
提示62:不要依赖巧合编程 207
只能依赖可靠的事物。注意偶然事件的复杂性,不要混淆快乐的巧合与有目的的计划。
提示63:评估算法的级别 214
在开始编程前,对这件事情大概会花多长时间要有概念。
提示64:对估算做测试 214
针对算法的数学分析无法说明所有问题,尝试在目标环境中测试一下执行代码的耗时。
提示65:尽早重构,经常重构 219
像除草和翻整花园那样,只要有需要就对代码进行重新编写、修订和架构,以便找到问题的根源并加以修复。
提示66:测试与找 Bug 无关 221
测试是观察代码的一个视角,可以从中得到针对设计、接口和耦合度的反馈。
提示67:测试是代码的第一个用户 222
用测试的反馈来引导工作。
提示68:既非自上而下,也不自下而上,基于端对端构建 225
创建一小块端到端的功能,从中获悉问题之所在。
提示69:为测试做设计 228
写下代码之前先从测试角度思考。
提示70:要对软件做测试,否则只能留给用户去做 230
无情地测试,不要等用户来帮你找 Bug。
提示71:使用基于特性的测试来校验假设 231
基于特性的测试将会进行你从未想过的尝试,并会以你不曾打算采用的方式操练你的代码。
提示72:保持代码简洁,让攻击面最小 241
复杂的代码给 Bug 以滋生之沃土,给攻击者以可趁之机。
提示73:尽早打上安全补丁 243
攻击者会尽可能快地部署攻击,你必须快上加快。
提示74:好好取名;需要时更名 249
用名字向读者表达你的意图,并且在意图改变时及时更名。
提示75:无人确切知道自己想要什么 252
他们或许知道大概的方向,但不会了解过程的曲折。
提示76:程序员帮助人们理解他们想要什么 253
软件开发更像是一种由用户和程序员协同创造的行为。
提示77:需求是从反馈循环中学到的 254
理解需求需要探索和反馈,因此决策的结果可以用来完善最初的想法。
提示78:和用户一起工作以便从用户角度思考 255
这是看透系统将如何被真正使用的最佳方法。
提示79:策略即元数据 256
不要将策略硬编码进系统,而应该将其表达为系统的一组元数据。
提示80:使用项目术语表 259
为项目的所有特定词汇创建一张术语表,并且在单一源头维护。
提示81:不要跳出框框思考——找到框框 261
在面对无法解决的难题时,识别出真正的约束。可以问自己:“必须这样做才能搞定吗?必须搞定它吗?”
提示82:不要一个人埋头钻进代码中 267
编程往往困难又费力,找个朋友和你一起干。
提示83:敏捷不是一个名词;敏捷有关你如何做事 267
敏捷是一个形容词,有关如何做事情。
提示84:维持小而稳定的团队 272
团队应保持稳定、小巧,团队中的每个人都应相互信任、互相依赖。
提示85:排上日程以待其成 274
如果你不把事情纳入日程表,它们就不会发生。反思、实验、学习、提高技能,这些事都应放入日程表。
提示86:组织全功能的团队 276
围绕功能而不是工作职能组织团队。不要将 UI/UX 设计者从程序员中分离出去,也不要分开前端和后端;不要区分数据建模者和测试人员,以及开发和设计。构建一个团队,这样你就可以渐进地不断迭代端到端的代码。
提示87:做能起作用的事,别赶时髦 279
不要仅仅因为别的公司正在那么干就采纳一项技术或采用一个开发方法,而是要采用自己所处环境中对团队有效的东西。
提示88:在用户需要时交付 281
不要卡着流程要求,刻意等到几周甚至几个月后才交付。
提示89:使用版本控制来驱动构建、测试和发布 282
利用提交或推送来触发构建、测试、发布,利用版本控制的标签来进行生产部署。
提示90:尽早测试,经常测试,自动测试 283
每次构建都跑一下的测试,要比束之高阁的测试计划有效得多。
提示91:直到所有的测试都已运行,编码才算完成 283
无须多言。
提示92:使用破坏者检测你的测试 285
在一个单独的源码副本中特意引入 Bug,验证测试能否将其捕获。
提示93:测试状态覆盖率,而非代码覆盖率 286
要识别并测试重要的程序状态,只测试一行行的代码是不够的。
提示94:每个 Bug 只找一次 286
只要人类测试者找到一个 Bug ,就应该是该 Bug 最后一次被人类发现。从此之后,自动化测试完全可以发现它。
提示95:不要使用手动程序 287
计算机能一次又一次,按照同样的次序,执行相同的指令。
提示96:取悦用户,而不要只是交付代码 289
为用户开发能够带来商业价值的解决方案,并让他们每天都感到愉快。
提示97:在作品上签名 290
过去的工匠在为他们的作品签名时非常自豪,你也应该这样。
提示98:先勿伤害 293
犯错在所难免,确保犯错后没人会因此受难。
提示99:不要助纣为虐 294
因为这样做你也有变成纣王的风险。
提示100: 你要为自己的人生做主。