2018-04-27 《程序员的职业素养 - The Clean Coder》

本文主要是介绍2018-04-27 《程序员的职业素养 - The Clean Coder》，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：[美] Robert C. Martin
翻译：章显洲 余晟
https://book.douban.com/subject/11614538/

---

第一章 专业主义

1.1 清楚你要什么

专业主义的精髓在于将公司利益视同个人利益。所以犯错不是“在所难免的”，而是应当极力避免，并勇于承担后果。

1.2 担当责任

1.3 不行损害之事

1. 不破坏软件功能
   让QA找不出问题，而不是让QA帮忙检查
2. 确信代码能正常运行
   要考虑单元测试，测试覆盖率，测试驱动开发（TDD）
3. 自动化QA
4. 不破坏结构
   所有软件项目的根本指导原则是：软件要易于修改。
   不破坏结构并不表示尽量少修改代码，相反，如果期望自己的软件灵活可变，就应该时常修改它。
   事实是，大多数开发人员不敢不断修改代码，因为害怕改坏了。这里就又回到上面的“自动化测试”，如果有自动化测试，并且测试覆盖率也很高，那么就不会害怕改坏了。

1.4 职业道德

职业发展是个人的事情，雇主没有义务考虑这些，也没有义务给你培训，送你参加会议等等。

职业道德是：
1. 你自己要计划每周工作的时间，比如60小时，其中40小时是给雇主的，剩下的20小时是给自己做提升使用。
2. 了解你的领域
工作中涉及到的东西都要去了解，否则只能写写 if-else, while 之类的代码了。

以下是每个专业软件开发人员必须精通的事项：
设计模式：GoF 书中（设计模式）的23种模式
设计原则：必须了解SOLID原则，而且要深刻理解组件设计原则
方法：XP、Scrum、精益、看板、瀑布、结构化分析、结构化设计等
实践：TDD、OOP、结构化编程、CI&CD&CD、结对编程
工件：UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图、决策表

坚持学习
坚持练习（业精于勤）
合作
辅导（教学相长）
了解业务领域（熟悉行业背景，不能全按照规格说明去编码，而是要能够辨别、质疑一些需求）
与雇主/客户保持一致
谦逊（每个人都会犯错，所以不要嘲笑别人，自己出错了能坦然接收别人的嘲笑）

第二章 说“不”

能就是能，不能就是不能。不要说“试试看”。 - 尤达

这一章介绍了“专业程序员要竭尽所能地追求和捍卫自身的目标，从而会和管理者产生对抗”，“高风险时刻更应该说不”，“团队精神是为整体目标着想，而不是试试看”。而这些前提都是开发人员人员能够做到较好的项目排期，并且有理有据地对管理者说“不”，同时也不能总说不，否则就是能力问题了。

第三章 说“是”

3.1 承诺用语

口头上说、心理认真、付诸行动。

“缺乏承诺的”的征兆：
1. 我们要。。。
2. 我需要。。。
3. 。。。应当。。。
4. 让我们。。。
5. 希望。。。
6. 但愿。。。

真正的承诺：我将在（时间点）之前完成（某个任务）
言必行行必果，如果没做到的话，要如何应对呢？
1. 之所以没成功，是因为我寄希望于某某去做这件事。
2. 之所以没成功，是因为我不太确信是否真能完成得了
即使目标无法完成，也能全力前进，离目标更近。
3. 之所以没成功，是因为有些时候我真的无能为力。
突发事件出现后，尽快去调整别人对你的预期（越快越好）。

总结：估算日期、确定最后期限、交流沟通等等，做出承诺会令人害怕，但是可以建立个人的信誉（reputation）。

3.2 学习如何说“是”

1. “试试”的另一面
   
2. 坚守原则
   首先，测试、文档、代码整洁性这些是不能够省略的，因为省略这些也不能保证更快完成。多年的经验是，打破这些纪律和原则，更会拖慢进度。
   然后，尝试说服管理者确实无法做到，可以找
   最后，如果实在不行，必须要做到，也得给自己争取利益，不管是加人也好、调休也好。

3.3 总结

专业人士不需要对所有请求都回答“是”。不过，应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用承诺用语，以确保各方能够明白无误地理解承诺内容。

第四章 编码

4.1 做好准备

编码要求聚精会神，要避免：
1. 心烦意乱时写代码
2. 疲劳时写代码（比如加班，凌晨3点）
3. 焦虑时写代码

4.2 流态区

其实就是效率很高的状态。
但是这种状态其实是一种”浅层冥想”状态，敲出的代码会增多，但是理性思考就少了。
结对编程的好处在于任何一方都不会进入流态区。

4.3 阻塞

写不出来的时候要学会调整状态。做些事情，而不是死盯着屏幕。

4.4 调试

4.5 保持节奏

也就是调整状态。

4.6 进度延迟

4.7 帮助他人

第五章 测试驱动开发

TDD不光是一种技巧，也是一种思维方式。
三大原则：
1. 编好失败单元测试之前，不要编写任何产品代码。
2. 只要有一个单元测试失败了，就不要再编写代码；无法通过编译也是一种失败情况。
3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多谢。

这样测试代码、产品代码、测试代码、产品代码。。。同步增长，互为补充。

5.3 TDD的优势

1. 确定性
   单元测试通过了，对产品就有把握了。
2. 降低缺陷注入率
3. 勇气
   有助于重构、修改糟糕代码
4. 文档
   单元测试即文档。
