第一章 专业主义

• 了解领域知识
  软件开发人员必须精通的知识：
  • 设计模式 GOF中的24种，POSA中的实战经验
  • 设计原则 SOLID原则，组件设计原则
  • 方法 Scrum、精益、看板、瀑布、结构化分析、结构化设计 等
  • 实践 测试驱动开发、面向对象设计、结构化编程、持续集成、结对编程
• 学习和练习
  • 读书、看文章、参加技术大会、参与讨论小组
  • 做一些简单的练习，让手指习惯点击快捷键或者习惯的使用某些重构技法。把这些当做 热身练习 或者 静心过程
• 合作
  • 尝试与他人一起编程、一起练习、一起设计，从彼此身上学到东西
  • 独处的时间也很重要
• 了解业务领域
  • 有义务了解自己开发的解决方案对应的业务领域
  • 开始一个新领域的项目时，应该读一两本该领域相关的书，了解该行业的原则和价值观念
  • 要理解业务 为什么 那样规定

第二章 说不

• 专业人士敢于说明真相而不屈从于权势

• 试试看

  • 许诺 尝试，意味着你承认自己之前未尽全力，承认自己还有余力可施，意味着只要你再加把劲还是可以达成目标的；而且这也是一种表示你将再接再厉去实现目标的承诺。因此，只要你许诺自己会去 尝试，你其实是在承诺你会确保成功

第三章 说是

• 做出承诺包含三个步骤：口头上说自己将会做；心里认真对待做出的承诺；真正付诸行动

• 逃避承担责任倾向的几个词：需要/应当 希望/但愿 让我们

• 真正的许诺： 我将在……之前完成……

• 几个没做到承诺的原因

  • 之所以没成功，是因为我寄希望于某某去做这件事
    你只能承诺自己能 完全掌控 的事情，如果最终目标依赖于他人，那么你就应当采取些具体行动，接近最终目标

• 之所以没成功，是因为我不太确信是否真能完成得了
  即使目标无法完成，你仍能全力前进，离目标更近些。比如发布前无法修复的bug，可以和QA一起努力重现这些bug，并在本周可支配的时间，尝试逐一修复

• 之所以没成功，是因为有些时候我真的无能为力
  因为有些事情事前的确没有预料到，但是如果你仍然希望自己不负众望，那就赶紧去调整别人对你的预期，越快越好！
  如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越早越好。你越早向各方利益相关方发出预警信号，整个团队就越有可能抓住机会，并重新评估当前的活动，并决定是否采取措施或者作出改变

• 如何说是

  • 试试的另一面，可以回答是，但是同时可以措辞更清楚的表达自己的不确定性

• 坚守原则

  • 不能放弃自己的底线，比如不写测试，不做完整的回归测试，代码的清晰整洁

• 专业人士对自己的能力极限了如指掌。他们十分清楚自己还能保持效率加班多长时间，也非常明白要付出的代价

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

第四章编码

1. 做好准备

• 我最糟糕的代码，是凌晨3点写出来的。
  在经过18个小时高强度的编码之后（还不算上每周工作60~70小时），我已经想不出更好的解决方案了。我记得，当时对自己能够胜任长时间工作感觉非常良好。我记得那种献身工作的感觉，自己当时认为，凌晨三点还在忘我工作是多么专业的表现啊。当时错的实在离谱！那些代码后来回过头来一遍又一遍的肆虐我们……
  这个故事给我们的教训是：疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指 要遵循纪律原则 而非成长为长时间的工作狂。要确保自己已经将睡眠、健康和生活方式调整到最佳状况，这样才能做到在每天的8小时工作时间内全力以赴。
• 焦虑时写的代码
  这时产出的任何代码都会是垃圾，因此此时应该先解决焦虑情绪。
  当然有许多焦虑无法再一两个小时内便能解决，而且老板也无法长期容忍我们因为要解决个人问题而不投入工作。关键所在是要学会如何关闭后台进程，或至少要能够降低其优先级，这样焦虑就不会造成持续的干扰。
  理想情况下，应该使用个人时间去解决个人问题。专业开发人员善于合理分配个人时间，以确保工作时间段中尽可能富有成效。

