作者：[美] Robert C. Martin
翻译：章显洲 余晟
https://book.douban.com/subject/11614538/
第一章 专业主义
1.1 清楚你要什么
专业主义的精髓在于将公司利益视同个人利益。所以犯错不是“在所难免的”，而是应当极力避免，并勇于承担后果。
1.2 担当责任
1.3 不行损害之事
- 不破坏软件功能
让QA找不出问题，而不是让QA帮忙检查 - 确信代码能正常运行
要考虑单元测试，测试覆盖率，测试驱动开发（TDD） - 自动化QA
- 不破坏结构
所有软件项目的根本指导原则是：软件要易于修改。
不破坏结构并不表示尽量少修改代码，相反，如果期望自己的软件灵活可变，就应该时常修改它。
事实是，大多数开发人员不敢不断修改代码，因为害怕改坏了。这里就又回到上面的“自动化测试”，如果有自动化测试，并且测试覆盖率也很高，那么就不会害怕改坏了。
1.4 职业道德
职业发展是个人的事情，雇主没有义务考虑这些，也没有义务给你培训，送你参加会议等等。
职业道德是：
- 你自己要计划每周工作的时间，比如60小时，其中40小时是给雇主的，剩下的20小时是给自己做提升使用。
- 了解你的领域
工作中涉及到的东西都要去了解，否则只能写写 if-else, while 之类的代码了。
以下是每个专业软件开发人员必须精通的事项：
设计模式：GoF 书中（设计模式）的23种模式
设计原则：必须了解SOLID原则，而且要深刻理解组件设计原则
方法：XP、Scrum、精益、看板、瀑布、结构化分析、结构化设计等
实践：TDD、OOP、结构化编程、CI&CD&CD、结对编程
工件：UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图、决策表
坚持学习
坚持练习（业精于勤）
合作
辅导（教学相长）
了解业务领域（熟悉行业背景，不能全按照规格说明去编码，而是要能够辨别、质疑一些需求）
与雇主/客户保持一致
谦逊（每个人都会犯错，所以不要嘲笑别人，自己出错了能坦然接收别人的嘲笑）
第二章 说“不”
能就是能，不能就是不能。不要说“试试看”。 - 尤达
这一章介绍了“专业程序员要竭尽所能地追求和捍卫自身的目标，从而会和管理者产生对抗”，“高风险时刻更应该说不”，“团队精神是为整体目标着想，而不是试试看”。而这些前提都是开发人员人员能够做到较好的项目排期，并且有理有据地对管理者说“不”，同时也不能总说不，否则就是能力问题了。
第三章 说“是”
3.1 承诺用语
口头上说、心理认真、付诸行动。
“缺乏承诺的”的征兆：
- 我们要。。。
- 我需要。。。
- 。。。应当。。。
- 让我们。。。
- 希望。。。
- 但愿。。。
真正的承诺：我将在（时间点）之前完成（某个任务）
言必行行必果，如果没做到的话，要如何应对呢？
- 之所以没成功，是因为我寄希望于某某去做这件事。
- 之所以没成功，是因为我不太确信是否真能完成得了
即使目标无法完成，也能全力前进，离目标更近。 - 之所以没成功，是因为有些时候我真的无能为力。
突发事件出现后，尽快去调整别人对你的预期（越快越好）。
总结：估算日期、确定最后期限、交流沟通等等，做出承诺会令人害怕，但是可以建立个人的信誉（reputation）。
3.2 学习如何说“是”
-
“试试”的另一面
image.png - 坚守原则
首先，测试、文档、代码整洁性这些是不能够省略的，因为省略这些也不能保证更快完成。多年的经验是，打破这些纪律和原则，更会拖慢进度。
然后，尝试说服管理者确实无法做到，可以找
最后，如果实在不行，必须要做到，也得给自己争取利益，不管是加人也好、调休也好。
3.3 总结
专业人士不需要对所有请求都回答“是”。不过，应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用承诺用语，以确保各方能够明白无误地理解承诺内容。
第四章 编码
4.1 做好准备
编码要求聚精会神，要避免：
- 心烦意乱时写代码
- 疲劳时写代码（比如加班，凌晨3点）
- 焦虑时写代码
4.2 流态区
其实就是效率很高的状态。
但是这种状态其实是一种”浅层冥想”状态，敲出的代码会增多，但是理性思考就少了。
结对编程的好处在于任何一方都不会进入流态区。
4.3 阻塞
写不出来的时候要学会调整状态。做些事情，而不是死盯着屏幕。
4.4 调试
4.5 保持节奏
也就是调整状态。
4.6 进度延迟
4.7 帮助他人
第五章 测试驱动开发
TDD不光是一种技巧，也是一种思维方式。
三大原则：
- 编好失败单元测试之前，不要编写任何产品代码。
- 只要有一个单元测试失败了，就不要再编写代码；无法通过编译也是一种失败情况。
- 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多谢。
这样测试代码、产品代码、测试代码、产品代码。。。同步增长，互为补充。
5.3 TDD的优势
- 确定性
单元测试通过了，对产品就有把握了。 - 降低缺陷注入率
- 勇气
有助于重构、修改糟糕代码 - 文档
单元测试即文档。 - 设计
测试代码的一个问题是必须隔离出待测试的代码，这样有助于代码的解耦，也就有助于开发出更好的设计。
（先写产品代码，很容易写出一大坨耦合的代码，不利于测试；先写测试代码就可以避免） - 专业人士的选择
5.4 TDD的局限
测试代码也可能很糟糕。。。
还有一些其他场景，不适合TDD
等等
第六章 练习
为开源项目贡献代码。
第七章 验收测试
7.1 需求的沟通
- 避免过早精细化
需求总会变化的，突发事件也总是会发生的，在这之前想要确定最终交付的一项项的功能，就有点浪费精力了。 - 明确需求
跟客户直接隔着一层又一层，就会导致信息的丢失，也就会导致对需求理解的偏差。
7.2 验收测试
- 什么叫完成？
QA + 需求方都确认了，才叫完成。 - 沟通
- 自动化
- 额外工作
5.验收测试什么时候写，由谁写
业务方+QA > 业务分析员+QA > QA > Dev
避免同一个人既写了代码又写了测试。 - 测试的协商与被动推进
- 验收测试和单元测试
- GUI及其他因素
- CI
7.3 结论
编写自动化的验收测试可以避免交流中的误解。
第八章 测试策略
8.1 QA应该找不到错误
QA和Dev是一个团队的，而不是对立的。
8.2 自动化测试金字塔
从下往上，覆盖率由高到低：
单元测试，组件测试，集成测试，系统测试，Web自动化测试，人工探索式测试。
第九章 时间管理
9.1 会议
- 拒绝一些会议
- 提前离席
- 确定议程与目标
- 站会（尽可能快）
- 迭代计划会议
- Retro
- 争论/反对（争论之所以花费很多时间，是因为各方都拿不出有力的证据）
9.2 注意力（精力）
- 睡眠
- 咖啡因
- 恢复
- 肌肉注意力
- 输入与输出
9.3 时间拆分和番茄工作法
划分时间段，比如25分钟一个时间段，这段时间内只做一件事，25分钟结束后再处理这段时间内发生的事情。
25分钟专注+5分钟休息，4轮过后休息30分钟。
9.4 排好优先级
9.5 避免死胡同里浪费时间
9.6 避免陷入泥潭
9.7 结论
专业开发人员要注意管理自己的时间和精力，排好优先级，认清当前的状况，并避免走入死胡同和陷入泥潭。
第十章 预估
第二章 说“不” 里已经提到了预估的重要性。
10.1 区分预估和承诺
10.3 预估任务
按照斐波那契数列预估（1，2，3，5，8）
10.4 大数定律
大任务分割为小任务，预估，加和，这样预估准确率高一些
10.5 结论
专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。
但是大多数情况下，他们不会做这种承诺，而是提供概率预估，来描述期望的完成时间和可能的变数。
第十一章 压力
11.1 避免压力
- 承诺
- 保持整洁
- 危机中的纪律
11.2 应对压力
- 不要慌张
- 沟通
- 依靠纪律原则
- 寻求帮助
11.3 结论
能回避压力的时候尽可能回避，无法回避时则勇敢直面压力。
可以通过慎重承诺、遵循自己的纪律原则、保持整洁来回避压力。
直面压力时，保持冷静，多与人沟通，坚持原则，寻求他人帮助。
第十二章 协作
12.1 程序员与人
- 与雇主
多了解业务 - 与程序员
互相学习、互相帮助
12.3 结论
编程就意味着与人协作，与人交流。
第十三章 团队与项目
13.1 只是简单的混合吗
- 有凝聚力的团队
- 如何管理有凝聚力的团队
- 项目承包人的困境
13.2 结论
团队比项目更难构建。因此，组件稳健的团队，接手一个又一个的项目，整体移动，形成凝聚力，不断磨合，一直共同工作，成为不断交付项目的强大引擎。
第十四章 辅导、学徒期与技艺
14.1 失败的学位教育
14.2 辅导
14.3 学徒期
14.4 技艺
14.5 结论
学校传授的是计算机编程的理论，还缺少原则、实践、技能。需要软件行业中的每一代人去引导下一代人。
读后感
这本书的内容本身就很务虚，作者通过大量的、大段的举例说明，来描述他想要表达的思想。
而这些思想又不是各自独立的，分为十四个章节，相互交织在一起，导致一些重复（比如多次提到需要沟通，还有关于测试，团队协作，团队精神等等），所以显得有些混乱。
同时这十四个章节涵盖的面又有些广，从个人技能到与人协作，再到辅导、学徒，稍显零散。
不过可以看出，这些思想是作者经年累月的宝贵的人生经验，还是可以让读者在多个方面产生共鸣的。
记住这些经验，在工作中时刻提醒自己，一定可以有所收获的。
简单地总结一下：
- 提高预估、排期的能力，从而可以从容地说“不”，说“是”，提高个人的声誉，减小压力；
- 沟通交流，不仅要与业务方交流业务，还要与管理者交流进度，还要与其他程序员交流技术，互相帮助；
- 管理好时间，不光是工作上，减少无意义的会议、管理精力、排好优先级、避免死胡同和泥潭，还要给自己保留提升个人技艺的时间，勤加练习；
- 建立个人的原则，例如不轻易承诺、保持整洁、不能为了工期而削减测试代码等等，这些纪律也可以帮助你说“不”，说“是”，以及应对压力；
- 团队凝聚力是完成项目的前提；
- 怎么才算完成？开发人员要做到自己测试没问题，然后再交给QA，等QA和业务方都确认后才算完成。
不是说代码写完了就完了的。
做到了上面的这些，才能算作专业人士，才能算是具有程序员的职业素养！
P.S. 虽然本身很务虚，但也通过大量的举例，提出了一些务实的建议和方法，比如：
- 多了解技能领域：设计模式、设计原则、方法、实践、工件等
- 编码是一项脑力+体力劳动，所以需要身体做好准备，要避免疲劳、焦虑时编码
- 时间管理里，减少会议时间、减少无意义的争论（让数据说话）
- 预估任务时，（1，2，3，5，8），拆分任务再预估
- 项目交付快要失败前，及时沟通，降低别人的期望，保护你自己的声誉，也减小你的压力
