程序员的职业素养

注：本文章为《代码整洁之道-程序员的职业素养》[Robert C.Martin]个人读书笔记，不代表个人观点，强烈推荐大家观看原书籍。

第一章 专业主义

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

   • 如果你不小心放过了某个模块里的一个 bug，以致公司损失了1万美元，结果将会怎呢？非专业人士会耸耸肩说：“难免要出点儿状况嘛。”然后像没事儿人一样继续写其他模块。而专业人士会自己为公司的那1万美元买单！

     哇，自掏腰包？那可真让人心疼唉！但专业人士就必须这么做。实际上，专业主义的精髓就在于将公司利益视同个人利益。看到了吧，”专业主义“就意味着担当责任。

3. 首先，不行损害之事
   1. 不要破坏软件功能
      1. 让QA找不出任何问题：
         • 发布软件时，你应该确保OA找不出任何问题。故意发送明知有缺陷的代码,这种做法是极其不专业的。什么样的代码是有缺陷的呢？那些你没把握的代码都是！且不说这么做是否会大幅增加公司成本，严重损害软件，是否会破坏计划并让企业对开发小组的信心打折扣，也不去评判这么做是否等同于懒惰失职，把自己没把握的代码发送给QA这么做本身就是不专业的。这违背了“不行损害之事”的原则。
         • 要确信代码正常运行
           • 怎么知道代码能否正常运行呢？很简单，测试！一遍遍地测，翻来覆去、颠来倒去地测，使出浑身解数来测！
           • 你或许会担心这么狂测代码会占用很多时间，毕竟，你还要赶进度，要在截止日期前工。如果不停地花时间做测试，你就没时间写别的代码了。言之有理！所以要实行自动化试。写一些随时都能运行的单元测试！然后尽可能多地执行这些测试。必须要保证测试能够百分之百覆盖你得代码！
         • 自动化QA
   2. 不要破坏结构
      • 成熟的专业开发人员知道，聪明人不会为了发布新功能而破坏结构。结构良好的代码更灵活。以牺牲结构为代价,得不偿失，将来必追悔莫及。所有软件项目的根本指导原则是，软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。
      • 如果你希望自己的软件灵活可变，那就应该时常修改它！
4. 职业道德
   1. 了解你得领域：专业知识需要熟悉并掌握
      • 设计模式。必须能描述GOF 书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验。
      • 设计原则。必须了解SOLID原则,而且要深刻理解组件设计原则。
      • 方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等。
      • 实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
      • 工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表。
   2. 坚持学习：不断地在专业上提升自己。
   3. 练习
      • 业精于勤。真正的专业人士往往勒学苦干，以求得自身技能的纯熟精炼。只完成日常工作是不足以称为练习的，那只能算是种执行性质的操作，而不是练习。练习，指的是在日常工作之余专门练习技能，以期自我提升。如”保龄球游戏“或”素数筛选“。
   4. 合作
      • 学习的第二个最佳方法是与他人合作。专业软件开发人员往往会更加努力地尝试与他人一起编程、一起练习、一起设计、一起计划，这样他们可以从彼此身上学到很多东西。而且能在更短的时间内更高质量地完成更多工作。
   5. 辅导
      • 让新人融入团队的最好办法是和他们坐到一起，向他们传授工作要诀。专业人士会视辅导新人为己任，他们不会放任未经辅导的新手恣意妄为。“教学相长”，传道授业的同时，导师也会从中受益。
   6. 了解业务领域：所有的功能都依赖于业务。
   7. 与雇主/客户保持一致：雇主的问题就是你的问题，你必须与雇主站在一个角度
   8. 谦逊

第二章 说“不”

能就是能，不能就是不能，不能说‘试试看’。

1. 对抗角色
   • 每位经理都承担着工作职责，绝大部分经理也知道该如何尽职尽责。其中一部分的工作职责，便是要竭尽所能追求和捍卫他们设定的目标。
     同样，程序员也自有其工作职责所在，绝大多数程序员也知道该如何出色地尽职尽责。如果他们是专业程序员的话，他们也会竭尽所能地去追求和捍卫自身的目标。如果你明知道第二天不能完成，嘴上却说‘我试试看’，那么便是你失职了。这时候，尽职的唯一选择是“不，这不可能。”
   • 为什么重要吗
     • “为什么”远不如“事实”更重要。不能完成的任务，是事实。而为什么不能完成，对经理/用户来说并不重要。
     • 如果“为什么”有助于让经理/用户来理解不能完成任务的原因，那也是必须的。
