第1章 专业主义
R：开发的软件有bug会损害软件的功能。因此，要做得专业，就不能留下bug。
软件开发太复杂了，不可能没什么bug。但很不幸，这并不能为你开脱。
人体太复杂了，不可能尽知其全部，但医生仍要发誓不伤害病人。
如果他们都不拿“人体的复杂性”作托词，我们又怎么能开脱自己的责任呢？
第10页 · 2022-04-13
C：在第一次看到这个观点，冲击还是挺大的，以前从没有想过 bug 跟程序员专业性的关系。看到作者对医生的类比后，恍然大悟，作者说的没错，我们可以有 bug，但要对每一个 bug 负责。
R：为什么大多数开发人员不敢不断修改他的代码呢？
因为他们害怕会改坏代码！为什么会有这样的担心呢？因为他们没做过测试。
如果你有一套覆盖了全部代码的自动化测试，如果那套测试可以随时快速执行，那么你根本不会害怕修改代码。
怎样才能证明你不怕修改代码呢？那就是，你一直在改。
第13页 · 2022-04-13
C：这段对程序员不干改代码的心理描写非常真实。借助这个常见的痛点，作者引出了自动化测试的解决方案，成功引起了我的兴趣。
R：下面列出了每个专业软件开发人员必须精通的事项。
设计模式。必须能描述 GOF 书中的全部24种模式，同时还要有 POSA 书中的多数模式的实战经验。
设计原则。必须了解 SOLID 原则，而且要深刻理解组件设计原则。
方法。必须理解 XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计 等。
实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
工件。必须了解如何使用 UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表。
第15页 · 2022-04-13
C：这里给出了程序员的升级路线，如果在从业前两三年看到这本书就好了。
第2章 说“不”
R：许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。
许诺“尝试”，意味着只要你再加把劲还是可以达成目标的；
而且，这也是一种表示你将再接再厉去实现目标的承诺。
因此，只要你许诺百己会去“尝试”，你其实是在承诺你会确保成功。
这样，压力就要由你自己来扛了。
如果你的“尝试”没有达成预期的结果，那就表示你失败了。
第27页 · 2022-04-13
C：以前没有深刻思考过这个问题，也遇到过身边类似的同事，总喜欢随便说试试，这样看来，试试也不能随便说，要有足够的把握才行。
R：有可能写出好代码吗？有可能坚守专业主义精神吗？
我的回答是：“是的。但你要学会如何说‘不’。”
第36页 · 2022-04-13
C：一句话总结，想要做到专业，必须学会说不。
第3章 说“是”
R：承诺用语（Roy Osherove）
做出承诺，包含三个步骤：
（1）口头上说自己将会去做。
（2）心里认真对待做出的承诺。
（3）真正付诸行动。
第39页 · 2022-04-13
C：这里给出了承诺的步骤，感觉这套步骤不仅适用于程序员，适用于大部分场景。
R：专业人士不需要对所有请求都回答“是”。
不过，他们应该努力寻找创新的方法，尽可能做到有求必应。
当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方能明白无误地理解承诺的内容。
第46页 · 2022-04-13
C：想要做到专业，需要做到有求必应，但不一定总是给肯定的答案。
第4章 编码
R：避免进入流态区。
这种意迟状态并非真的极为高效，也绝非毫无错误。
这其实只是一种“浅层冥想”状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。
第51页 · 2022-04-13
C：翻译问题，这里说的状态应该是“心流”，从其他书籍中也看过，但大都是提倡进入“心流”状态的。这里给了一个相反的建议，感觉需要看场景活用。
R：假设你正在专心工作，此时有人过来问你问题，你会粗暴相待吗？
粗暴相对的回应方式通常都是因为流态区所致。
有一些解决办法可以应对这种情况。
结对是用以应对中断的一种好方法。
当你接答电话或回答其他同事的问题时，结对搭档能够维护住中断处的上下文。
等到你重新回去和结对搭档一起工作时，他能够很快地帮你恢复被打断前的思维。
另一种很有帮助的方法便是采用TDD。
失败的测试能帮你维护住编码进度的上下文。
当处理完中断重新回去时，你很清楚下一步任务便是让这个失败的测试通过。
当然，中断无法避免，总有干扰会打断你、消耗你的时间。
发生这种情况时要记住一点，也许下次也会轮到你去打断别人请求帮助。
因此，礼貌地表现出乐于助人的态度才是专业的态度。
第53页 · 2022-04-13
C：我以前就是很讨厌被人打断的，作者分析了这种心态的原因，也给出了一些建议。我还有一种办法可以补充，就是以前写好设计文档或实现思路，被中断后可以回来参考。
R：衡量你是否是一名专业人士的一个重要方面，便是看你是否能将调试时间尽量降到最低。
绝对的零调试时间是一个理想化的目标，无法达到，但要将之作为努力方向。
医生不喜欢重新打开病人的胸腔去修复此前犯下的错误。
律师不喜欢重新接手此前搞砸的案子。
经常重新返工的医生或律师会被认为不专业。
同样，制造出许多bug的软件开发人员也不专业。
第57页 · 2022-04-13
C：这部分对调试时间做了详细的分析，说明了缩短调试时间的重要性。作者再次拿医生和律师行业的例子做对比，很有说服力。
R：不应该采用额外加班加点工作的方案，除非以下三个条件都能满足：
（1）你个人能挤出这些时间；
（2）短期加班，最多加班两周；
（3）你的老板要有后备预案，以防万一加班措施失败了。
最后一条至为关键。如果老板无法向你清楚说明加班方案失败的后备预案，那么你就不
该同意接受加班方案。
第60页 · 2022-04-13
C：在常见的加班问题上，作者给出了几个参考条件，很有借鉴价值，应该牢记。
第5章 测试驱动开发
R：TDD的三项法则：
（1）在编好失败单元测试之前，不要编写任何产品代码。
（2）只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
（3）产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
第67页 · 2022-04-13
C：作者给出了一些TDD的建议，有借鉴意义，可以和《测试驱动开发的艺术》结合起来看。
第6章 练习
R：无论如何，专业人士都需要练习。
他们这么做，是因为他们关心自己能做到的最好结果。
更重要的是，他们用自己的时间练习，因为他们知道保持自己的技能不落伍是自己的责任，而不是雇主的责任。
练习的时候你是赚不到钱的，但是练习之后，你会获得回报，而且是丰厚的回报。
第80页 · 2022-04-13
C：本章详细介绍了联系，并强调了它的重要性。明确了练习不应该占用工作时间，不应该期望雇主给你练习时间，因为这是在提升自己的职业技能。
第7章 验收测试
R：验收测试什么时候写，由谁来写
在理想状态下，业务方和 QA 会协作编写这些测试，程序员来检查测试之间是否有冲突或矛盾。
但实际上，业务方通常没有时间，或者有时间也难以达到所需要的细致程度，所以他们通常会把测试交给业务分析员、QA 甚至是开发人员。
如果只能由开发人员来写测试，应当确保写测试的程序员与开发所测试功能的程序员不是同一个人。
通常，业务分析员测试“正确路径”，以证明功能的业务价值；QA则测试“错误路径”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。
遵循“推迟精细化”的原则，验收测试应该越晚越好，通常是功能执行完成的前几天。
在敏捷项目中，只有在选定了下一轮迭代（Iteration）或当前冲刺（sprint）所需要的功能之后，才编写测试。
第90页 · 2022-04-13
C：这里给出了验收测试编写的权责和时机，如果有机会在团队中推行验收测试，可以参考。估计推行验收测试也挺有难度的，主要难点是谁来写。
R：验收测试和单元测试
验收测试不是单元测试。
单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。
关心单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的（虽然可能最后是身为开发者的你来写）。
它们是正式的需求文档，描述了业务方认为系统应该如何运行。
关心验收测试结果的是业务方和程序员。
这两种测试并不重复的根本理由在于，它们的主要功能其实不是测试，测试只是它们的附属职能。
单元测试和验收测试首先是文档，然后才是测试。它们的主要目的是如实描述系统的设计、结构、行为。
它们当然可以验证设计、结构、行为是否达到了具体指标，但是，它们的真正价值不在测试上，而在具体指标上。
第93页 · 2022-04-13
C：这里详细解释了验收测试和单元测试的区别，这块很重要，程序员需要非常清楚。
R：通过恰当的界面测试
测试系统功能时，应当调用真实的 API，而不是 GUI。
通过 GUI 来进行测试是非常容易出问题的，除非你要测试的仅仅是 GUI。
应当尽可能地减少GUI测试。GUI很容易变化，所以这类测试是不稳定的。
GUI测试越多，维护它们的难度就越大。
第94页 · 2022-04-13
C：这里对 UI 测试提出了建议，主要观点是尽可能的少，因为 UI 变化太快了，持续编写和维护 UI 测试不现实。
R：持续集成
请务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。
整套持续集成系统应该由源代码管理系统来触发。
只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试，测试结果会用电子邮件发送给团队所有人。
第94页 · 2022-04-13
C：持续集成这个概念我们经常提及，但就像“敏捷开发“一样，大部分人只知道这个词，很少全面理解他们的含义，但搞清楚这些概念很重要。
R：交流细节信息是件麻烦事。
尤其是开发方和业务方交流关于程序的细节时，更是如此。
通常，各方握手言欢，以为其他人都明白自己的意思。
双方以为取得了共识，然后带着截然不同的想法离开，这种事太平常不过了。
要解决开发方和业务方沟通问题，我所知道的唯一有效的办法就是编写自动化的验收测试。
这些测试足够正式，所以其结果有权威性。这些测试不会造成模糊，也不可能与真实系统脱节。
它们，就是无可挑剔的需求文档。
第95页 · 2022-04-13
C：这里从提升交流效率的角度，讨论了自动化测试的重要性，很有借鉴价值，但需要团队对这个理念达成共识。
第8章 测试策略
R：自动化测试金字塔
第99页 · 2022-04-13
C：本章对自动化测试做了全面的讲解，一张金字塔图基本可以概括。
第9章 时间管理
R：“凡是不能在5分钟内解决的争论，都不能靠辩论解决。”（Kent Beck）
争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。
所以这类争论依据的不是事实，而是信念。技术争论很容易走入极端。
每一方都有各种说法来支持自己的观点，只是缺乏数据。
在没有数据的情况下，如果观点无法在短时间（5~30分钟）里达成一致，就永远无法达成一
致。
唯一的出路是，用数据说话。
第107页 · 2022-04-13
C：作者引用了 Kent Beck 的话来说明争论是浪费时间。并给出了唯一的解决方案，用数据说话。
第10章 预估
R：专业开发人员懂得如何为业务人员提供可信的预估结果，以便做出计划。
如果做不到，或者不确定能做到，专业开发人员不会给出承诺。
专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。
但是大多数情况下，他们都不会做这种承诺，而是提供概率预估，来描述期望的完成时间及可能的变数。
对需要妥善对待的预估结果，专业开发人员会与团队的其他人协商，以取得共识。
第123页 · 2022-04-13
C：本章举例说明了专业开发人员做出可信预估的几种方法。有些方法应该可以参考，比如军队的那个估时方法。
第11章 压力
R：应对压力的诀窍在于，能回避压力时尽可能地回避，当无法回避时则勇敢直面压力。
可以通过慎重承诺、遵循自己的纪律原则、保持整洁等来回避压力。
直面压力时，则要保持冷静，与别人多多沟通，坚守自己的原则纪律，并寻求他人的帮助。
第129页 · 2022-04-13
C：面对压力，我们有两种应对策略，首先是遵循专业程序员的各种原则来回避压力，如果不行，那要保持冷静，多跟其他人沟通，坚守原则，寻求帮助。
第12章 沟通
R：真不走运，编程就意味着与人协作。
我们需要和业务人员一起工作，我们之间也需要互相合作。
我知道，我知道。
如果把我们关在一个有六个大屏幕显示器的房间里，里面有高速宽带网络，有一组超快的处理器并行队列，有用不尽的内存和磁盘，享用不完的健怡可乐和香脆的玉米薯条，那岂不是棒极了？
唉，伙计，不是这样的。
如果我们真想终生能以编程度日，那么，一定要学会交流一和大家交流。
第138页 · 2022-04-13
C：大部分程序员都不喜欢与人协作，但专业的程序员必须能与人畅快的合作，因为一个人能做的事情是很有限的。
第13章 团队与项目
R：有凝聚力的团队
形成团队是需要时间的。团队成员需要首先建立关系。
他们需要学习如何互相协作，务要了解彼此的癖好、强项、弱项，最终，才能凝聚成团队。
有凝聚力的团队确实有些神奇之处。他们能够一起创造奇迹。
他们互为知己，能够替对方着想，互相支持，激励对方拿出自己最好的表现。他们攻无不克。
有凝聚力的团队通常有大约12名成员。
程序员算一组，测试人员和分析师算一组，两组人数比例没有固定限制，但2：1是比较
好的组合。
所以由12个人组成的理想团队，人员配备情况是这样的：7名程序员、2名测试人员、2名分析师和1名项目经理。
第140页 · 2022-04-13
C：本周说明了有凝聚力的团队的重要性，并给出了非常具体的团队规模和配置建议。
第14章 辅导、学徒期和技艺
R：学校能够传授的是计算机编程的理论。
但是学校并不会也无法传授作为一名编程匠者所需掌握的原则、实践和技能。
这些东西只有经由师徒个体间多年的细心监督和辅导才能获得。
软件行业中像我们这样的一批人必须要面对这一事实，即指引下一代软件开发人员成熟起来
的重任无法寄希望于大学教育，现在这个重任已经落到了我们肩上。
建立一种包含学徒期、实习期和长期指引的机制已是迫在眉睫。
第155页 · 2022-04-13
C：本周表达了作者对软件行业的混乱状况的担忧，并给出了学徒、实习、长期指引等一系列规范化机制的建议。之前看过一个外科领域的纪录片，感觉v跟作者的愿景有点像。
总结
Bob大叔其人
书中有大量篇幅描写了作者本人的真实经历。
大叔经验非常丰富，技术栈也非常全面，在社区的影响力不小，而且他本人应该也很有趣。
读了这本书以后，对Bob大叔肃然起敬，接连读了他的几本书，都挺不错的。
程序必备技能
书中全面介绍了专业程序员的必备技能：如何承诺、编码过程中的技巧、测试驱动开发、练习、时间管理、应对压力、预估和协作等。
其中大部分内容其实是非技术能力，但这些能力却至关重要，如果没有系统的了解过这些能力，那就需要长年累月的摸索和积累经验了，会绕很多弯路。
交付、团队
书中贯穿始终的自动化测试，理论上是非常靠谱的。
如果团队能够正确时间这些方法论，应该会有非常好的交付能力，为公司和业务提供坚实的技术后盾。
关于团队规模和配置的说明，有一定参考意义，但也有点安利“敏捷开发“的嫌疑，不管怎么说，想达到理想状态还是很有难度的。