《程序员的职业素养》读书笔记

目录

引言

        成功的程序员在以往的工作和生活中都曾经历过大大小小的不确定性，承受过永无休止的压力。他们之所以能够成功，是因为拥有一个共同点，都深切关注创建软件所需的各项实践。他们将软件开发视为一种需要精雕细琢加以修炼的技艺，他们以专业人士的标准要求自己，他们具有职业素养。

        在你过去的工作中，你遇到的问题可能很容易也可能很难，但实际上最重要的并不是问题的难度，而是解决问题的方式、步骤以及反思的深度。职业素养它强调的并不是天赋的神秘，也不是技艺的高深，而是持续积淀的结晶：一方面，它体现了能力和素质；另一方面，它又强调了持续的积累和养成。作为职业开发人员，基本技能不够熟练，当然谈不上职业素养。如果只会迅速地编写代码，却不关心代码背后的意义，不能迅速判断、解决程序运行中的各种问题，不能自信满满地为自己交付的程序承担责任，同样是与职业素养绝缘的 —— 许多所谓的 “高手”，其实正是缺乏职业素养的典型。

第一章 – 专业主义

        “专业主义” 有很深的含义，它不但象征着荣誉与骄傲，而且明确意味着责任与义务。这两者密切相关，因为从你无法负责的事情上不可能获得荣誉与骄傲。

担当责任

        如果你不小心放过了某个模块里的一个bug，以致公司出现了资损。非专业人士会耸耸肩说：“状况总是难免的嘛。” 然后像没事人一样继续写下一个模块，而专业人士会主动承担责任。实际上，专业主义的精髓就在于将公司利益视同为个人利益。

首先，不行损害之事

不要破坏软件功能

        开发的软件有 bug 会损害软件的功能。因此，要做得专业，就不能留下bug。会有人认为软件开发太复杂了，不可能没有bug。但这并不能为你开脱。就像人体这么复杂，不可能尽知其全部，但医生仍誓言不伤害病人。
        没人能写出完美的软件，但这并不表示你不用对不完美负责。专业人士需要练习的第一件事就是 “道歉”。道歉是必要的，但还不够。你不能一而再、再而三地犯同样的错误。你有责任让你的失误率无限接近零。
        作为开发人员，你需要有个相对迅捷可靠的机制，以此判断所写的代码可否正常工作，并且不会干扰系统的其他部分。

不要破坏结构

        聪明人不会为了发布新功能而破坏结构。结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必追悔莫及。        
        所有软件项目的根本指导原则是：软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。

职业道德

了解你的领域

下面列出了每个专业软件开发人员必须精通的事项

• 设计模式：必须能描述GOF书中的全部24种设计模式且有实战经验
• 设计原则：必须了解SOLID原则，且需要深刻理解组件设计原则
• 设计方法：必须理解结构化分析以及结构化设计方法等
• 实践：必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程
• 工件：必须了解如何使用UML图、结构图、流程图等

坚持学习

软件行业的飞速发展，意味着软件开发人员必须坚持广泛学习才不至于落伍。
这里推荐以下几种学习方式：

• 广泛阅读技术书籍以及技术文章
• 参加技术大会
• 学习多种编程语言

练习

        业精于勤。真正的专业人士往往勤学苦干，以求得自身技能的纯熟精炼。Bob大叔常用的一个技巧是重复做一些简单的练习，如 “保龄球游戏” 或 “素数筛选” 【可以理解为一些简单的程序算法题】

合作

        专业软件开发人员往往会更加努力地尝试与他人一起编程、一起练习、一起设计、一起计划，这样他们可以从彼此身上学到很多东西，而且能在更短的时间内更高质量地完成更多工作。 

辅导

        想迅速牢固地掌握某些事实和观念，最好的方法就是与由你负责的人交流这些内容。专业人士会视辅导新人为己任，他们不会放任未经辅导的新手乱打乱撞。

了解业务领域

        每位专业软件开发人员都有义务了解自己开发的解决方案所对应的业务领域。你未必需要成为该领域的专家，但你仍需要勤勉，付出相当的努力来认识业务领域。
         在开始一个新领域的项目时，应当读一两本该领域相关的书，还应当花时间与业内人士交流，了解他们的原则与价值观念。