2. 流态区
   很多程序员在编写代码是会进入的一种意识高度集中但思维事业却会收拢到狭窄的状态。在这种状态下，他们会感到 效率极高；在这种状态中，他们会感到绝无错误。
   但是，我们要 避免进入流态区。这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种浅层冥想的状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。
   在流态区，你可能可以敲出更多的代码，其实可能没有估计全局，因此你很可能会做出一些后来不得不推倒重来的决策。在流态区写代码可能会快一些， 但是后面你将不得不更多的回头重新审视这些代码。
   当我感觉到自己将要滑入流态区时，就会走开几分钟，换换脑筋。

• 音乐
  音乐有可能有助于你编写代码，也有可能将你们带入流态区
• 中断
  粗暴相对的回应方式通常都是因为流态区所致。被他人从流态区中拉出来，或者当你正努力进入流态区却被其他人干扰时，你可能都会十分生气。不管哪种情况，粗暴方式都与你如何看待刘流态区相关。
  有时候并非是因为流态区，而只是你正在努力理解一些十分复杂的东西，这要求你必须全神贯注。
  中断无法避免，总有干扰会打断你、消耗你的时间。发生这种情况时要记住一点，也许下次也会轮到你去打断别人请求帮助。因此，礼貌的表现出乐于助人的态度才是专业的态度。

3. 阻塞
   有时候死活就是写不出代码来，通常会去找一些其他事情干；或者有一个结伴编程的小伙伴
   创造性输出 依赖 创造性输入，比如悬疑小说，诗，科幻小说等等
4. 调试
   测试驱动开发 会显著的降低调试时间，作者大约只有原来的十分之一
5. 保持节奏
   软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。无论是赛前还是赛中，马拉松选手都会仔细调整好自己的身体状态。专业程序员也会同样仔细的保存好自己的精力和创造力。

• 知道何时应该离开一会
• 开车回家路上
• 洗澡

6. 进度延迟

• 管理延迟的诀窍，便是早期检测和保持透明。
  • 最糟糕的情况是，你一直都在告诉每个人你会按时完成工作，到最后期限来临之前你还在这样说，但最终你只能让他们大失所望。相反，要根据目标定期衡量进度，使用三个考虑到多种因素的期限：乐观预估、标称预估、悲观预估。把全部三个数字呈现给团队和利益相关者，并每天修正这些数字
  • 不要盲目冲刺。 如果可怜的开发人员在压力之下最终屈服，统一尽力赶上截止日期，结局会十分悲惨。那些开发人员会开始抄近路，会额外加班加点工作，抱着创造奇迹的渺茫希望。这是制造灾难的最佳秘诀，因为这种做法给自己、给团队以及利益相关方带来了一个错误的期望。这样每个人都可以避免面对真正的问题，把做出必要的艰难决定的实际不断后延。
  • 加班确实有用，而且有时候也有必要。有时候，通过一天工作是个小时再加上周末加班一两天，你确实能够达到原本不可能的进度。但是这么做的风险也很高。在额外加班20%的时间内，其实你并无法完成20%的额外工作。而且如果连续两三个星期都要加班工作，则加班的措施必败无疑。
  • 最糟糕不专业行为就是明知道还没有完成任务却宣称已经完成。我们自欺欺人的认为任务已经完成的足够好，然后转入下一项任务，我们自己给自己找借口说 ，其他还没来得及完成的工作可以等有更充裕时间的时候再来处理。这种做法具有传染性 。如果一个程序员这么做，其他程序员看见了也会消防。这些人中肯定会有人把“完成”的标准压的更低，后面其他人将会采用新的定义……可以通过创建一个确切定义的完成标准来避免交付失误

7. 帮助
   帮助他人 以及 接受他人的帮助

第五章 测试驱动开发 （很难做到……）

• TDD 的三项法则
  • 在编好失败单元测试之前，不要编写任何产品代码
  • 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种测试情况
  • 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写
• TDD的优势
• 确定性：通过测试的产品确信可以被交付
• 勇气：拥有一套值得新来的测试，可以打消对修改代码的恐惧！
  当程序员不再惧怕整理代码时，他们便会动手整理！整洁的代码更易于理解，更易于修改，也更易于扩展，代码更简洁了，缺陷也更少了。

第九章 时间管理

