一、前言

这本书，总体感觉非常建议大家读读。

作者是一个工作经历十分丰富的程序员，从业四十多年，各种语言，项目类型从汇编到如今的开发环境，，都经历过，职业生涯大起大落。作者拥抱变化，持续思考，保持个人持续进化，让我十分敬佩。

拜读完这本书，我大概把这本书分为五个部分，如下所示。归纳了主题，和各个所在的章节。有兴趣的小伙伴可以参考。

1.谈建立『专业感』

§1.专业主义

§2.说『不』

§3.说『是』

2.谈更好的『编码和TDD』

§4.编码

§5.测试驱动开发

§6. 练习

3.谈如何更好的『测试』项目

§7.验收测试

§8.测试策略

4.谈『个人、项目』

§9.时间管理

§10.预估

§11.压力

5.谈『个人与团队』

§12.协作

§13.团队与项目

§14.辅导、学徒期与技艺

二、价值摘录和评论

A. 谈建立『专业感』

1) 『专业主义』意味着担当责任

软件开发变得日益重要，软件用于生产各个环节，一个疏忽，会导致巨大的损失。认识到自己工作的重要性，并且从心态和认识上认证严肃起来，承担责任。

如何才能承担责任呢？一些原则：

不要破坏结构：不要为了新功能而破坏结构，结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必追悔莫及。

不要破坏软件功能：失误率永远不可能等于零，但是你有责任让它无限接近于零 让QA找不出任何问题：每当QA，用户找出问题，你都应该震惊羞愧，并决心以此为戒 要确信代码正常运行：TDD开发重要性，唯一能让你确信的代码正常的东西 自动化QA 职业道德：在工作时间内，为你的雇主发挥最大价值。 了解你的领域：学习你所在领域一些必须精通的知识 坚持学习 练习 合作：学习第二最佳方法是和他人合作，彼此学习 辅导 了解业务领域：每位程序员有义务了解自己开发解决方案所在领域。 与雇主客户保持一致：雇主的问题就是你的问题，你要弄明白，并且寻找最佳方案。你要站在雇主的角度思考。避免产生割裂认知。 谦逊

2）说『不』

这个章节很有趣，讲的就是现实中不断发生的事情——『赶需求』。作者用描述的方式，展现了赶需求的灾难，摆明了几种态度，和他们的结果。 总之，这章节没有什么金句。但是过来人告诉你一个道理，遇到根本不可能完成的任务时——勇敢说不。 不管什么理由，明知道不可能，而说『是』，会带来灾难：

赶工期，加班，为了赶进度而忽略测试，结构——一切的混乱会把项目拖垮，而那种幻想下的交付，根本不可能达成。

3) 说『是』

前面讲了说『不』，讲的是如何拒绝不合理需求，坚守底线。这个部分讲的是，『承诺』，对于我们自己和业务方的交流，提供模糊的回答也是不专业的。专业人士对自己的能力极限了如指掌，他们会努力寻找创新的方法，尽可能做到有求必应。给出肯定回答的时候，会使用正是承诺。确保各方能够明白无误的理解承诺内容。

B. 更好的编码

1）平衡编码

代码不是件容易的事情，首先他要

代码可以正常工作 解决客户的问题 和系统结合的天衣无缝 其他程序员必须能读懂 代码解决的是一个平衡的问题，长时间高度集中精神是有难度的，现实中还会有各种干扰。

感到疲惫或者心烦意乱，千万不要编码。抢而为之最终会返工，相反去找到一种方式，平复情绪。 焦虑时不要写代码 避免进入流态区：这种集中的一个人的境界是一种浅层冥想状态，会让你的思维变得狭窄。 音乐：回来带干扰，其实是另一种流态区 中断：礼貌的回应，TDD、结对，可以让你恢复上下文 阻塞：结对编程，是个好方法 创造性输入：广泛阅读，激发你的创造性——编程是创造性的工作 调试：调试的时间，也被认为是开发的一部分。 保持节奏：软件开发是马拉松，而不是冲刺跑。保持休息 进度延迟：不要盲目冲刺打乱计划 定义完成：每个环节，定义完成的标准，进行验收测试 帮助：互相帮助，从别人的思考想法中获益；同时也要乐于接受帮助。 辅导：向资深导师寻求辅导也是程序员专业职责

2) 测试驱动开发

TDD三项法则：

编好单元测试之前，不要编写任何产品代码 只要有一个单元测试失败了，就不要再写测试代码，无发通过编译也是一种失败情况 产品代码恰好能让当前失败的单元测试成功通过即可，不要多谢。 遵循三项法则，大概30秒就要运行一次代码。循环往复，测试代码不断匹配于产品代码。同步增长，互为补充。