客户至上

        要将客户的问题化作自己的问题，你必须弄明白并寻求最佳的解决方案。站在客户的角度思考问题，确保开发的功能真正能满足客户的需求。

谦逊

        任何时候都不要自负，时刻保持谦逊。要对自己的能力充满信心，并勇于承担有把握的风险。
        不要嘲讽别人犯下的错误，一笑了之吧，因为下一个犯错的可能就是你自己。

第二章 – 勇于说 “不” 

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

高风险时刻

        最要说 “不” 的是那些高风险的关键时刻。越是关键时刻，“不” 字就越具价值。

要有团队精神

        具备团队精神，意味着恪尽职守，意味着当其他队员遭遇困境时你要援手相助。有团队精神的人会频繁与人交流，会关心队友，会尽最大可能地做到尽职尽责。 

试试看

        “尝试” 一词有许多定义。或是 “一种积极的举动”，又或是 “付出额外的精力”。许诺 “尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。许诺 “尝试”，意味着只要你再加把劲还是可以达成目标的。

第三章 – 说 “是”

前面学会了说 “不”，但是，学会如何说 “是” 也同样重要。

说 “是” 的成本

        大多数时间，我们都希望能够说 “是”。确实，健康的团队都会努力寻求给他人以肯定的答复。运作良好的团队的经理和开发人员，会相互协商，直至达成共同认可的行动方案。

承诺用语

做出承诺，包含三个步骤

• 口头上说自己将会去做
• 心里认真对待做出的承诺
• 真正付诸行动

识别 “缺乏承诺” 的征兆

        在承诺做某事时，应当留意自己的用词，这些词透露了我们对待承诺的认真态度。实际情况当然不只是注意在我们所说的话中是否有某几个词这么简单。

        以下示例中包含的几个用词和短语，会透露 “缺乏承诺” 的蛛丝马迹，要注意搜寻。

•         需要/应当：“我需要把活做完”
•         希望/但愿：“我希望程序运行没有bug”
•         可能/应该：“我可能在xx日前能完成任务” 

真正的承诺

        识别真正承诺的诀窍在于，要去搜寻与下列相似的语句：我将在 ··· 之前 ··· （如：我将在周二之前完成这个任务。）
        这句话的关键在于你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。那不是指别人，而是说的自己。你谈的是自己会去做的一项行动，而且，你不是可能去做，或是可能做到，而是会做到。
        这时，你的措辞已经转变到 “承诺” 模式了，之后便要继续走完下面两个步骤：

        言必行，行必果。

小结

        今天的程序员肯定得去面对诸如估算、确定最后期限以及面对面交流等沟通活动。做出承诺或许听来令人有点害怕，但它能够帮助程序员解决在沟通中可能发生的不少问题。如果你能一直信守承诺，大家会以为你是一名 “严谨的开发人员”。 
        专业人士不需要对所有请求都回答 “是”。不过，他们应该努力寻求创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用承诺用语，以确保各方能明白无误地理解承诺内容。

第四章 – 编码

        编码是一项颇具挑战也十分累人的智力活动。相比其他类型的活动，编码要求更加聚精会神。因为在编码时你必须平衡互相牵制的多种因素。

四项挑战

        首先，代码必须能够正常工作。必须理解当前要解决的是什么问题以及该如何解决。必须确保编写的代码忠实遵循解决方案。必须管理好解决方案的每一处细节，并且使语言、平台、现有架构以及当前系统的所有问题和平共处。
        代码必须能够帮你解决客户提出的问题。很多时候，客户提出的需求其实并没能真正解决他们自己的问题。这有赖于你去发现这些问题并及时与客户进行交流，以确保代码能够满足客户的真实需求。

        代码必须要能和现有系统结合得天衣无缝。你的代码不能让系统变得更僵硬、更易碎、更晦涩，必须要妥善管理好各种依赖关系。简而言之，编写代码时必须遵循稳健的工程原则。

        其他程序员必须能读懂你的代码。这不仅包括要写好注释这类事，还包括要精心锤炼代码，使它能够表达你的编程意图。要做到这点很不容易。事实上，这可能是程序员最难精通的一件事。

