最近读了《程序员的职业素养》，对其中两章《专业主义》，《预估》 颇有感触： 我所遇到过的优秀程序员大都符合专业主义的要求：专业人员会为事情负责，而非专业人士只会说状况在所难免

做了思维导图与大家分享。（图片和文章正文皆由思维导图导出

程序员的职业素养.png

本书要回答的问题

什么是专业开发人员（Professionialism）？

专业开发人员怎么工作？

专业开发人员怎么处理冲突，应对很紧的工期，如何和不切实际的管理人员打交道？

专业开发人员合适说不，怎么说？

专业开发人员怎么应对压力

专业主义

清楚你要什么

• 专业主义不但象征着荣誉与骄傲，也明确意味着责任与义务。两者息息相关，因为你无法负责的事情上不可能获得荣誉与骄傲
• 非专业人士搞砸一件事，只会说状况是难免的，然后打住没有后续
  而专业人士自己会为那件事的损失买单

担当责任

• 作者在做一个项目时，为节省时间且风险小忽略了一项测试，导致放出软件有故障。这种行为就是不负责任

  在我身上，这个现象应该相当频繁。。

不作恶

• 不要留下bug

• 程序提测后的代码应当找不出bug，不要把QA当成除虫机器

• 确信代码能正常运行--单元测试！

• 不要破坏结构--无情重构

  • 理想情况，每提交一次代码就要让它比上次检出时变得更为简洁
  • 需要有自动化测试保底才有信心无情重构

职业道德

• 自己做好时间规划，终身学习

  • 将自己的职业发展寄希望于雇主的程序员未来会很惨
  • example: 你应该每周计划工作60小时，40小时留给雇主，20小时留给自己
  • 如果你不愿勤勉，也不能称之为专业人士

• 了解你的专业

  • 了解Mealy和Moore这两种状态机的差别吗？了解变化分析（Transform Analysis）吗？ 不了解的话，为何不去了解下

  • 旧见解不会过时，那些50年中来之不易的理念，绝大多数在今天仍像过去一样富有价值

    • 桑塔亚纳的诅咒： “不能铭记过去的人，注定重蹈前任的覆辙”

• 程序员必须精通知识

  • 设计模式

    • GOF

  • 设计原则

    • SOLID原则

  • 软件工程

    • XP，Scrum，精益，看板，结构化分析

  • 实践

    • TDD，OOP，devops，结对编程

  • 设计

    • UML，DFD，结构图，状态迁移图表，流程图，决策图

• 坚持学习

  • 程序员必须坚持广泛学习才不至于落伍
  • 读书，看文章，博客，参加技术大会，读书小组，学习其他语言

• 练习

  • 只完成日常工作时不足以称为练习的，那只能算是执行性质的操作，而不是练习。练习指的是日常工作之余专门练习技能，以期自我提升。
  • 对程序员，什么是可以操练的？好像没有啊？但是你细想音乐家怎么掌握演奏技能的？程序员也一样，通过重复练习基本技能（kata）训练自己的手指跟意识。

• 合作

  • 结对编程，找个队友

• 辅导新人

  • 传道受业，导师也能收益

• 了解业务领域

  • 每位专业开发人员都有义务了解自己开发的解决方案所对应的业务领域
  • 最糟糕，最不专业的做法是： 简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。你应该对这一领域有所了解，能辨别，质疑规格说明书中的错误

• 与雇主保持一致

  • 雇主的问题就是你的问题，你必须搞明白这些问题
  • 开发人员之间相互认同是容易的，但把一方换成雇主，人们就容易发生分歧，专业人士会尽量避免这样的狭隘分歧

• 谦逊

  • 我们大胆的从混沌之中创建秩序，我们自信的发布准确无误的指令，稍有差错，机器的错误行为就可能造成无法估量的损失，因此，编程也是极其自负的行为
  • 发生问题时，专业人士会接受他人的嘲讽，也不会因别人犯错而横加指责，因为他知道，自己可能就是下一个犯错的人

说“不“

“能就是能，不能就是不能，不要说试试看”

对抗角色

• 经理要求明天完成任务，他在追求和捍卫一个目标，那是尽它的工作职责。如果你明知道不能完成还说试试看，就是你的失职乱