5. 设计
   测试代码的一个问题是必须隔离出待测试的代码，这样有助于代码的解耦，也就有助于开发出更好的设计。
   （先写产品代码，很容易写出一大坨耦合的代码，不利于测试；先写测试代码就可以避免）
6. 专业人士的选择

5.4 TDD的局限

测试代码也可能很糟糕。。。
还有一些其他场景，不适合TDD
等等

第六章 练习

为开源项目贡献代码。

第七章 验收测试

7.1 需求的沟通

1. 避免过早精细化
   需求总会变化的，突发事件也总是会发生的，在这之前想要确定最终交付的一项项的功能，就有点浪费精力了。
2. 明确需求
   跟客户直接隔着一层又一层，就会导致信息的丢失，也就会导致对需求理解的偏差。

7.2 验收测试

1. 什么叫完成？
   QA + 需求方都确认了，才叫完成。
2. 沟通
3. 自动化
4. 额外工作
   5.验收测试什么时候写，由谁写
   业务方+QA > 业务分析员+QA > QA > Dev
   避免同一个人既写了代码又写了测试。
5. 测试的协商与被动推进
6. 验收测试和单元测试
7. GUI及其他因素
8. CI

7.3 结论

编写自动化的验收测试可以避免交流中的误解。

第八章 测试策略

8.1 QA应该找不到错误

QA和Dev是一个团队的，而不是对立的。

8.2 自动化测试金字塔

从下往上，覆盖率由高到低：
单元测试，组件测试，集成测试，系统测试，Web自动化测试，人工探索式测试。

第九章 时间管理

9.1 会议

1. 拒绝一些会议
2. 提前离席
3. 确定议程与目标
4. 站会（尽可能快）
5. 迭代计划会议
6. Retro
7. 争论/反对（争论之所以花费很多时间，是因为各方都拿不出有力的证据）

9.2 注意力（精力）

1. 睡眠
2. 咖啡因
3. 恢复
4. 肌肉注意力
5. 输入与输出

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 避免压力

1. 承诺
2. 保持整洁
3. 危机中的纪律

11.2 应对压力

1. 不要慌张
2. 沟通
3. 依靠纪律原则
4. 寻求帮助

11.3 结论

能回避压力的时候尽可能回避，无法回避时则勇敢直面压力。
可以通过慎重承诺、遵循自己的纪律原则、保持整洁来回避压力。
直面压力时，保持冷静，多与人沟通，坚持原则，寻求他人帮助。

第十二章 协作

12.1 程序员与人

1. 与雇主
   多了解业务
2. 与程序员
   互相学习、互相帮助

12.3 结论

编程就意味着与人协作，与人交流。

第十三章 团队与项目

13.1 只是简单的混合吗

1. 有凝聚力的团队
2. 如何管理有凝聚力的团队
3. 项目承包人的困境

13.2 结论

团队比项目更难构建。因此，组件稳健的团队，接手一个又一个的项目，整体移动，形成凝聚力，不断磨合，一直共同工作，成为不断交付项目的强大引擎。

第十四章 辅导、学徒期与技艺

14.1 失败的学位教育

14.2 辅导

14.3 学徒期

14.4 技艺

14.5 结论

学校传授的是计算机编程的理论，还缺少原则、实践、技能。需要软件行业中的每一代人去引导下一代人。

读后感

这本书的内容本身就很务虚，作者通过大量的、大段的举例说明，来描述他想要表达的思想。
而这些思想又不是各自独立的，分为十四个章节，相互交织在一起，导致一些重复（比如多次提到需要沟通，还有关于测试，团队协作，团队精神等等），所以显得有些混乱。
同时这十四个章节涵盖的面又有些广，从个人技能到与人协作，再到辅导、学徒，稍显零散。

不过可以看出，这些思想是作者经年累月的宝贵的人生经验，还是可以让读者在多个方面产生共鸣的。
记住这些经验，在工作中时刻提醒自己，一定可以有所收获的。

简单地总结一下：
1. 提高预估、排期的能力，从而可以从容地说“不”，说“是”，提高个人的声誉，减小压力；
2. 沟通交流，不仅要与业务方交流业务，还要与管理者交流进度，还要与其他程序员交流技术，互相帮助；
3. 管理好时间，不光是工作上，减少无意义的会议、管理精力、排好优先级、避免死胡同和泥潭，还要给自己保留提升个人技艺的时间，勤加练习；
4. 建立个人的原则，例如不轻易承诺、保持整洁、不能为了工期而削减测试代码等等，这些纪律也可以帮助你说“不”，说“是”，以及应对压力；
5. 团队凝聚力是完成项目的前提；
6. 怎么才算完成？开发人员要做到自己测试没问题，然后再交给QA，等QA和业务方都确认后才算完成。
不是说代码写完了就完了的。

做到了上面的这些，才能算作专业人士，才能算是具有程序员的职业素养！

P.S. 虽然本身很务虚，但也通过大量的举例，提出了一些务实的建议和方法，比如：
1. 多了解技能领域：设计模式、设计原则、方法、实践、工件等
2. 编码是一项脑力+体力劳动，所以需要身体做好准备，要避免疲劳、焦虑时编码
3. 时间管理里，减少会议时间、减少无意义的争论（让数据说话）
4. 预估任务时，（1，2，3，5，8），拆分任务再预估
5. 项目交付快要失败前，及时沟通，降低别人的期望，保护你自己的声誉，也减小你的压力

这篇关于2018-04-27 《程序员的职业素养 - The Clean Coder》的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---