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 帮助他人
三项法则
- 在写好失败单元测试前，不要写任何产品代码；
- 一旦单元测试失败了，就不要写测试代码；
- 产品代码只需要恰好能够让当前失败的单元测试通过即可，不要多写。
优势
- 确定性；对代码的掌控程度高。
- 缺陷注入率；降低代码的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. 辅导、实习生和技艺
辅导：
- 通过书籍手册向作者学习
- 通过观察他人工作来学习
实习生：
- 技术方面你的传授、培训、督导和检查
技艺：
- 技艺的模因包含价值观、原则、技术、态度和正见
- 技艺的模因经由口口相传和手手相承而来