The Clean Coder 是The Clean Code的姊妹篇，由同一个作者编写，The Clean Code主要讲述如何编写高质量的代码，而The Clean Coder则关于于人，讲述如何做一个”专业“的编码人员。
以下是我看完此书的一些笔记，做个小记。
- 持续重构：无论什么时候看到坏味道的代码，重构它，不要以”怕影响线上功能“为理由，如果想保证代码的高质量，只有不断的，无情的重构。同时，为了能保证重构前后代码的等效性，完备的测试代码是必不可少的。
- 练习编码：就像运动员需要训练、棋手需要对弈一样，程序员需要不断练习。这里的练习不是找尚未解决的问题，而是重复地练习固定的题目，只求越来越熟悉，直到训练出编写固定题目再无任何冗余动作的地步。它旨在练习手指和思路，还有工具的熟练程度。TDD、算法、固定起手式，都可以练习。并且练习可以结对进行，比如一人写测试用例，一人写实现，二者交换角色。这有助于练习结对编程。
- 对于工时预估：不可能准确的，但是专业的编码人员能识别延期的风险，最大限度告诉外界，给外界正确的预期。所以，我们要：
- 大胆说不，完成不了的时候，强硬的说完不成，只能做到预期功能的几分之几
- 要求告知工时的时候，区分 ”承诺“和”预估“ 能完成的时间，承诺必须遵守，而预估是一个可以不断修正的模糊值。
- 讲工时拆分，拆开为乐观估计、一般估计、悲观估计，三者综合考虑，或者仅仅考虑一般估计和悲观估计的加权平均(4:1)
- 如果发现进度落后，不要一个人低头烦躁，赶进度。告诉别人，让别人知道自己当前的状态，风险提前暴露
- 更多关于工时预估， 对于工时的估计，于以下几种方式
- PERT:对乐观估计、标称估计、悲观估计按照 1：4：1 的比例求算数平均((最差 + 4*标称 + 最好)/6)，统计计算标准差( (最差-最好情况)/6)，工时偏差是平均值得一个标准差到两个标准差范围。
- 打扑克方式：在敏捷开发过程中，迭代会上，对于同一个任务，所有成员出牌告知自己对任务的预估时间，如果大家预估时间偏差不大，则采纳之，否则讨论之。
- 讲工时拆分，对于小任务的预估更容易准确，所以先把任务拆分，分别估算时间，然后组装。
- 不要在状态不佳的时候写代码
- 不要进入心流状态–(本条存疑，作者是不赞同心流状态写的代码是好代码的)
- 关于TDD：TDD不是花一天时间写测试，再花一天时间写代码，如此反复。而是先写10分钟测试，写刚好让测试跑通的代码，再写下一部分测试，如此反复。TDD事关 重构的验证和高质量的代码，有效性毋庸置疑
- 关于会议：对于和自己关系不大或者 会中发现和自己关系不大的会议，选择不去 以及会中离开
- 立会：一个人一分钟，回答三个问题：昨天做了什么、今天要做什么、遇到了什么问题
- 开发过程中的陷阱：
- 死胡同：即走不通的技术道路，比如技术选型有问题，解决问题的思路有问题，死胡同可以快速意识到，意识到之后就要赶紧回头
- 泥潭：即 也许可以走通，但是会花很大力气的技术道路，泥潭的杀伤力要比死胡同更大，因为在解决问题的过程中，泥潭总给人一种 ”我能解决“的 微弱希望，直到花费了很多很多精力。要训练条件反射 识别泥潭。
- 关于面对压力：应对压力最好的方式就是避免压力，从一开始避免压力的产生。如果无法避免，在受压期间，坚持一般时候自己的行为方式，一般时候自己坚持TDD，受压期间继续TDD，不要在过程中变形。
- 关注业务：作为程序员，除了关注自己的代码写没写完，还要关注业务，解决公司业务面临的问题，老板其实是为解决问题付钱，不是为代码付钱。
- 程序员的培养体系：医生、工匠都有自己的培养体系，但是程序员很奇怪，很多时候靠自觉来自我提升。这样对程序员，对公司人才建设都不好。建议通过结对编程、code review方式，将经验丰富的编程人员的能力传承下去。
- 在多个系统，使用过多种语言工作过经验丰富的大师，除了管理和架构建设之外，还可负责对熟练工的督导。
- 精力充沛，一般只了解一种语言、一个平台的熟练工，已经有了较高的变成素养，但是对架构尚缺乏经验，他们是编程的主力，在接受大师的督导之外，他们还可以贴身指导进入行的学徒。
- 刚刚入行的学徒，前几年就是要亦步亦趋，接受来自于熟练工的 关于设计原则，模式、重构等思想和编码实操的最佳实践。
- 如上，结对编程往往是个好方法。
- 不要以项目组建团队，尤其不要让不是一个团队的人，投一部分精力，在同一个项目中(eg：这个项目不太复杂， 你投半个人，支持一下隔壁组的开发工作)。这种模式，注定团队是散的，没有凝聚力的。要用团队管理项目。