不要带着焦虑写代码

        如果你内心焦躁不安，这时根本不应该编写代码，而应该先解除焦虑情绪。当然，有许多焦虑无法在一两个小时内解决，而且老板也无法长期容忍我们因为要解决个人问题而不投入工作。
        关键所在是要学会如何关闭后台进程，或至少要能降低其优先级，这样焦虑就不会造成持续的干扰。

避免进入 “流态区”

        这是程序员在编写代码时会进入一种意识高度专注但思维视野却会收拢到狭窄的状态。在这种状态下，他们会感到 “效率极高，绝无错误”。
        在流态区，你可能可以敲出更多的代码。你会收获一种愉悦感或征服感。问题在于，在流态区状态下，你其实没有顾及全局，因此，你很可能会做出一些后来不得不推倒重来的决策。所以，请尽量避免进入 “流态区”。

理性面对中断

        中断无法避免，总有干扰会打扰你、消耗你的时间。发生这种情况时请记住，也许下次也会轮到你去打断别人请求帮助。因此，礼貌地表现出乐于助人的态度才是专业的态度。

阻塞

        有的时候，死活就是写不出代码来。这时候，通常需要去找一些其他事情干。去查看邮件或者读点文档。不必死盯着屏幕，干坐在那里。 

导致阻塞的原因 

• 睡眠
• 焦虑
• 恐惧
• 沮丧
  
  解决办法：找一个结对编程搭档。
  这个方法很有效也很神奇。当坐到别人旁边的时候，本来挡住去路的问题忽然就会消失了。你是能真切感知到这种变化的，这种变化能帮助你冲破阻塞继续前进。

调试 

        衡量你是否是一名专业人士的一个重要方面，便是看你是否能将调试时间尽量降到最低。绝对的零调试时间是一个理想化的目标，无法达到，但要将之作为努力方向。
        医生不喜欢打开病人的胸腔去修复此前犯下的错误。律师不喜欢再度接手此前搞砸的案子。同样，软件开发人员也不喜欢为自己埋下bug的软件返工。

保持节奏

        软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。无论是赛前还是赛中，马拉松选手都会仔细调整好自己的身体状态。专业程序员也会同样仔细地保存好自己的精力和创造力。 

知道何时应该离开一会儿

        当碰到困难而受阻时，当你感到疲倦时，就离开一会儿，让富有创造力的潜意识接管问题。精力分配得当，你将能在更短的时间内以更少的精力完成更多的事情。让自己保持好节奏，让团队保持好节奏。了解你的创造力和智力运行的模式，充分发挥它们的优势而非与之背道而驰。

进度延迟

        你总有一天会遭遇延迟的情况。即使是最优秀的程序员、最敬业的员工，也不能避免碰到延迟。有时候，则只是因为我们预估时过于乐观夸下了海口，最后延迟的情况无可避免。 

切勿盲目冲刺

        如果经理极力要求你尽力赶上最后截止期限，你需要坚决维持你的估算！唯一能够加快进度的方法便是缩减范围。
        如果在压力之下最终屈服，同意尽力赶上截止日期，结局会十分悲惨。那些开发人员会开始抄近路，会额外加班加点工作，抱着创造奇迹的渺茫希望。但需要明白一点，额外加班20%的时间无法完成20%的额外工作。这是制造灾难的最佳秘诀，因为这种做法给自己、给团队以及利益相关方带来了一个错误的期望。这样每个人都可以避免面对真正的问题，把做出必要的艰难决定的时机不断后延。

正确定义 “完成” 避免交付失败

        在程序员所能表现的各种不专业行为中，最糟糕的是明知道还没有完成任务却宣称已经完成。或是我们自欺欺人地认为任务已经完成得足够好，然后转入下一项任务。如果一个团队陷入此种误区之中，管理者听到的将是诸事顺利。所有的状态报告表明，每个人的工作完成得都很准时。这就像是一群盲人坐在铁轨旁边野餐：没有人能够看见满载未完成工作的火车马上将会把他们压垮，而等他们发现时，一切都已经来不及了。
        避免交付失败的最好方法是通过创建一个确切定义的 “完成” 标准。例如让业务分析师和测试人员创建一个自动化的验收测试，只有完全通过这些验收测试，开发任务才能算已经完成。