• 会议
  关于会议，有两条真理：1）会议室必需的； 2）会议浪费了大量的时间

• 拒绝
  受到邀请的会议没有必要全部参加，你应该理智的使用时间，谨慎的选择应当参加哪些，礼貌拒绝哪些。
  邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。

• 离席
  会议并不总是按计划进行的。有时候你正参加某个会议，但是发现如果之前对此会议知道的多一点，就不会来。还有时候，会议临时增加了一体，或者某个讨厌的家伙霸占了讨论。这些年来，我学到了一条简单规则：如果会议让人厌烦，就离席。
  仔细管理自己的时间是你的责任。如果你发现参加某个会议是在浪费时间，就应当像个礼貌地办法退出来。如果必须出席，可以选个恰当的时间来问问大家。你可以解释说 ，自己抽不去更多时间用于这场会议，问问有没有办法加快讨论，或者另选时间。
  重要的是，你应当明白，继续待在会议室是浪费时间；继续参加对你没有多大意义的会议，是不专业的行为。因为你有责任合理分配老板给你的时间和金钱，所以，选个格式的机会商量如何离席，并非不专业的做法。

• 确定议程和目标
  为了合理使用有用的时间，会议应当有清晰的议程，确定每个议题所化的时间，以及明确的目标。
  如果收到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长时间，要取得什么成果。如果得不到确切的答案，你可以礼貌拒绝。
  如果你已经出席会议，但发现已经偏离或者是放弃了原有议程，你应当要求详细列出新的议题和议程。如果没有答案，也应当在合适的时候礼貌离席。

• 争论/反对
  凡是不能再5分钟内解决的争论，都不能靠辩说解决。争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。
  技术争论很容易走入极端。每一方都有各种说法来支持自己的观点，知识缺乏数据，在没有数据的情况下，如果观点无法在短时间内达成一致，就永远无法达成一致。
  唯一的出路是，用数据说话

  • 提高嗓门、近距离对视、摆出不屑的姿态，这都不重要，长期来看，强力是无法解决争论的，最终还是需要数据；
  • 有人同意结束争论后，消极的对待结果，拒绝为解决问题出一份力。他们会安慰自己说：“既然其他人想要这么办，那就这么办吧” 这可能是非专业行为中最糟糕的了。千万不要这么做，如果你同意了，那就必须拿出行动来。
  • 如果问题解决了，这个选择就是对的。如果遇到了麻烦，你可以退回来选择另外一条路。明智的做法是，选定一个时间点或者设定一系列标准，来决定什么时候放弃。
  • 要小心这类会议：他们的目的是发泄情绪，或者让大家战队，如果会议上只有一面之词，就要避免参加。
  • 如果争论必须解决，就应当要求争论各方在5分钟时间内向大家摆明问题，然后大家投票，这样，整个会议花的时间不会超过15分钟。

• 注意力点数

• 睡眠 专业的开发人员会安排好他们的睡眠， 保证清晨有饱满的注意力点去上班

• 咖啡因 对于某些人来说，适量的咖啡因可以帮他们更有效的使用注意力点数

• 恢复 在你不集中注意力的时候，注意力点数可以缓慢恢复。漫步一段长路，与朋友聊天，看看窗外，都有助于恢复。 我发现，一旦注意力点数耗尽，你就没办法控制注意力。你仍然可以写代码，但是多半需要第二天重写，或者几周之后备受这段代码的煎熬。所以更好的办法还是花30到60分钟换换脑子

• 肌肉注意力 搏击、太极、瑜伽之类体力活动使用的注意力是不同的。即便需要全神贯注，这种注意力也不同于编程时的注意力，因为他们需要的是肌肉的注意力，而编程需要的是心智的注意力

• 时间拆分和番茄工作法

• 25分钟之内，不要让任何事情打扰你的工作，如果有人来打断你问问题，礼貌的问他能否过25分钟之后再来问。毕竟，几乎没有事情会紧急到25分钟都等不了。等25分钟一过，停下手头的工作，去处理这25分钟内遇到的其他事情，然后休息五分钟。然后再设定25分钟，开始一个新的番茄时间段。每完成4各番茄时间段时间，休息半小时。（可以参考其他书籍）