2. 要有团队精神
   • 为团队考虑
     • 不能完成的事情，坚决向上反馈不能完成。如果答应了他人没有完成的事情，就是不专业。
   • 试试看
     • 即使是面对项目或是经理的压力，也不能说出“试试看”这句话。因为根本没有“试试看”这回事。这背后意味着，可能超出负荷的加班、依旧没有完工的功能、完工但很多bug的正式环境。这都是不专业的行为。
   • 消极对抗
     • 如果一列载货汽车向大家冲来，而只有你一个人有所察觉，你看与轻轻抽身退到轨道外，眼看其他人被车碾过，也可以大喊：”车！车来了！快离开！“。显然专业人士都会选择后者。 

第三章 说“是”

口头上说。心里认真。付诸行动。

做出承诺包含三个步骤：

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

1. 识别”缺乏承诺“的征兆
   • 需要/应当。”我需要减肥“，”有人应当去负责推动这件事“。
   • 希望/但愿。”希望我明天能完成这个任务“，”但愿我有时间做这件事“。
   • 让我们（而不是让我）。”让我们回头再见“，”让我们把这件事做完“。
2. 做出真正的承诺
   • 我将在...之前...：我将在周二之前完成这个任务。
   • 对自己将会做某件事做清晰的事实陈述，还说明完成期限。说的是自己，而不是别人。而且不是可能去做，或是可能做到，而是必须做到。

第四章 编码

1. 编码是一项颇具挑战也十分累人的智力活动。编码时，必须平衡多种因素

• 代码必须能够正常工作
• 代码必须能够帮你解决客户提出的问题
• 代码必须要和现有系统配合得天衣无缝
• 其他程序员必须能读懂你得代码

同时要平衡好所有这些关注点颇为困难。长时间维持高度集中精神是有难度的，再加上在团队或组织中工作时常会遭遇到各种问题与干扰，以及需要留意和关注的各种日常琐事。总之，编码时无可避免地会受到各种干扰。当你无法全神贯注地编码时，所写代码就有可能出错。代码中可能会存在不少错误，也可能会存在错误的结构，模糊晦涩，令人费解，无法解决客户的实际问题。总之，最终你可能必须返工修改代码甚至重写。在心烦意乱的状态下工作，只会造成严重重的浪费。如果感到疲劳或者心烦意乱，千万不要编码。

2. 流态区

关于高效率状态通常被称为"流态"。有些程序员将之称为"流态区"。这是和程序员在编写代码时会进入的一种意识高度专注但思维视野却会收拢到狭窄的状态。在这种状态下，感到效率极高：在这种状态中，他们会感到"绝无错误"。因此他们一直苦苦追求进入这种状
态，并经常以能在那种状态下维持多久来衡量自我价值。一些曾经进入这种状态但终又从中摆脱出来的人给出了一点儿忠告：避免进入流态区，这种意识状态并非真的极为高效，也绝非毫无错误。这其实只只是一种"浅层冥想"状态,在这种状态下，为了追求所谓的速度，理性思考的能力会下降。

3. 音乐

听音乐消耗了一部分宝贵的脑力资源，而这些资源本该用于编写设计良好的整洁代码。也许对你而言可能不是这样，也许音乐有助于你编写代码。许多人在写代码时喜欢戴着耳机，但愿音乐真的能够帮到他们。但真实的情况是，音乐正带领他们进入流态区。

4. 中断

假设你正在专心工作，此时有人过来问你问题，你会怎么回应呢？你会厉声相斥怒目相向吗？你的肢体语言会对他们说”走开，别烦我，我正忙着呢“吗？简而言之，你会粗暴相待吗？或者你会停下手中的活，礼貌地帮助那些碰到困难的人吗？你会以你自己碰到困难时期望他人对待你的方式来对待他们吗?

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

5. 阻塞

有的时候，死活就是写不出代码来。

• 适当休息：看看邮件、翻看些书籍、泡杯咖啡
• 结对编程：找一个搭档，和你一起整理思路，书写代码。

6. 调试

• 永远不要相信自己，执行结果才是唯一标准
• 采用测试驱动开发（TDD）来降低调试时间

7. 保持节奏

软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。