帮助

        编程很难，事实上，仅凭一己之力无法写出优秀的代码。即使你的技能格外高超，也肯定能从另外一名程序员的思考与想法中获益。

帮助他人

        将自己封闭在格子间或者办公室里与世隔绝，有悖于专业的职业精神。你的工作不可能重要到你不能花一丁点儿时间来帮助别人。事实上，作为专业人士，要以能够随时帮助别人为荣。
        帮助别人的时候，可以坐下来和他一起写代码，不要让自己看起来十分仓促，仿佛只是随便应付，要全情投入到任务中。当你离开时，可能会发现自己从中收获的东西比给予的还要多。

接受他人的帮助

        如果有人向你伸出援手，要诚挚接受，心怀感激地接受帮助并诚意合作。不要死命护着自己的地盘拒绝别人的帮助。 
        要学会如何请求帮助。当你受阻时，或者有点犯晕时，或者只是绕一个问题绕不出去时，不妨请求别人的帮助。

第五章 – 测试驱动开发

测试驱动开发（TDD）意味着编程需要先写测试程序。谁会这么做呢？先写单元测试？谁会做这么蠢的事呢？

TDD的优势

确定性

        在TDD的开发模式下，任何时刻，一旦修改了工程中的任何部分，只需再次运行全部的单元测试即可。如果单元测试全部通过，差不多就可以确信修改没有破坏任何东西。

勇气

        这是TDD最强大之处。用有一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。当看见糟糕的代码时，就可以放手整理。代码会变得具有可塑性，你可以安全地将之雕琢成简单而满意的结构。 

文档

        单元测试即是文档。它们描述了系统设计的最底层设计细节。它们清晰准确，以读者能够理解的语言写成，并且形式规整可以运行。它们是最好的底层文档。 

设计

        测试代码的一个问题是必须隔离出待测试的代码。如果一个函数调用了其他函数，单独测试它通常会比较困难。为了编写测试，你必须找出将这个函数和其他函数解耦的办法。换言之，测试先行的需要，会迫使你去考虑什么是好的设计。

TDD的局限

        尽管TDD有诸多优点，但是它既非宗教信仰，也非魔力公式。即使做到了测试先行，仍有可能写出糟糕的代码。因为写出的测试代码可能就很糟糕。 

第六章 – 练习

        专业人士都需要借助专门训练提升自己的技能，无一例外。乐手练习音阶，球员练习绕桩，医生练习动手术和缝针，律师练习论辩，士兵练习执行任务。如果重视最终的成绩，专业人士就会选择练习。

卡塔

        在武术里，卡塔是一套设计好的、用来模拟搏斗一方的招式。目标则是要逐步把整套招式练习到纯熟。习武者努力训练自己的身体来熟悉每一招，把它们连贯成流畅的套路。训练有素的卡塔看起来相当漂亮。 
        与之类似，编程卡塔也是一整套敲击键盘和鼠标的动作，用来模拟编程问题的解决过程。练习者不是在解决真正的问题，因为你已经知道了解决方案。相反，你是在练习解决这个问题所需要的动作和决策。
        编程卡塔的最终目标，也是逐步练习以达到纯熟。反复的练习会训练大脑和手指如何动作和反应。在不断练习当中，你或许会发现动作的细微进步，或者解决问题效率的小幅提升。

瓦萨

        瓦萨基本可以说是两个人的卡塔。其中的招式需要精确地记忆，反复演练。一个人负责攻，另一个人负责守。攻守双方互换时，各种动作要一而再、再而三地重复。 

自身经验的拓展

        职业程序员通常会受到一种限制，即所解决问题的种类比较单一。经验不够丰富的程序员，履历和思维中都存在某种贻害无穷的盲区。经常可以看到这样的情景：程序员发现，面对行业的周期性变化造成的新局面，自己并没有做好准备。 

