《代码整洁之道》笔记

1. 专业主义

1.1 担当责任

1.2 不行损害之事

(1)不要破坏软件功能,让失误率无限接近于 0

  • 让测试人员找不出问题
  • 不发布无把握的代码
  • 反思 bug 怎么越过测试
  • 确信代码正常运行(自动化测试、单元测试)
  • 自动化 QA

(2)不要破坏结构

  • 不为了发布新功能破坏代码的结构
  • 软件要易于修改(需要使用测试保证代码可经常修改)

1.3 职业道德

职业发展需要保证每周有自己的时间

  • 领域知识(设计模式、设计原则、方法、实践、工件)
  • 坚持学习(文章、博客、技术大会)
  • 练习(每天一到两道题)
  • 合作
  • 辅导
  • 了解业务领域(了解基础架构、基本知识、原则和价值观念)
  • 站在用户的角度思考
  • 谦逊

2. 说“不”

能就是能,不能就是不能。不要说“试试看”。

作为专业人士,就不应该什么事都照做

2.1 对抗角色

面对艰难的决定,直面不同角色的冲突是最好的办法——找到可能的最好结果

“为什么”其实并没有那么重要

2.2 高风险时刻

在高风险时刻说不,是对大家负责

2.3 团队精神

  • 不说谎,做出合理预期
  • 如果是“试试看”,那就代表之前留有余力。本质上是在说谎,可能是为了护住面子和避免冲突
  • 不消极对抗,不能任由事态发展

2.4 如何写出好代码

坚守专业主义精神,说不

3. 说“是”

3.1 承诺用语的三个阶段

  • 口头上说。缺乏承诺,通常是“需要、但愿、让我们”等
  • 心里认真。有清晰的事实陈述,明确说明了期限
  • 真正付诸行动。

3.2 如何做到“言必信,行必果”

  • 如果目标依赖于他人,就应该采取具体行动,推动最终目标
  • 即使感觉目标无法完成,也要弄清楚目标是否能够达成
  • 如果做不到,就应尽早向承诺对象发起预警

3.3 如何说“是”

不说“试试”,直接说出所有的可能性

坚守原则

4. 编码

4.1 编码需要考虑的问题

  • 代码正常工作
  • 解决客户提出的问题——不是需求,需求不一定能解决问题
  • 和现有的系统能很好的结合
  • 其他程序员可以读懂你的代码
  • 不要在疲劳或者焦虑的时候编码

4.2 流态区

这种状态下,感觉效率极高、绝无错误

避免进入流态区,因为这样会进入“放弃顾及全局”的陷阱

4.3 思路阻塞

  • 找个搭档结对编程
  • 创造性输入(PPT、音乐、电影等)

4.4 调试

调试和编码一样重要

TDD 可以减少调试时间

4.5 保持节奏

在疲劳的时候应该离开工作

回家路上把自己从工作中抽离出来

洗澡时或许会浮现解决方案

4.6 关于进度延迟

  • 不盲目期望提前完成
  • 不盲目冲刺(可以考虑所有情况,缩减交付的范围)
  • 加班(需要保证有个人有时间、短期加班、有加班失败的后备预案)
  • 交付失误时不自欺欺人
  • 定义一个确切的“完成”标准(自动化验收测试)

4.7 帮助他人

  • 帮助他人的时候不应付
  • 学会接受他人的帮助,学会请求帮助
  • 辅导与寻求辅导

5. 测试驱动开发

三项法则

  • 在写好失败单元测试前,不要写任何产品代码;
  • 一旦单元测试失败了,就不要写测试代码;
  • 产品代码只需要恰好能够让当前失败的单元测试通过即可,不要多写。

优势

  • 确定性;对代码的掌控程度高。
  • 缺陷注入率;降低代码的 bug 和风险。
  • 勇气;测试完备,修改或者重构的风险降低。
  • 文档;单元测试即示例,清晰准确。
  • 设计;迫使自己考虑好的设计。

6. 练习

6.1 练习方式

kata

练习解决这个问题所需要的动作和决策

学习热键和导航操作、测试驱动开的、持续集成之类的方法

wasa

两个人的 kata,一个人写单元测试,另一个人写程序

自由练习

多人参与的 wasa

6.2 拓展经验的方法