• 适当的离开。在遇到困难而受阻时、疲倦时、离开一会，就会让富有创造力的潜意识接管问题。
• 放松。埋头忙于解决问题时，有时候可能会由于和问题贴得太近，无法看清楚所有的可选项。由于大脑中富有创造性的部分被紧张的专注力所抑制，你会错过很棒的解决方案。因此有时候解决一个问题最好的办法是回家，吃顿好的，然后上床睡觉，再在第二天清晨洗个澡。

8. 进度延迟

你总有一天会遭遇延迟的情况。即使是最优秀的程序员、最敬业的员工，也不能避免遇到延迟。有时候，则只是因为我们预估时过于乐观夸下了海口，最后延迟的情况无可避免。不要把预估和期望混淆在一起，把预估结果呈现给团队和利益相关者，并每天修正这些预估值。

• 不要经受不住诱惑盲目冲刺
  • ​​​如果可怜的开发人员在压力之下最终屈服，同意尽力赶上截止日期，结局会十分悲惨。那些开发人员会开始抄近路，会额外加班加点工作，抱着创造奇迹的渺茫希望。这是制造灾难的最佳秘诀，因为这种做法给自己、给团队以及利益相关方带来了一个错误的期望。这样每个人都可以避免面对真正的问题，把做出必要的艰难决定的时机不断后延。
• 不要超负荷加班
  • 个人能挤出时间
  • 短期加班，最多加班两周        
  • 你的老板有后备预案，以防万一加班措施失败了
• 没有完成的任务坚决不能交付
  • 完成的意义在于代码无误的部署与正式环境，并且功能准确没有任何瑕疵。

9. 帮助他人和接受他人帮助都很重要

互相帮助时每个程序员的职责所在。将自己封闭在格子间或者办公室里与世隔绝，有悖于专业的职业精神。

• 作为专业人士，要以能够随时帮助他人为荣。
• 要学会如何请求帮助。
  • 当你受阻时，或者有点犯晕时，或者只是绕一个问题统不出去时，不妨请求别人的帮助。如果你刚好和团队在一起办公，只需将手头的工作停下来，跟大家说"我需要帮忙"。再强调调一次，这体现的是一种专业的职业精神。如果帮助唾手可得却让自己一个人堵在那儿，是很不专业的表现。
     

第五章 测试驱动开发

”测试驱动开发“（TDD）是专业人士的选择。它是一项能够提高代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。对TDD的各项尝试表明，不使用TDD就说明你可能还不够专业。

TDD的三项法则

1. 在编好失败单元测试之前，不要编写任何产品代码。
2. 只要有一个单元测试失败了，就不要再写测试代码：无法通过编译也是一种失败情况。
3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

第六章 练习

专业人士都需要通过专门训练提升自己的技能，无一例外。乐手练习音阶、球员练习绕桩、医生练习开刀和缝针、律师练习论辩、士兵练习执行任务。要想表现优异，专业人士就会选择练习。

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

职业程序员用自己的时间来练习。老板的职责不包括避免你的技才术落伍，也不包括为你打造一份好看的履历。医生练习手术不需要病人付钱，球员东习绕桩（通常）不需要球迷付钱，乐手练习音阶也不需要乐迷付钱。所以老板没有义务为程序员的练习来买单。
 

第七章 验收测试

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

1. 避免过早精细化

做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。业务方还没有别自动项目，就要精确知道最后能得到什么；开发方还没有评估整个项目，就希望精确知道要交付什么。双方都贪求不现实的精确性，而且经常愿意花大价钱来追求这种精确。

问题在于，东西画在纸上与真正做出来，是不一样的。业务方看到真正的运行情况时就会意识到，自己想要的根本不是这样的。一看到已经满足的需求，关于到底要什么，他们就会冒出更好的想法-通常并不是他们当时看到的样子。

2. “完成”的定义

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

不同的团队对”完成“（done和complete）的定义各不相同，一支团队甚至有”完成“和”真正完成“两种说法。专业开发人员的"完成"只能有一个含义，完成，就是完成。完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这才是完成。

3. 沟通

验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识，大家都能明白系统的行为将会是怎样。各方都应当记录这种准确的共识。在专业开发人员看来，与业务方、测试方协同工作，确保大家都明白要做的是什么，是自己的责任。

在理想状态下，业务方和QA会协作编写这些测试，程序员来检查测试之间是否有冲突或矛盾。但实际上，业务方通常没有时间，或者有时间也难以达到所需要的细致程度，所以他们通常会把测试交给业务分析员、QA甚至是开发人员。如果只能由开发人员来写测试
应当确保写测试的程序员与开发所测试功能的程序员不是同一个人。 

