之前看到书的英文名Clean Coder或中文名<程序员的职业素养>时，觉得不会有太多信息，没有要读的想法。
最近在极客时间学习两次看到有人提及该书，上次在图书馆借书时偶然看到。书很薄，仅170页。
看完坚定了一条：Bob大叔的书，是程序员必读系列。不管是Clean Code还是Clean Architecture中文版，每次读完都能刷新自己的认知。
专业
第一章是点题的，码农也可以作为一种自嘲，但不能作为一种追求。 既然是个职业，就要专业，想医生律师一样受人尊敬。
如何专业：
- 编程上：高质量代码，这里有软件设计、持续重构、不断练习编码等
- 技术上： 持续学习，了解新技术领域
- 业务上：摆脱纯技术视角，理解业务，懂得沟通
沟通
说“不”
- 尽职捍卫自己的目标
- 协商达成双方都接受的解决方案
- 事实比为什么更重要，为什么只是细节
- 试试看是对之前承诺的自我否定
- 避免消极对抗
说“是”
- 重视承诺：说到-付诸行动-做到
- 承诺自己能掌控的事
- 如果目标无法完成，尽力接近目标
- 如果有风险无法兑现，尽快调整别人的预期
- 坚守原则或表达不确定
开发
TDD/测试驱动开发
TDD能提升代码的确定性、降低代码缺陷率、优化文档（底层设计细节的文档）和设计（可测试性）。
三项法则：
- 在编好失败单元测试之前，不要编写任何产品代码
- 只要有一个单元测试失败了，就不要再写测试代码
- 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写
练习
关于Code Kata的介绍我会在另一篇博文详细介绍。
测试
验收测试
解决开发方和业务方沟通问题的唯一有效办法就是编写自动化的验收测试。
验收测试针对正常路径的测试(happy-path test)，QA测试针对极端情况(corner)、边界状态(boundary)和异常路径(unhappy-path)
自动化测试金字塔
- 单元测试在最低层次上定义系统，作为持续集成的一部分运行，覆盖率应保持在90%以上。大多数的异常路径测试是由单元测试覆盖。
- 组件测试是验收测试的一种，组件封装了业务规则，因此是对组件业务规则的验收测试。主要测试成功路径，以及一些明显的极端情况、边界状态和可选路径。
- 集成测试主要测试组件装配在一起时是否协调，不太关注业务规则测试。
- 系统测试时整个系统集成完毕的最终集成测试，测试系统是否正确组装完毕及各组件之间是否正确交互，不直接测试业务规则。目的不是确保正确的系统行为，而是确保正确的系统构造。
- 手动探索式测试不是要证明每条业务规则、每条运行路径都正确，而是确保系统在人工交互下表现良好，富有创造性地找出尽可能多的问题。
其他主题
该书还介绍了诸如各种会议、保持注意力、时间拆分和番茄工作法、避免和应对压力等方面。
预估
- PERT/计划评审技术：三元分析法，乐观预估、标称预估、悲观预估
- 德尔菲法： 两手指、规划扑克,通常用于单个任务预估
- 大数定律：把大任务分解成许多小任务，分开预估再加总