开源

        保持不落伍的一种方法是为开源项目贡献代码，就像律师和医生参加公益活动一样。开源项目有很多，为其他人真正关心的开源项目做一点贡献，应该可以算是提升技能的最好办法了。 

第七章 – 验收测试

        验收测试这个名词用得太多太泛了。有人认为，验收测试就是在接受正式发布之前由用户执行的程序，也有人认为它是QA测试。验收测试可以定义为业务方与开发方合作编写的测试，其目的在于确定需求已经完成。

沟通

需求的沟通

        开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西，程序员按照自己理解的业务方表达的需求来开发。至少从理论上来说，应该是这样。但在现实里，关于需求的沟通是及其困难的，其中会出现各种问题。 

       专业开发人员既要做好开发、也要做好沟通。“输入糟糕，输出也会糟糕” 对程序员同样适用，所以职业程序员会重视与团队及业务部门的沟通，确保这种沟通的准确、流畅。

过早精细化

        做业务的人和写程序的人都容易陷入一个陷阱，即过早的进行精细化。业务方还没有启动项目，就要精确知道最后能得到什么；开发方还没有评估整个项目，就希望精确知道要交付什么。

“完成” 的定义

        不同的团队对 “完成” 的定义各不相同。专业开发人员的 “完成” 只有一个含义：完成，就是完成。完成意味着所有的代码都写完了，所有的测试都通过了，QA 和需求方已经认可。这，才是完成。

自动化测试

        验收测试都应当自动进行。在软件开发的周期中，确实有时候需要手动测试，但是验收测试不应当手工进行，原因很简单：要考虑成本。

测试的协商与被动推进

        写测试的人也是普通人，也可能犯错误。有时候你刚开始实现某个功能，就会发现有些测试没什么意义。有些太复杂，有些不灵活，有些包含愚蠢的假定，还有些干脆就是错的。身为专业开发人员，与编写测试的人协商并改进测试是你的职责。

验收测试和单元测试

        验收测试是测试方写给业务方的。它们是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。而单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。

        它们的主要目的是如实描述系统的设计、结构、行为。它们真正的价值并不在测试上，而在具体指标上。

持续集成

        请务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。整套持续集成系统应该由源代码管理系统来触发。只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试。

第八章 – 测试策略

        专业开发人员会测试自己的代码。但是，测试并不就是写一些单元测试或者验收测试那么简单。编写这些测试只是万里长征的第一步。每个专业的开发团队都需要一套好的测试策略。

自动化测试金字塔

单元测试

        在金字塔底部是单元测试，这些测试由程序员使用与系统开发相同的语言来编写，供程序员自己使用。编写这些测试的目的是在最低层次上来定义系统。
        单元测试可以做到接近100%的覆盖率，通常而言这个数字应该保持在90%以上。

组件测试

        组件测试是验收测试的一种，它们是针对系统的各个组件而编写的。系统的组件中封装了业务规则，因此对这些组件的测试便是对其中业务规则的验收测试。
        组件测试差不多可以覆盖系统的一半，它们更主要测试的是成功路径的情况以及一些明显的极端情况、边界状态和可选路径。

集成测试

        集成测试是编排性测试，它们并不会测试业务规则，而是主要测试组件装配在一起时是否协调。它们是装配测试，用以确认这些组件之间已正确连接，彼此间通信畅通。

系统测试

        系统测试是针对整个集成完毕的系统来运行的，自动化测试是最终的集成测试。它们不会直接测试业务规则，而是测试系统是否已经正确组装完毕，以及系统各个组件部件之间是否能正确交互。在这个层次的测试集中，应该包含吞吐率测试和性能测试。

人工探索式测试

        这是需要人工介入、敲击键盘、盯牢屏幕的测试。它们既非自动化的测试，亦非脚本化的测试，这些测试的意图是需要在验证预期行为的时候，探索系统预期之外的行为。

第九章 – 时间管理

        8小时其实十分短暂，只有480分钟，28800秒。身为专业开发人员，你肯定希望能在这短暂的时间里尽可能高效的工作，取得尽可能多的成果。