开源

使用自己的时间练习

7.验收测试

7.1 需求的沟通

不要过早精细化需求

  • 不确定原则(观察者效应):观察到的新信息会影响对整个系统的看法
  • 预估焦虑:需求一定会变化,追求早期的精准性是徒劳的

迟来的模糊性:需求文档中的模糊之处,都对应着业务方的分歧

7.2 验收测试

“完成”的含义

  • 所有的代码写完了
  • 测试通过了
  • QA 和需求方已经认可

沟通:开发方、业务方、测试方达成共识

自动化:缩减成本

测试并不是额外工作

验收测试与开发应当不是同一个人编写

开发人员的角色是把验收测试和开发系统联系起来保证测试的通过

不能被动接收测试,需要协商并改进

验收测试和单元测试:内部 vs 外部

图形界面和其他复杂因素:调用 API 而不是 GUI

持续集成:失败应立刻终止

8. 测试策略

自动化测试金字塔:

  • 单元测试:在最低层次上定义系统。
  • 组件测试:对业务规则的验收测试。
  • 集成测试:装备测试,确认组件之间正确连接,彼此通信畅通。
  • 系统测试:测试系统是否正确组装完毕,以及各个组件之间是否正确交互,同时包括吞吐量测试和性能测试。
  • 人工探索式测试:确保系统在人工才操作表现良好。

9. 时间管理

9.1 会议

学会拒绝/离席,确定议程和目标,立会,迭代计划会议,争论与反对

凡是不能在五分钟内解决的争论,都不能靠辩论解决。
唯一的出路是:用数据说话。可以做试验、模仿或者建模。

9.2 注意力点数

学会安排时间,妥善使用自己的注意力点数

睡眠/咖啡/恢复/肌肉注意力/输入和输出

9.3 时间拆分和番茄工作法

记录下来并画图展示

9.4 要避免的行为

优先级错乱——提高某个任务的优先级,有借口推迟真正急迫的任务

9.5 死胡同

不执拗于不容放弃也无法绕开的主意,听取其他意见。越是坚持,浪费的时间越多。

9.6 泥潭

走回头路是最简单的办法。

发现身处泥潭还固执前进,是最严重的优先级错乱。

10. 预估

10.1 什么是预估

承诺还是猜测?

预估是一种猜测,不包含任何承诺的色彩。不是一个定数,是一种概率分布。

小心给出暗示性的承诺。

10.2 PERT(计划评审技术)

乐观预估(1%),标称预估(概率最大),悲观预估(1%)

得出任务的期望完成时间和任务的概率分布标准差(不确定性)

10.3 预估任务

德尔菲法:

  • 亮手指:预估相近达到统一,有分歧则讨论
  • 规划扑克
  • 关联预估:多人对任务进行所需时间长短的排序,讨论分歧,任务归类
  • 三元预估:使用德尔菲法分别进行乐观、标称、悲观预估

10.4 大数定律

控制错误的方法——把大任务分成小任务,分开预估在加总,结果会比单独评估大任务要准确的多

11. 压力

11.1 避免压力

避免对没有把握能够达成的最后期限做出承诺

让系统、代码和设计尽可能整洁

在危机时也要遵守纪律原则(例如 TDD)

11.2 应对压力

不要惊慌失措:深思熟虑,努力寻找可以带来最好结果的方法

沟通:告诉你制定的走出困境的计划,请求支援和指引

坚信纪律和原则

寻求帮助:结对编程

12. 协作

首要职责是满足雇主的需求,和团队协作,深刻理解业务目标,了解企业如何从你的工作中获得回报

拥有代码的是整个团队,而不是个人

专业人士会共同工作,彼此面对面。

13. 团队和项目

形成团队需要时间。建立关系,学会互相协作,了解彼此的癖好和长短处,最后凝聚成为团队。

把项目分配给已经形成凝聚力的团队,而不是围绕项目组建团队。

14. 辅导、实习生和技艺

辅导:

  • 通过书籍手册向作者学习
  • 通过观察他人工作来学习

实习生:

  • 技术方面你的传授、培训、督导和检查

技艺:

  • 技艺的模因包含价值观、原则、技术、态度和正见
  • 技艺的模因经由口口相传和手手相承而来