• 可能的最好结果是你和你的经理追求共同的目标，最关键的是找到共同目标，而这依赖于协商

  • 找出经理最在意的功能，削减其他需求

• 要解释为何需要这么长时间吗

  • 最好不要，有时候提供太多细节，可能导致更多的微观管理

高风险时刻

• 确定无法完成，不要委屈求全，等到deadline情况会更糟

团队精神

• 真正为团队努力的人，根据自己最好的能力状况，明确说明哪些是做得到的事，哪些是做不到的事

• 试试看

  • 意味着加把劲还是能完成任务的

    • 如果没能完成，就是你的过错

  • 尝试有多重定义

    • 付出额外的精力，设计新的方案

      • 你的想法

    • 意味着你承认之前未尽全力

      • pm的想法

  • 尝试~=说谎

    • 既没有新的方案，又不准备改变自己的行为，事事如前，那么尝试是什么呢？
    • 为了维护可怜的自尊

• 消极对抗

  • 损坏整个团队

说“是”的成本

• 讲述了一个有志程序员屈服于客户无尽的奇怪需求写入烂代码的故事

• 然而事实是

  • 主人公对客户做出了不切实际的承诺

    • 明知实际比听起来更复杂，还是接受了
    • 接受了后加的不合理需求
    • 连续加班

  • 他希望成为英雄人物

  • 应该对内心的渴望说不，杜绝为了按期完工，怎么快怎么来的想法

说“是"

承诺用语

• 口头上说

  • 口头上说自己会做

    • “天哪，我真该减减肥了“

• 心里认真

  • 心里认真对待做出的承诺

• 付诸行动

  • 真正付诸行动

• 不要轻信 别人会说到做到

• 承诺的用词透漏了我们的认真程度--识别缺乏承诺的征兆

  • 需要，应当，希望，但愿，让我们回头再见
  • 要么显的事情不再我的掌控范围，要么不愿意承担个人责任

• 真正的承诺

  • 自己能掌握的事情

  • 对自己将会做某件事做了详细的事情陈述，而且明确结束期限

  • 承诺未能做到的原因

    • 之所以没成功，是因为我寄希望于xx去完成这件事
    • 之所以没成功，是因为我不太确信是否真的能完成
    • 之所以没成功，是因为我真的无能为力

• 如果你不尽早告诉他人可能的问题，就错失了让他们帮助你达成目标，兑现承诺的机会。

• 做出承诺或许听来令人有点害怕，但他能帮助程序员解决在沟通中发生的不少问题

学习如何说“是”

• om询问能还是不能，你回答试试看，这就是错误的，最好给一个大致范围，不要模糊不清

• 坚守原则

  • 打破纪律和原则，必定拖慢进度
  • 口头上说周末加班很容易，真正做起来却很难

如何更好的工作

做好准备

• 平衡多种牵制的元素

  • 代码能够解决问题
  • 代码必须跟现有系统恰当结合
  • 代码必须可读

• 疲惫时不要再敲代码

  • bob又给自己发消息了

• 焦虑时不要敲代码

  • 时间分块，集中精力

避免进入心流状态

• 意识高度集中，思维视野收拢到狭窄
• 心流状态并非高效，也并非毫无错误
• 结对编程

卡住

• 不如试试结对编程

• 创造性输出

  • 依赖于创造性输入
  • 广泛阅读
  • 创造力激发创造力

调试

• 上古时代汇编，没有断点，没有日志，只能看内存数据
• 程序天然的认为调试时间不属于开发时间，但公司不会这么想
• 使用TDD“尽可能减少调试时间

保持节奏

• 知道何时要休息一会

  • 感到疲惫时不如先休息一会
  • 开车u时间
  • 洗澡

进度延迟

• 三种预估期限

  • 乐观预估
  • 标准预估
  • 悲观预估

• 最糟糕的情况是，你一直都在告诉每个人你会按时完成工作，到最后期限来临前你还在这样说，但最终你只能让他们大失所望

• eg. 10天后有一个展会，你的乐观，标准，悲观预估分别是8、12、20.那么你是绝不可能完成的

• 盲目冲刺

  • 不要经受不住诱惑盲目冲刺加班
  • 唯一能加快进度的方式是缩减范围