会议

拒绝 

        受到邀请的会议没必要全部参加，参加的会议太多，其实只能证明你不够专业，你应该理智的使用时间，所以必须谨慎选择应当参加的一些会议，礼貌拒绝哪些会议。邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你，所以如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实一些显著的成效，否则不必参加。

离席

        会议并不总是按计划进行的，有时候你正参加某个会议，但是发现如果之前对此会知道的多一些就不会来。再说一次，仔细管理自己的时间是你的责任，如果你发现参加某个会议是在浪费时间，就应当想个礼貌的办法退出来。

确定议程和目标

        如果收到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长时间要取得什么成果，如果得不到确切的答案，你可以礼貌拒绝。

迭代计划会议

        迭代计划会议用来选择在下一轮迭代中实现的开发任务，在会议召开前务必完成两项任务。评估可选择任务的开发时间，确定这些任务的业务价值。如果组织得足够好，业务验收组件测试也应当在会议召开前完成，或者至少要有概略方案。

注意力点数

        编程是需要持续投入精力和注意力的智力活动，注意力是稀缺的资源，它类似魔力点数，如果你用光了自己的注意力点数，必须花一个小时，或更多的时间做不需要注意力的事情来补充它。
        注意力点数也会随时间流逝而减少，如果不及时使用，它们就会消失。会议之所以具有巨大的破坏力，原因之一就在于此，如果你所有的注意力点数都用在了会议上，编程时就大脑空空了。

睡眠

        睡眠的重要性再怎么强调都不为过，美美一觉醒来，注意力点数是最充裕的，好好睡上七个小时。你将有足够的注意力点顺序做好八个小时的工作，专业开发人员会安排好他们的睡眠，保证清晨有饱满的注意力点数去上班。

咖啡因

        毋庸置疑，对有些人来说，适量的咖啡因可以帮他们更有效的使用注意力点数。但是请小心，咖啡因也会给你的注意力添乱，太多的咖啡因会把你的注意力转到奇怪的方向，太浓的咖啡会搞得你一整天都沉溺于不重要的事情。

恢复

        在你不集中注意力的时候，注意力点数可以慢慢恢复。漫步一段长路，与朋友聊天，看看窗外都有助于恢复注意力点数。有些人选择沉思反省，也有些人选择小睡一会儿，还有人选择听博客。或者翻翻杂志。

肌肉注意力

        肌肉注意力有助于改善心智注意力，而且不仅仅是简单的恢复。定期训练肌肉注意力，可以提升心智注意力的上限。

避免进入死胡同和泥潭

死胡同

        所有软件开发者都要遇到死胡同，比如你做了决定，选择了走不通的技术道路。你对这个决定越是坚持，浪费的时间就越多。如果你认为这关系到自己的专业信誉，就永远也走不出来。慎重的态度和积累的经验可以帮你避免某些死胡同，但是没法完全避免所有的。所以你真正需要的是在走入死胡同时，可以迅速意识到，并有足够的勇气走回头路。这就是所谓的 “坑” 法则：如果你掉进了坑里，别挖。

泥潭

        比起死胡同更糟的是泥潭，泥潭会减慢你的速度，但不会让你彻底停下来，泥潭会阻碍你前进，但如果使尽全力，你仍然可以取得进展，之所以说泥潭比起死胡同更麻烦，因为在泥潭中你仍然可以看到前进的道路，而且看起来总是比回头路要短。
        如果发现自己身处泥潭还要固执前进，这是是最严重的优先级错乱。继续沉浸无异于欺骗自己，欺骗团队，欺骗公司，欺骗客户。你一边带大家走向炼狱，一边告诉其他人所有问题都会解决。

小结

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

第十章 – 预估 

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

什么是预估

        预估是一种猜测，它不包含任何承诺的色彩，它不需要做任何约定，预估错误无关声誉，我们之所以要预估，是因为不知道到底要花多少时间。
        不同的人对预估有不同的看法，业务方觉得预估就是承诺，开发方认为预估就是猜测，两者相差迥异。