写测试的人也是普通人，也可能犯错误，有时候，你刚开始实现某个功能，就会发现有些测试没什么意义。有些太复杂，有些不灵活，有些包含愚蠢的假定，还有些干脆是错的如果你是开发人员，要想通过这类测试可不轻松。身为专业开发人员，与编写测试的人协商并改进测试是你的职责。绝不能被动接受测试更不能对自己说："噢，测试是这么要求的，我就得这么办。"请记住，身为专业开发人员，你的职责是协助团队开发出最棒的软件。也就是说，每个人都需要关心错误和疏忽，并协力改正。
 

第八章 测试策略

TDD很强大，验收测试是表达和强化需求的有效方式。但它们都只是整体测试策略的一部分。为了更好地做到”QA应该找不到任何错误“，开发团队要和QA紧密协作，创建由单元测试、组件测试、集成测试、系统测试和探索式测试构成的测试体系。应该尽可能频保持运行这些测试，提供尽可能多的反馈，确保系统始终整洁。

1. 单元测试

在金字塔底部是单元测试要做到接近100%的覆盖率，这些测试由程序员使用与系统开发相同的语言来编写，供程序员自己使用。编写这些测试的目的是在最低层次上来定义系统。开发人员是这样定义特写代码规约的：先编写测试，再编写产品代码，这些单元测试将作为持续集成的一部分来运行用以确保程序员的代码意图没有遭到破坏。

2. 组件测试

组件测试是验收测试的一种。通常，它们是针对系统的各个组件而编写的，系统的组件封装了业务规则，因此，对这些组件的测试便是对其中业务规则的验收测试。

3. 集成测试

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

4. 系统测试

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

5. 探索式测试
这是需要人工介入、敲击键盘、盯牢屏幕的测试。它们既非自动化的测试，亦非脚本化的测试，这些测试的意图，是要在验证预期行为的时候，探索系统预期之外的行为。为了达到这个目的，需要人类智慧的介入，需要使用人类的创新能力，对系统进行深入研究
和探索，预告编写测试计划反而会削弱这类测试的效果。

第九章 时间管理

1. 会议：会议是必须的；会议浪费了大量时间。这是永恒不变的真理。专业人士会对会议做出专业的规划

• 拒绝没必要的会议
• 如果议题偏离，或者你觉得会议没有任何意义，请尽快找一个合理的理由离开
• 会议要有确定的议程和目标
• 立会（stand up）是敏捷开发中最具有地位的武器之一：
  • 我昨天干了什么？
  • 我今天打算干什么？
  • 我遇到了什么问题
• 迭代计划会议用来选择再下一轮迭代中实现的开发任务，节约时间的办法之一，就是会议前准备好相关内容
  • 评估可选择任务的开发时间
  • 确定这些任务的业务价值
  • 验收/组件测试（或者有个概略方案）
  • 每个任务讨论时间不超过10分钟
  • 总时间不应该超过总迭代周期的5%
• 迭代回顾与Demo
  • 在周期的最后一天下班前45min召开
  • 20分钟回顾做了什么
  • 25分钟展示
  • 只设计周期内的更新
• 争论/反对
  • 凡是不能在5分钟内解决的争论，都不能靠辩论来解决
  • 争论各方提供有力的证据，通过5分钟来向大家摆明道理，最后投票

2. 注意力点数：每个人的注意力都是有限度的，要合理的使用，以及合理的休息以恢复注意力。

• 保证充足的睡眠
• 适当的休息
• 提升肌肉注意力

3. 时间拆分与番茄工作法

4. 避免优先级错乱：评估每个任务的优先级，排除个人的喜好和需要，按照真实的紧急程度来执行任务。

5. 不必执拗于走不通的技术道路，越是坚持浪费的时间越多，如果你认为关系到专业信誉，就永远也走不出来。

6. 发现自己身处泥潭还要固执前进，是最严重的优先级错乱，继续前进无异于欺骗自己，欺骗团队，欺骗公司，欺骗客户。

第十章 预估

1. 承诺

承诺是必须做到的。如果你承诺在某天做成某事，就必须按时完成。即便它意味着你必须每天工作12小时，放弃周末的休假，也不得不如此。既然承诺了，就必须兑现。专业开发人员不随便承诺，除非他们确切知道可以完成。道理就是这么简单。如果你被要求承诺做自己不确定的事情，那么就应当坚决拒绝。如果要求我你承诺在某天完成，但是需要每天加班，周末加班，取消休假，那么最后的决定取决于你；不过，不要违背自己的意愿去勉强。