勇气：TDD给你修改代码，重构代码的勇气。

文档：TDD是另一种，底层的文档。

设计：测试会驱动你的代码去解耦

专业：TDD是专业人士的选择

TDD的局限：依旧是工具，人要去平衡问题。

3) 练习

卡塔：编程柔道场

C. 更好的测试

1）验收测试

1.『完成』的定义：日常面对的不确定因素是『完成』的各种说法。跑通、通过测试、完成业务，都算是完成。专业人士会根据自动化验收测试来定义需求，他们与业务方和QA一起工作，确保自动化测试能够真正覆盖完成所需各种指标

2.沟通：开发、业务方、测试协同工作，确保大家都要明白，要做的是什么

3.自动化：使用开源商业工具完成自动化验收

4.开发的角色：

开发人员有责任把验收测试和系统联系在一起，让测试通过。身为专业开发人员，你的职责是协助团队开发出最棒的软件，也就是说，每个人都要关心错误和疏忽，并且协力改正。

5.验收测试和单元测试：

两者都是测试，但是路径不一样。单元测试是深入系统内部进行，调用特定的方法；验收测试时系统外部，通常是API或者UI级别进行。执行者不同。

6.图形界面与其他复杂因素：

依据『单一责任原则』（SRP）设计UI，以此为做稳定要素，对UI进行测试。

通过恰当的UI测试，因为UI很容易变化，这类测试不稳定，反而会成为维护负担。

7.持续集成

2）测试策略

自动化测试金字塔

D. 个人和项目

1）时间管理 把控好你自己工作的时间，拒绝无效会议、干扰 会议非常昂贵，主持会议，制定目标，控制时间，有效讨论 争论和反对：5分钟解决不了的问题，可能会变成站队、情绪的发泄、毫无帮助的讨论细节。单独解决，投票等。 注意力点数：保持专注，休息恢复 睡眠：充足的睡眠十分重要！！！ 输入与输出：好的输入会带来好的输出，读点能帮助自己创造力的任何东西。 番茄工作法：25分钟控制一个节奏，拒绝任何干扰 避免的行为：

优先级错乱：这是一种自我欺骗 死胡同：有勇气回头 泥潭：有勇气回头 2）预估 预估和承诺不同，但是现实中，预估就是承诺。沟通时，要清晰的表达。

借助数学工具，评估工作

• PERT
• 德尔菲法
• 亮手指
• 规划扑克牌
• 关联预估
• 三元预估
• 大数定律

3）压力 保持冷静是应对压力的最好方式。冷静思考，发现问题，解决问题。

避免压力

承诺：就算是没有能兑现诺言，导致业务失败。但是此前你已经表现的足够专业，至少可以问心无愧 保持整洁：快速前进的方法是，保持整洁。不会为了快点而乱来 纪律：困难降临，不要改变原则，坚决秉持纪律比如TDD 应对压力

不要惊慌和失措 沟通 依靠你的纪律原则 寻求帮助 E. 个人与团队 1）协作： 这章节也很有趣，程序员天生不爱打交道，但是实际上只有更好的打交道，才能让个人和团队一起进步。

协作性的代码共有权：尽可的共享代码，互相合作 结对 2）团队与项目 有凝聚力的团队 3）辅导、学徒期与技艺 建立一直师徒制

三、个人感受

实际上在接触到这本书的时候，正好处在一个Delay的项目中，亲眼看到书上的文字变成『纪实文学』。古话说『纸上得来终觉浅，绝知此事要躬行』，书本要比这个笔记更加丰富，但是即使写的更加生动，现实中的具体的项目和人才会更真实。

十分有趣的是作者在书里发的感慨，计算机行业30年，硬件性能提高了10^22 。引用作者原文：

这真是个巨大的数字，22个数量级是什么概念呢：是从这里到半人马座阿尔法星的距离（以埃为单位），是1美元硬币里的电子书，是地球质量与个人质量的比例。这个数字无比巨大，而这台笔记本就在我腿上。或许，你也有一台。

即使如此，但是程序的书写方式，并没有多大的改变。这非常有趣。

作者提出了很多方法论，其实这种方法论，如果奉承金科玉律，应该是流于形式了，不是作者本意。计算机行业快速发展，工具、框架、思想都年年发生井喷。如果把东西记死，不免又会落入一种禁锢。

其实只要有一个念头，就是重视，关心眼前所做的这件事情。积极的寻找更加专业的方式和方法。多换角度考虑。并且，拥抱新事物，不断地学习，擦除更新脑子里的概念。也可以像作者一样，保持进化，成为更好，更专业的自己。