• 重要的事情是，番茄时间是有生产率的，你可以真正做点事情。用于应付干扰、参加会议、休息等非工作事宜的时间，属于非番茄时间

• 不错的情况下你每天可以有12_{14个番茄时间段，糟糕的只有2}3个

• 番茄工作法的真正好处在于，在25分钟的高效工作时间内，你有底气拒绝任何干扰

• 要避免的行为

• 优先级错乱

  • 无论什么原因，我们都可以找到办法逃避真正的工作。你说服自己有些工作更紧急，所以转去处理，这种行为叫做优先级错乱--提高某个任务的优先级，之后就有借口推迟真正急迫的任务。优先级错乱是自我麻醉的谎言，因为不能面对真正需要做的事情，所以我们告诉自己，其他事情更重要。我们知道这不是真的，但还用它来欺骗自己。
  • 其实这不是在欺骗自己：我们真正做的是在准备谎言--如果有人问自己在做什么事情，为什么这么做，我们就会摆出这些谎言。我们是在为他人对自己的判断寻找理由和借口。显然，不是专业的行为，专业开发人员会评估每个人物的优先级，排除个人的喜好和需要，按照真实的紧急程度来执行任务。

• 死胡同

  • 比如你做了决定，选择了而走不通的技术道路。你对这个决定越是坚持，浪费的时间就越多。如果你认为这关系到自己的专业信誉，就永远也走不出来。
  • 慎重的态度和积累的经验可以帮你避免某些死胡同，但是没法完全避免所有的。所以你真正需要的是，在走入死胡同时可以迅速意识到，并有足够的勇气走回头路。这就是所谓的 坑法则： 如果你掉进了坑里，别挖！
  • 专业开发人员不会执拗于不容放弃也无法绕开的注意。他们会保持开放的头脑来听取其他意见，所以即使走到尽头，他们仍然有其他选择。

• 结论
  专业开发人员会用心管理自己的时间和注意力。他们知道优先级错乱的诱惑，他们也珍视自己的声誉，所以会抵制优先级错乱。他们 永远有多种选择，永远敞开心扉听取其他 解决方案，他们从来不会执拗于某个无法放弃的解决方案。他们也时刻警惕着正在显露的泥潭，一旦看清楚，就会避开。最糟糕的事情，莫过于看到开发人员在徒劳的拼力工作 ，结果却陷入越来越深的泥潭。

第十章 预估

预估是软件开发人员面对的最简单、也是最可怕的活动之一了。预估影响到的商业价值巨大，关乎声誉，也给我们带来了很多的苦恼和挫折。预估是业务人员和开发人员之间最主要的障碍，横亘在双方之间的种种不信任，几乎都由它引发。
业务方觉得预估就是承诺，开发方觉得预估就是猜测，两者相差迥异。

• 承诺

• 承诺是必须做到的。如果你承诺在某天做成某事，就必须按时完成。即便他意味着你必须每天工作12个小时，放弃周末的休假，也不得不如此。既然承诺了，就必须兑现。

• 专业开发人员不随便承诺，除非他们确切知道可以完成。道理就是这么简单。如果你被要求承诺做自己不确定的事情，那么就应当坚决拒绝。如果要求你承诺在某天完成，但是需要每天加班，周末加班，取消休假，那么最后的决定取决于你；不过，不要违背自己的意愿去勉强。

• 预估

• 预估是一种猜测。它不包含任何承诺的色彩。它不需要做任何约定。预估错误无关声誉。我们之所以要预估，是因为不知道到底要花多长时间。

• 不幸的是，大多数软件开发人员都很不擅长预估。这不是因为他们没有掌握关于预估的诀窍--根本没有这样的诀窍。预估的偏差总是很大，原因在于我们并不理解预估的实质。

• 预估不是个定数，预估的结果是一种概率分布。不要只看到可能性最高的那个数字 ，而要估计最大的数字。

• 总结
  专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下，他们才会给出承诺。此外，他们也会小心避免给出暗示性的承诺。他们会尽可能清楚地说明预估的概率分布，这样主管就可以做出合适的计划。

• PERT Program Evaluation and Review Technique

  • O 乐观预估，为了保证乐观预估有意义，这个数字对应的概率应该小于1%
  • N 标称预估，这是概率最大的数字
  • P 悲观预估，这是最糟糕的数字，也应该小于1%
    平均时间 = (O + 4N + P) / 6
    标准差 = (P - O) / 6