2. 预估

预估是一种猜测。它不包含任何承诺的色彩。它不需要做任何约定。预估错误无关声誉。计划评审技术(PIERT, Program Evaluation and Review Technique)的一部分内容就是对预估的计算方法。这种技术包含了一个非常简单而有效的办法，把预估变成概率分布，让主管们看懂。

• O：乐观预估

    这是非常乐观的数字。如果一切都异常顺利，你可以在这个时间内完成。实际上，为了保证乐观预估有意义，这个数字对应的发生概率应当小于1%。

• N：标称预估

    这是概率最大的数字。如果画一张柱状图，标称预估就是最高的那个。

• P：悲观预估

    这是最糟糕的数字。它应当考虑到各种意外,比如飓风、核战争、黑洞、其他灾难等。为保证悲观预估有意义，这个数字对应的发生概率也应当小于1%。

举个例子，如果O=1，N=3，P=12.

μ=(O+4N+P)/6

μ是任务的期望完成时间。在例子中,它等于(1+12+12)/6,也就是大概4.2天。通常这个数字都有点水分，因为分布图的右边部分比左边部分长。

ɓ=(P-O)/6

ɓ是这个任务的概率分布的标准差，用来衡量不确定性。如果这个数字很大，就表示示非常不确定。它等于(12-1)/6,也就是大概1.8天。现在我们知道，预估天数是4.2±1.8。

3. 预估任务

对于任务的预估，最重要的是共识，别忘了和你的团队一起确定每一个任务的完成时间。

• 亮手指
      大家围坐在桌旁。每次讨论一项任务。针对每项任务，都必须讨论这个任务涉及什么，什么因素会把它搞复杂，它应该如何实现。然后所有参与者把手埋到桌底下，根据自己的判断，伸出0~5个手指。这时候，主持人数1-2-3，所有人都把手亮出来。如果大家伸出的手指数相同，就开始讨论下一个任务。否则，就开始讨论为什么有分做如此重复，直到意见统一。
• 关联预估
      关联预估(Affinity Estimation)是德尔非法的一种特殊形式。在关联预估中，所有任务都写在卡片上，卡片上没有任何关于预估的信息。让参与预估的人围成一圈站在桌子边或是墙边，,把卡片打乱铺开。大家保持静默，只是卡片按照任务所需时间的长短排序，需要时间长的放右边，短的放左边。
      任何时候，任何人，都可以移动任何卡片，不需要关心之前是否有人移动过。如果哪张卡片移动过超过几次，就需要抽出来单独讨论。最终，静默的排序终止。大家开始讨论，详细了解排序意见的分歧所在，也可以通过简短的设计讨论或者手绘的线框草图来帮助取得共识。
      下一步是按照时间单位来给任务归类。时间单位可能是天或周或点数。按照惯例，一般选择菲波那契数列中头5个元素(1、2、3、5、8)。
• 三元预估
      如果为单个任务做标称预估，德尔菲法是不错的办法。但是之前说过，大多数情况下需要做3种预估，才能得出概率分布。不论使用德尔菲法的哪利中形式，都可以迅速得到每个任务的乐观预估值和悲观预估值。举例来说，如果选择使用规划扑克，可以要求大家根据悲观预估亮出纸牌，然后选择点数最大的那张。乐观估计也是如此，只不过是选出点数最小的那张。

4. 大数定律

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

第十一章 压力

想象一下灵魂出窍后的体验：你看见自己躺在一张手术台上，一位外科医生给你做开胸手术。医生竭力挽救你的性命，但是时间有限，也就是说，他的一举一动都与病人生死攸关---你命悬一线。

你期望医生的表现如何？你希望他冷静、井井有条吗？你希望他清楚准确地吩咐助手吗？你希望他严格遵循当初训练时的做法坚守手术规程吗?

还是想让他汗流淡背、咒骂之声不断？想让他乱扔手术器械、把东西摔得哐当响吗？想让他满腹怨气责怪管理人员设定的不现实的手术时间，一直嚷嚷时间不够用吗？你期望他表现得像一名专业人士，还是像我们常见的某些开发人员的那些做派？

1. 避免压力

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

2. 保持整洁

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

3. 危机中的纪律

选择那些你在危机时刻依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律。遵守这些纪律原则是避免陷入危机的最好途径。