• 交付失误

  • 最糟糕的是明知道还没有完成任务却宣称已经完成

  • 常用的借口是： 其他还没有来得及完成的工作可以等有更充裕时间的时候再来处理

    • 慢慢的，完成的标准就被压低了

  • 最好的方式是创建一个自动化测试，只有完全通过这些验收测试，开发任务才算完成

帮助

• 帮助他人&接受他人帮助

TDD

三项法则

• 在编写失败单元测试前，不要编写任何产品代码
• 只要有一个单元测试失败了，就不要再写测试代码
• 产品代码恰好能够让当前失败的单元测试成功通过即可

TDD的优势

• 确定性

  • 任何时刻，代码有任何修改，都必须运行手头有的测试代码，如果没有报错就表示产品没有问题

• 降低bug率

  • 相当于提测前就解决了一些bug

• 勇气

  • 有TDD垫底，程序员会敢于改动代码

• 文档

  • 每个测试用例都是一个API用法说明

• 设计

  • TDD会迫使你去思考什么是好的设计

  • 后写的测试在深度和捕获错误的灵敏度要逊色很多

    • 后写的测试会为已有代码妥协

局限

• 并非银弹，游戏就不太适合

编程热身

编程柔道场

• 类似于多人在线刷leetcode

验收测试

需求的沟通

• 非专业人士不能认识要需求的复杂性

• 过早精细化陷阱

  • 双方都贪求不现实的精确性，而且经常愿意花大价钱来追求这种不确定性

  • 不确定原则

    • 每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法

  • 预估焦虑

    • 即使拥有全面准确的信息，评估也通常会存在巨大的变数，其次，因为不确定原则，不可能通过反复推敲实现早期的精确性

  • 迟来的模糊性

    • 需求文档中的每一点模糊之处，都对应着业务方的一点分歧

      • 有时候，业务方会想当然的认为看文档的人懂得自己的意思

验收测试

• “完成”的定义

  • 可以部署到生产环境
  • 可以提测
  • 写完代码并且跑通了，但还没有真正测试过

• 专业人士的完成只有一个含义： 完成，就是完成

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

• 额外工作

  • 不要把自动化测试看做额外的工作，应当成节省时间和金钱的办法

• 测试的协商和被动推进

  • 身为专业开发人员，你的职责是协助团队开发出最棒的软件，也就是说，每个人都要关心错误和疏忽，并协力改正

测试策略

QA应该找不到任何错误

自动化测试金字塔

• 单元测试
• 组件测试
• 集成测试
• 系统测试
• 人工探索式测试

时间管理

会议

注意力点数

要避免的行为

• 优先级错乱

  • 提高某个任务的优先级，之后就有借口推迟真正急迫的任务

• 坑法则

  • 如果你掉进了坑里，别挖

预估

什么是预估

• 业务方觉得预估就是承诺
• 开发方认为预估就是猜测

PERT

• 技术评审计划（Program Evaluation and Review Technique）

• 这种技术包含一种非常简单有效的办法，把预估编程概率分布

• 定义

  • 三种预估数字

    • 乐观预估O

      • 一切异常顺利，非常乐观的数字，为了保证乐观预估有意义，这个数字对应发生的概况应该小于1%

    • 标准预估N

      • 概率最大的数字，如果画一张柱状图，这个数字就是最高的那个

    • 悲观预估P

      • 最糟糕的数字，应当考虑到各种意外，比如飓风，核战争，其概率也应该小于1%

  • 任务的期望完成事件u

    • u=(O+4N+P)/6

      • eg （1+12+12）/6=4.2

  • 任务概率分布的标准差V

    • V=(P-O)/6
    • 用来衡量不确定性，数值越大越不确定

  • 总项目的期望完成事件U总

    • 各个任务u的总和

  • 总项目的标准差V总

    • 各个任务的标准差平方之和的平方根

大数定律

• 将大人物划分成小人物，分开估计再加总，能够有效减少误差

压力

避免压力

• 如果你遵守的纪律原则是工作的最佳方式，那么即使在深度危机中，也要坚决秉持这些纪律原则

应对压力

• 不要惊慌失措茫然四顾另寻依靠，而要从容不迫，专心致志的依靠你自己的纪律原则，这将帮助你更快走出困境

协作

程序员与雇主

• boss不关注bug如何有趣，如何修复。最好把目标关注到boss的目标上

程序员与程序员

团队

有凝聚力的团队

练级之路

XMind - Trial Version