• 大数定律
  预估是非常容易出错的，所以才叫做预估。控制错误的办法之一是使用大数定律。该定律的意思是：把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确的多。这样做之所以能提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。
  坦率的说，这也是比较乐观的想法。预估中的错误通常会被低估而不是高估，所以拆分再加总很南做到完美。不过，把大任务拆分成小任务分开预估，仍然是个好办法。有些错误会被忽略，而且拆分成小任务也更利于理解任务本身及其他意外因素。

第十一章 压力

• 避免压力
  在压力下保持冷静的最好方式，便是规避会导致压力的处境。规避的方式也许无法完全减除压力，但是可以大大降低压力，并缩短高压力期的时间

• 承诺
  业务方总是期望能够拿到这些承诺，因为他们想消除风险，我们要做的就是是风险定量化并将他们陈述给业务方，这样他们就能做好相应的准备。做不切实际的承诺会阻碍目标的实现，对公司和个人都没好处。有时有人会代我们做出承诺。比如业务人员可能在没有事先咨询我们的情况下就像客户做出了承诺。发生这种事情时，处于责任感我们必须主动帮助业务方找到方法来兑现这些承诺，但是一定不能接受这些承诺。
  专业人士总会千方百计的帮助业务方找到达成目标的方法，但并不一定要接受业务方代为做出的承诺。最终，如果我们无法兑现业务方所作出的承诺，那么该由当时做出承诺的人来承担责任。

• 保持整洁
  快速前进确保最后期限的方法，便是保持整洁。专业人士不会为了快点前进而乱来。他们明白 快速但脏乱 是自相矛盾的说法，脏乱只会导致缓慢！

• 危机中的纪律
  观察自己在危机时刻中的反应，就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律，就说明你确实相信那些纪律。反过来说，如果在危机中改变行为，就说明你并不真正相信常规行为中的原则。
  如果平常时候你会注意保持代码整洁，但在危机时刻你却会产出会乱的代码，说明你并不真正相信混乱会导致速度下降。
  选择那些你在危机时刻依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律。遵守这些纪律原则是避免陷入危机的最好途径。
  当困境降临时，也不要改变行为。

• 应对压力

• 不要惊慌失措
  呆坐着烦躁不安也于事无补，而你可能会烦的最严重的错误，就是鲁莽仓促！ 要避免产生孤注一掷的想法。鲁莽仓促只会把你带入更深的深渊。

• 沟通
  让你的团队和主管知道你正深陷困境之中。告诉他们你所制定的走出困境的计划，请求他们的支援和指引。避免制造意料之外的诧异。

• 依靠你的纪律原则
  当事情十分困难时，要坚信你的纪律原则。之所以你会将之奉为纪律，是因为他们可以指引你度过高压时期。这时候要更加留意全部的纪律原则，这不是质疑或者无端放弃他们的时候。

• 寻求帮助
  结对！结对伙伴会帮助你坚守原则纪律，防止你手足失措。搭档会捕捉住你疏忽遗漏的事情，会提出有帮助的想法，会在你注意力迷失的时候接过你手中的工作继续前进。

• 结论
  应对压力的诀窍在于，能回避压力时尽可能的回避，当无法回避时则勇敢直面压力。可以通过慎重承诺、遵循自己的纪律原则、保持整洁等来回避压力。直面压力时，则要保持冷静，与别人多多沟通，坚守自己的原则纪律，并寻求他人的帮助。

第十二章 协作

对做的事情充满激情是好的，但是最好把注意力集中在付我们薪水的老板所追求的目标上。
专业程序员的首要职责是满足雇主的需求。这意味着要和你的经理们，业务分析师们，测试工程师们和其他团队成员很好的协作，深刻理解业务目标。这并不是说你必须成为业务方面的老学究，而是说你需要理解手上正在编写的代码的业务价值是什么，了解雇你的企业将如何从你的工作中获取回报。
专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问。你的工作职责就要让业务免于陷入困顿，让公司可以长久发展下去。
因此，专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。
简而言之，他们会将注意力放在如何与业务同舟共济上