4. 不要惊慌失措

放松下来。对问题深思熟虑。努力寻找可以带来最好结果的路径，然后沿着那条路径以合理稳定的节奏前进。

5. 沟通

让你的团队和主管知道你正身陷困境之中。告诉他们你所制定的走出困境的最佳计划。请求他们的支援和指引。避免产生的惊恐。没有东西比惊恐更令人愤怒和失去理性，惊恐会让你的压力增大十倍。

6. 寻求帮助

结对！当头脑发热时，找一个愿意和你一起结对编程的伙伴。你会前进得更快，而缺陷却会更少。结对伙伴会帮助你守住原则，制止你的精神错乱。搭档会捕捉住你疏忽遗漏的事情，会提出有帮助的想法，会在你注意力迷失的时候接过你手中的工作继续前进。

第十二章 协作

1.代码个体所有

不正常的团队最糟糕的症状是，每个程序员在自己的代码周边筑起一道高墙，拒绝让其他程序员接触到这些代码。不少程序员甚至不愿让其他程序员看见他们的代码。这是引发灾难的“最有效秘诀”。

2.协作性的代码共有权

将代码所有权的各种隔断全部打破、由整个团队共同拥有全部代码的做法，相较于此则要好得多。团队中每位成员都能签出任何模块的代码，做出任何他们认为合适的修改。拥有代码的是整个团队,而非个人。专业开发人员是不会阻止别人修改代码的。他们不会在代码上构造所有权的藩篱，而是尽可能多地互相合作。他们通过合作来达到学习的目的。

3.结对
许多程序员都不喜欢“结对编程”这一理念。但很奇怪，在紧急情况下，大多数程序员又都愿意结对工作。为什么呢？很显然，因为这是解决问题最有效的力法。老话说得好：“三个臭皮匠胜过一个诸葛亮。”但是，如果在紧急情况下结对是解决问题题最有效的方法，那为什么在平常不是呢?"专业人士会结对工作。"为什么？因为至少对有些问题而言，结对是最有效的解决方法。不过这并非采用结对编程唯一的原因。

也许我们不是因为通过编程可以和人互相协作才选择从事这项工作的。但真不走运，编程就意味着与人协作。我们需要和业务人员一起工作，我们之间也需要互相合作。如果我们真想终生能以编程度日，那么，一定要学会交流--和大家交流。

第十三章 团队与项目

1. 有凝聚力的团队

形成团队是需要时间的。团队成员需要首先建立关系。他们需要学习如何互相协作，需要了解彼此的癖好、强项、弱项，最终，才能凝聚成团队。有凝聚力的团队确实有些神奇之处。他们能够一起创造奇迹。他们互为知己，能够替对方着想，互相支持，激励对方拿出自己最好的表现。他们攻无不克。

2. 团队优先

银行和保险公司试图围绕项目来构建团队。这是一种愚蠢的做法。按照这种做法，团队永远都不可能形成凝聚力。每个人都只在项目中的过客，只有一部分时间是在为项目工作，因此他们永远都学不会如何默契配合。专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕着项目来组建团队。一个有凝聚力的团队能够同时承接多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目。

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

1. 不用对应届毕业生抱有过高的期望

大学毕业生在成为软件开发人员之前有一段合理的督导实训期，并不是什么不合时宜的过分建议。
毕业生会从学徒这一步开始他们的职业生涯。学徒没有"自治权"，他们需要在熟练工的紧密督导下工作。在一开始，他们不会单独承接任何任务，而只作为助手为熟练工打下手。在这个阶段，应该十分密集地进行结对编程。这一时期是学问纪律并强化各项实践的阶段。各项价值观的基础也都是在这个阶段塑造成型。

2. 技艺

技艺是工匠所持的精神状态。技艺的"模因"(meme)中包含着价值观、原则、技术、态度和正见。

技艺模因经由口口相传和手手相承而来，需要由资深人士向年轻学徒殷勤传授，然后再在学徒之间相互传播。资深人士会观察年轻学徒的学习过程，然后不断反思和改进传授之道。技艺模因宛如一种"传染病"，一种"精神病毒"。通过观察其他人的工作，让模因落地生根 ，你也会"感染"上技术模因。

觉者觉人

只要技艺模因可以被人观察到，它便具有传染性。你自己首先要成为表率。你自己首先要成为能工巧匠，向人们展示你的技艺。然后，将剩余的事情交给技艺模因的自然运行之道即可。