承诺

        承诺是关于确定性的，其他人会把你的承诺当真，据此拟定计划，如果不能兑现承诺，他们的损失以及你的声誉受到的影响都是巨大的，承诺不能兑现也是欺骗，只不过比公然的欺骗好一点。

大数定律

        预估是十分容易出错的。控制错误的办法之一，就使用大数定律。该定律的意思是把大任务分成许多小任务，分开预估在加总，结果会比单独评估大任务要准确很多。这样做之所以能够提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。

小结

        专业开发人员懂得如何为业务人员提供可信的预估结果，以便做出计划。如果做不到或者不确定能做到专业开发人员不会给出承诺。

第十一章 – 压力

避免压力

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

保持整洁

        让系统代码的设计尽可能整洁，就可以避免压力。这并非是说我们要花无穷无尽的时间去清理代码，而只是说不要容忍混乱。混乱会降低速度，导致工期延误，承诺失信。因此，要尽力保持输出成果整洁干净。

危机中的纪律

        观察自己在危机时刻中的反应，就可以了解自己的信念，如果在危机中依然遵循着你守持的纪律，就说明你确实相信那些纪律。反而来说如果你在危机中改变行为，就说明，你并不真正相信常规行为中的原则。
        当困境降临时，也不要改变行为。如果你遵守的纪律原则是工作的最佳方式，那么即使在深度危机中也要坚决秉持这些纪律原则。

应对压力

        能遇见压力、转移压力和消除压力是很好的。但是有时候不管你多么千方百计的求防患于未然，依然会有压力降临到你头上。有时候项目周期就是比任何人此前所预计的要长，有时候原始设计就是有错误，必须返工。

不要惊慌失措

        正确应对压力，长夜漫漫，无心睡眠，无助于更快的解决问题。干坐着烦躁不安也于事无补。而你可能会犯的最严重的错误就是鲁莽仓促，要避免产生孤注一掷的想法，鲁莽仓促只会把你带入更深的深渊。
        相反，要放松下来，对问题深思熟虑，努力寻找可以带来最好结果的路径，然后沿着那条路径以合理稳定的节奏向前。

沟通

        让你的团队和主管知道你正深陷困境之中，告诉他们你所制定的走出困境的最佳计划，请求他们的资源和指引，避免制造意料之外的麻烦。

小结

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

第十二章 – 协作

        大多数软件都是由团队开发出来的，当团队成员能够十分专业的互相协作时，整个团队是最为高效的，单打独落与游离于团队之外都是不专业的表现。

程序员与Boss

        专业程序员的首要职责是满足 Boss 的需求。就意味着你要和你的经理们、业务分析师们、测试工程师们和其他团队成员有很好地协作，深刻理解业务目标。
        专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛了也不闻不问，你的工作职责就是要让业务避免陷入困顿，让公司可以长久发展下去。

程序员与程序员

        专业人士结对工作，因为这是分享知识的最好途径。专业人士并不会仅凭一己之力从零开始创建知识，而是通过互相结对来学习系统的不同部分和业务。他们明白，尽管每位团队成员都有自己的位置，但是在紧要关头，每位团队成员也要能够接替其他人的位置。

第十三章 – 团队与项目

有凝聚力的团队

        形成团队是需要时间的，团队成员首先需要建立关系，他们需要学习如何互相协作，需要了解彼此的癖好、强项和弱项，最终才能凝聚成团队。有凝聚力的团队，他们可以一起创造奇迹，他们互为知己，能够替对方着想，互相支持，激励对方拿出自己最好的表现，他们攻无不克。
        团队比项目更难构建。因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是最好的做法。并且，团队也可以同时承接多个项目，在组建团队时，要给予团队充足的时间让他们形成凝聚力，一起共同工作，成为不断交付项目的强大引擎。    

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

        学校能够传授的是计算机编程的理论，但是学校并不会也无法传授作为一名编程匠者所需要掌握的原则、实践和技能。这些东西只有经由师徒个体间多年的细心监督和辅导才能获得。软件行业必须要面对这一事实，下一代软件开发人员成熟起来的重任无法寄希望于大学教育，建立一种包含学徒期，实习期和长期指引的机制也是迫在眉睫。