读《程序员的职业素养》

原文链接：http://dearymz.blog.163.com/blog/static/205657420134149427420/?suggestedreading&wumii

正文之前

1. 最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。……美的系统是灵活、易于理解的，构建、维护它们就是一种快乐。

第1章 专业主义

1. 专业主义有很深的含义，它不但象征着荣誉与骄傲，而且明确意味着责任与义务。这两者密切相关，因为从你无法负责的事情上不可能获得荣誉与骄傲。
2. 代码中难免会出现bug，但这并不意味着你不用对它们负责；没人能写出完美的软件，但这并不表示你不用对不完美负责
3. 所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免
4. 职业经验多了之后，你的失误率应该快速减少，甚至渐进于零。失误率永远不可能等于零，但你又责任让它无限接近零
5. 写一些随时都能运行的单元测试，然后尽可能多的执行这些测试。要用这些自动化单元测试去测多少代码呢？还要说吗？全部！完全都要测！我是在建议进行百分百测试覆盖率吗？不，我不是在建议，我是在要求！你写的每一行代码都要测试。完毕！这是不是不切实际？当然不是。你写代码是因为想执行它，如果你希望代码可以执行，那你就该知道它是否可行。而要知道它是否可行，就一定要对它进行测试
6. 有些代码不是很难测试吗？是的，但之所以很难测试，是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码，最好是先写测试，再写要测的代码——TDD
7. 成熟的开发人员知道，聪明人不会为了发布新功能而破坏结构。结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必追悔莫及
8. 所有软件项目的根本指导原则是，软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型
9. 如果你希望自己的软件灵活可变，那就应该时常修改它！
10. 让软件保持固定不变是危险的！如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化了”
11. 对待代码，就如果雕塑家对待泥巴那样，要对它进行不断的变形与塑造
12. 职业发展是你自己的事情。雇主没有义务确保你在职场能够立于不败之地，也没有义务培训你，送你参加各种会议或给你买各种书籍充电。这些都是你自己的事。将自己的职业发展寄希望于雇主的软件开发人员将会很惨。
13. 雇主也没义务给你留学习时间
14. 应该勤勉的开辟一部分时间为自己的职业发展工作，这将会让你成为更有价值的专业人士
15. 不能铭记过去的人，注定重蹈先人的覆辙
16. 学不会新原则和技术的开发人员必将沦落
17. 业精于勤。真正的专业人士往往勤学苦干，以求得自身技能的纯熟精炼
18. 与他人合作是最佳学习方法之一。专业软件开发人员往往会更加努力的尝试与他人一起编程、一起练习、一起设计、一起计划，这样他们可以从彼此身上学到很多东西，而且能在更短的时间内更高质量的完成更多的工作
19. 让新人融入团队的最好办法是和他们做到一起，向他们传授工作要诀。专业人士会视辅导新人为己任，他们不会放任未经辅导的新手乱打乱撞

第2章 说“不”

1. 能就是能，不能就是不能。不要说“试试看” —— 尤达
2. 专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理们说“不”
3. 奴隶没有权利说“不”。劳工或许也对说“不”有所顾虑。但是专业人士应该懂得说“不”。事实上，优秀的经理对于敢于说“不”的人，总是求贤若渴。因为只有敢于说“不”，才能真正做成一些事情
4. 有时候，提供太多细节，只会招致更多的微观管理
5. 最要说“不”的是那些高风险的关键时刻。越是关键时刻，“不”字就越具价值
6. 当公司存亡成败皆系于此时，你必须尽己所能，把最好的信息传递给你的经理。这往往意味着要说“不”
7. 没有“试试看”这回事！从本质上讲，承诺“尝试”是一种不诚实的表现。你在说谎。你这么做的原因，可能是为了护住面子和避免冲突
8. 在经济全球化时代，企业惟利是图，为提升股价而采用裁员、员工过劳和外包等方法，我遇到的这种减缩开发成本的手段，已经消解了高质量程序的存在价值和时宜了。只要一不小心，我们这些开发人员就可能会被要求、被指使或是被欺骗去花一半的时间写出两倍数量的代码。
9. 成为英雄及“解决问题”的诱惑诚然巨大，只是我们要明白，委屈专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造出更多的麻烦

第3章 说“是”

1. 在承诺某事时，应当留意自己的用词，因为这些用词透露了我们对待承诺的认真程度
2. 你，你自己，始终都能掌控某些事情，也就是说，总有些事是你可以承诺做到的
3. 你只能承诺自己能完全掌握的事
4. 如果你无法兑现承诺，那么最终要的就是尽早向你的承诺对象发出预警，越快越好，越早越好
5. 如果你不尽早告诉他人可能的问题，就错失了然他们帮助你达成目标、兑现承诺的机会
6. 口头上说自己会在周末搞定这些事情是很容易的，但真要花精力高质量的完成工作会困难许多。专业人士对自己的能力极限了如指掌。他们十分清楚自己还能保持效率加班多长时间，也非常明白要付出的代价
7. 专业人士不需要对所有请求都回答“是”。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用承诺用语，以确保各方能明白无误的理解承诺内容

第4章 编码

1. 能够感知到错误确实非常重要。不只对“录入”是这样，对于一切事情莫不如此。具备“出错感知能力”，说明你已经能够非常迅速的获得反馈，能够更为快速的从错误中学习。要精熟掌握每项技艺，关键都是要具备“信心”和“出错感知”能力
2. 同时要平衡好所有关注点颇为困难。长时间维持高度的聚精会神是有难度的。再加上在团队或组织中工作时常会遭遇到各种问题与干扰，以及需要留意和关注各种日常琐事。总之，编码无可避免的会受到各种干扰。
3. 当你无法全神贯注的编码时，所写的代码就有可能出错。代码中可能会存在不少错误，也可能会存在错误的结构，模糊晦涩，令人费解，无法解决客户的实际情况。总之，最终你可能必须返工修改代码甚至重写。在心烦意乱的状态下工作，只会造成严重的浪费。
4. 如果感到疲劳或者心烦意乱，千万不要编码。强而为之，最终只能再回头返工。相反，要找到一种方法来消除干扰，让心绪平静下来。
5. 我最糟糕的代码，是在凌晨3点写出来的
6. 疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指要遵守纪律原则而非成为长时间工作的工作狂。要确保自己已经将睡眠、健康和生活方式调整到最佳状况，这样才能做到每天的8小时工作时间内全力以赴
7. 在不应该编写代码的时候，产出的任何代码都会是垃圾。憋出来的代码以后将不得不抛弃（如果还要与之长期相伴，那就是更糟糕的事情了）
8. 流态区是程序员在编写代码时会进入的一种意识高度专注但思维视野却会收拢到狭窄的状态
9. 在流态区，你可能可以敲出更多的代码。你会收获一种愉悦感或征服感。问题在于，在流态区状态下，你其实没有顾及全局，因此，你很可能会做出一些后来不得不推倒重来的决策。在流态区写代码可能会快些，但是后面你将不得不更多的回头重新审视这些代码
10. 现在，当我感觉自己将要滑入流态区时，就会走开几分钟。我会通过回复几封邮件或者翻看几条推特来换换脑筋。如果时间已近中午，我会停下来去吃午饭。如果我正和一个团队一起工作，则会去找一个结对编程的搭档
11. 结对编程最大的好处在于，结对中的任一方都不可能进入流态区。流态区是一种隔绝沟通的状态，而结对则要求激烈持续的进行沟通。事实上，我经常听到关于结对编程的抱怨便是，结对会阻碍人们进入流态区。很好！流态区正是要避免进入的状态
12. 我意识到，在听音乐时无法写好代码。音乐并没有帮助我专注于编码。事实上，听音乐似乎消耗了至为重要的一部分脑力资源，而这些资源本该用于编写设计良好的整洁代码。也许对你而言可能不是这样，也许音乐有助于你编写代码。我知道许多人在写代码时喜欢戴着耳机，但愿音乐真的能够帮助到他们。但同时我也怀疑，真实的情况是，音乐正将他们带入流态区
13. 结对编程是用以应对中断的一种好方法。当你接打电话或回答其他同事的问题时，结对搭档能够维护住中断处的上下文。等你重新回去和结对搭档一起工作是，他能够很快的帮助你回复被打断前的思维。另一种很有帮助的方法是采用TDD。如果有一个失败的测试，它就能帮你维护住编码进度的上下文。当处理完中断重新回去时，你很清楚下一步任务便是让这个失败的测试通过。
14. 当然，中断无法避免，总有干扰会打断 你、消耗你的时间。发生这种情况时要记住一点，也许下次也会轮到你去打断别人请求帮助。因此，礼貌的表现出乐于助人的态度才是专业的态度
15. 软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。无论是赛前还是赛中，马拉松选手都会仔细调整好自己的身体状态。专业程序员也会同样仔细的保存好自己的精力和创造力
16. 没解决好这个问题就不能回家？噢不，你可以回家，而且你应该回家！创造力和智力来自于大脑的高速运转。当你感到疲劳时，它们就不翼而飞了。当大脑已经无法正常思考却硬逼自己在深夜还在加班解决问题，你只会把自己折腾得更累，但是如果开车回家好好洗个澡，则问题很有可能会豁然开朗。
17. 当碰到困难而受阻时，当你感到疲倦时，就离开一会儿，让富有创造力的潜意识接管问题。精力分配得当，你将能在更短的时间内以更少的精力完成更多的事情。让自己保持好节奏，让团队保持好节奏。了解你的创造力和智力运行的模式，充分发挥它们的优势而非与之背道而驰
18. 埋头忙于解决问题时，有时候可能会由于和问题帖得太近，无法看清楚所有的可选项。由于大脑中富有创造力的部分被紧张的专注力所抑制，你会错过漂亮的解决方案
19. 管理延迟的诀窍，便是早期检测和保持透明
20. 唯一能够加快进度的方法便是缩减范围。不要经受不住诱惑盲目冲刺。如果可怜的开发人员在压力之下最终屈服，同意尽力赶上截至日期，结局会十分悲惨。那些开发人员会开始抄近路，会额外加班加点工作，抱着创造奇迹的渺茫希望。这是制造灾难的最佳秘诀，因为这种做法给自己、给团队以及利益相关方带来了一个错误的期望
21. 其实快速冲刺是做不到的。你无法更快的写完代码。你无法更快的解决问题，如果试图这么做，最终只会让自己变得更慢，同时也只能制造出一堆混乱，让其他人慢下来
22. 加班确实有用，而且有时候也有必要。短期加班，最多加班两周
23. 为了能够实现高效编程，好的协作至为重要。因此，对于我们大多数人而言，既然协作并非我们自身的天性，那么我们就需要通过纪律原则来驱动大家良好协作
24. 花时间手把手的辅导年轻的程序员是资深程序员的专业职责所在，向资深导师寻求辅导也是年轻程序员的专业职责

第5章 测试驱动开发

1. 对任何新鲜事物，最好不要马上批驳
2. 此事已有定论，TDD的确切实可行，每个开发人员都要适应和掌握TDD
3. TDD的三项法则：
   1. 在编好失败单元测试之前，不要编写任何产品代码
   2. 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况
   3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写
4. 看到糟糕代码时，你为什么不修改呢？看到混乱的函数时，你的第一反应是：“真是一团糟，这个函数需要整理。”你的第二反应是：“我不会去碰它！”为什么？因为你知道，如果去动它，就要冒破坏它的风险；而如果你破坏了它，那么它就缠上你了
5. 这是TDD最强大之处。拥有一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。当看见糟糕的代码时，就可以放手整理。代码会变得具有可塑性，你可以安全的将之雕琢成简单而满意的结构。
6. 当程序员不再惧怕整理代码时，他们便会动手整理！整洁的代码更易于理解，更易于修改，也更易于扩展。代码更简洁了，缺陷也更少了。整个代码库也会随之稳步改善，彻底杜绝业界常见的放任代码劣化而视若不见的状况。专业程序员怎么能够容忍代码持续劣化呢？
7. 测试先行的需要，会迫使你去考虑什么是好的设计
8. 事后写的测试只是一种防守。而先行编写的测试则是进攻，事后编写测试的作者已经受制于已有代码，他已经知道问题是如何解决的。与采用测试先行的方式编写的测试代码比起来，后写的测试在深度和捕捉错误的灵敏度方面要逊色很多
9. TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。对TDD的各项尝试表明，不使用TDD就说明你可能还不够专业

第6章 练习

1. 专业人士都需要借助专门训练提升自己的技能，无一例外
2. 现在仍然有些程序员必须等待构建，这是悲剧，也是不够仔细的征兆。如今，构建时间应该用秒来衡量，而不是分钟，更不是小时
3. 实际上真正做出反应的是你的身体，大脑是在更高层面上思考
4. 和习武者一样，程序员应该懂得多种不同的Code Kata，并定期练习，确保不会淡化或遗忘。
   1. http://katas.softwarecraftsmanship.org/
   2. http://codekata.pragprog.com/
5. 职业程序员通常会受到一种限制，即所解决问题的种类比较单一
6. 无论如何，专业人士都需要练习。他们这么做，是因为他们关心自己能做到的最好结果。更重要的是，他们用自己的时间练习，因为他们知道保持自己的技能不落伍是自己的责任，而不是雇主的责任。练习的时候是赚不到钱的，但是练习之后，你会获得回报，而且是丰厚的回报

第7章 验收测试

1. 专业开发人员既要做好开发，也要做好沟通
2. 验收测试——业务方与开发方合作编写的测试，其目的在于确定需求已经完成
3. 验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识，大家都能明白系统的行为将会是怎样。各方都应当记录这种准确的共识，确保大家都明白要做的是什么，什么是自己的责任
4. 编写自动化测试代码似乎得花很多工夫，但总比写一份人工测试计划要好，而且，重复执行人工测试花的功夫要多得多
5. 验收测试都应当自动进行。在软件开发的周期中，确实有时候需要手动测试，但是验收测试不应当手工进行，原因很简单：要考虑成本
6. 相比手动测试，自动化测试的成本非常低。专业开发人员认为，实现验收测试的自动化是自己的责任
7. 写测试并不是额外的工作。写这些测试是为了确定系统的各项指标符合要求。只有确定这些细节指标，程序员才能确知“完成”；只有确定这些细节指标，业务方才能确认他们花钱开发的系统确实满足了需求；只有确认这些指标，才可以真正做到自动化测试。所以，不要把写测试看作额外的工作，而应当看成节省时间和金钱的办法。测试可以避免开发误入歧途，也可以帮你确认已经完工
8. 通常，业务分析员测试“正确路径”，以证明功能的业务价值；QA则测试“错误路径”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题
9. 迭代开始的第一天，就应当准备好最初的几项验收测试。然后每天都应当完成一些验收测试。到迭代的中间点，所有的测试都应当准备完毕
10. 验收测试并不是单元测试
    1. 单元测试时程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员
    2. 验收测试是业务方写给业务方的。它们是正式的需求文档，描述了业务方任务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员
    3. 尽管两者测试的可能是同一个对象，其机制和路径却是不同的。单元测试是深入系统内部进行，调用特定类的方法；验收测试则是在系统外部，通常是在API或者UI级别进行
    4. 验收测试和单元测试的主要功能其实不是测试！测试只是它们的附属功能。单元测试和验收测试首先是文档，然后才是测试。他们的主要目的是如实描述系统的设计、结构、行为。它们当然可以验证设计、结构、行为是否达到了具体指标，但是，它们的真正价值不在测试上，而在具体指标上
11. 预先详细指定GUI很难，因为美是主观的，会不断变化。GUI通常都是不断变化的
12. 编写GUI的验收测试很麻烦。但如果把GUI当成API那样处理，而不是看成具体的控件，那验收测试就简单多了
13. GUI的布局、格式、工作流，都会因为效率和美观的原因而变化，但是GUI背后的功能却不会因此变化。所以，在编写GUI的验收测试时，必须使用GUI背后相对稳定的抽象元素。
14. 通过GUI进行测试是非常容易出问题的，除非你要测试的仅仅是GUI。因为GUI很容易变化，所以针对GUI的测试很不稳定。针对GUI的测试越多，维护它们的难度就越大
15. 请务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。整套集成系统应该由源代码管理系统来触发。只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试
16. 保持持续集成系统的时刻运行是非常重要的。持续集成不应该失败，如果失败了，团队里的所有人都应该停下手里的活，看看如何让测试通过。在持续集成系统里，失败的集成应该视为紧急情况，也就是“立刻终止”型事件
17. 交流细节信息是件麻烦事。尤其是开发方和业务方交流关于程序的细节时，更是如此。通常，各方握手言欢，以为其他人都明白自己的意思。双方以为取得了共识，然后带着截然不同的想法离开，这种事太平常不过了。要解决开发方和业务方沟通的问题，目前唯一有效的办法就是编写自动化的验收测试。这些测试足够正式，所以其结果有权威性。这些测试不会造成模糊，也不可能与真实系统脱节。它们，就是无可挑剔的需求文档

第8章 测试策略

1. QA和开发人员因该紧密协作，携手保障系统的质量。QA在团队中要扮演的便是需求规约定义者和特性描述者
2. 自动化测试金字塔 
   
   
   
   
3. 单元测试是可行的，而且可以做到接近100%的覆盖率。通常而言，这个数字应该保持在90%以上。大多数的异常路径是由单元测试来覆盖的
4. 组件测试差不多可以覆盖系统的一半。更主要测试的是成功路径的情况，以及一些明显的极端情况、边界状态和可选路径
5. 集成测试只对那些组件很多的较大型系统才有意义。集成测试将组件装配成组，测试它们彼此之间是否能正常通信。集成测试是编排性测试。它们并不会测试其业务规则，而是主要测试组件装配在一起时是否协调。它们是装配测试，用以确认这些组件之间已经正确连接，彼此间通信通畅
6. 系统测试是针对整个集成完毕的系统来进行的自动化测试，是最终的集成测试。它们不会直接测试业务规则，而是测试系统是否已正确组装完毕，以及系统各个组成部件之间是否能正确交互。在这个层次的测试集中，应该包括吞吐率测试和性能测试。其目的不是要确保正确的系统行为，而是要确保正确的系统构造
7. 人工探索式测试是需要人工介入、敲击键盘、盯牢屏幕的测试。它们既非自动化测试，亦非脚本化测试，其意图是要在验证预期行为的时候，探索系统预期之外的行为。为了这个目的，需要人类智慧的介入，需要使用人类的创新能力，对系统进行深入研究和探索。预先编写测试计划反而会削弱这类测试的效果。覆盖率并非此类测试的目标。探索式测试不是要证明每条业务规则、每条运行路径都正确，而是要确保系统在人工操作下表现良好，同时富有创造性的找出尽可能多的“古怪之处”
8. 应该尽可能频繁的运行这些测试，提供尽可能多的反馈，确保系统始终整洁

第9章 时间管理

1. 8小时其实非常短暂，只有480分钟，28800秒。身为专业开发人员，你肯定希望能在这短暂的时间里尽可能高效的工作，取得尽可能多的成果
2. 邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实而显著的成效，否则不必参与
3. 领导的最重要职责之一，就是帮助你从某些会议中脱身。好的领导一定会主动维护你拒绝出席的决定，因为他和你一样关心你的时间
4. 凡是不能在5分钟内解决的争论，都不能靠辩说解决。争论之所以要花这么多时间，是因为各方都拿不出足够有利的证据。所以这类争论依据的不是事实，而是信念
5. 在没有数据的情况下，如果观点无法在短时间里达成一致，就永远无法达成一致。唯一的出路是，用数据说话
6. 编程是需要持续投入精力和注意力的智力活动。注意力是稀缺的资源
7. 睡眠的重要性怎么强调都不为过。美美一觉醒来，我的注意力点数是最充裕的。专业开发人员会安排好他们的睡眠，保证清晨有饱满的注意力点数去上班
8. 在走入死胡同时可以迅速意识到，并有勇气走回头路。这就是所谓的坑法则：如果你掉进了坑里，别挖
9. 专业的开发人员不会执拗于不容放弃也无法绕开的主意，他们会保持开放的头脑来听取其他意见，即使走到尽头，他们仍然有其他选择
10. 比死胡同更糟的是泥潭。泥潭会减慢你的速度，但不会让你彻底停下来。泥潭会阻碍你前进，但如果使尽全力，即仍然可以取得进展。之所以说泥潭比死胡同更麻烦，是因为在泥潭中，你仍然可以看到前进的道路，而且看起来总是比走回头路更短（虽然实际不是这样）
11. 除了泥潭，没有其他东西能够对开发团队的效率产生如此深远且长期的负面影响
12. 发现自己身处泥潭还要固执前进，是最严重的优先级错乱。继续前进无异于欺骗自己，欺骗团队，欺骗公司，欺骗客户。你一边走向大家共同的炼狱，一边告诉其他人，所有问题都会解决
13. 最糟糕的事情，莫过于看到一群开发人员在徒劳的拼力工作，结果却陷入越来越深的泥潭

第10章 预估

1. 不同的人对预估有不同的看法。业务方觉得预估就是承诺，开发方认为预估就是猜测。两者相差迥异
2. PERT计划评审技术(Program Evaluation and Review Technique)：
   1. 1957年为支持美国海军的潜艇极地航行计划而诞生
   2. 可以根据3个数字评估某项任务（三元分析法）
      1. O：乐观估计。这是非常乐观的数字。如果一切都异常顺利，你可以在这个时间内完成。实际上，为了保证乐观估计有意义，这个数字对应的发生概率应当小于1%
      2. N：标称估计。这是概率最大的数字，表示最有可能的时间
      3. P：悲观估计。这是最糟糕的数字。它应当考虑到各种意外。为保证悲观估计有意义，这个数字对应的发生概率也应当小于1%

   3. 	期望时间	标准差
      单项任务
      序列任务累积

3. 把大任务分成许多小任务，分开预估再加总，结果会比单独估计大任务要准确的多

第11章 压力

1. 即使有压力，专业开发人员也会冷静果断。尽管压力不断增大，他仍然会坚守所受的训练和纪律，他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法
2. 通过卓越工作而非愚蠢工作来享受自己的职业生涯
3. 在压力下保持冷静的最好方式，便是规避会导致压力的处境。规避的方式也许无法完全减除压力，但是可以大大降低压力并缩短高压力期的时间
4. 专业人士总会千方百计的帮助业务方找到达成目标的方法，但并一定要接受业务方代为做出的承诺
5. 快速前进确保最后期限的方法，便是保持整洁。专业人士不会为了快点前进而乱来。他们明白“快速但脏乱”是自相矛盾的说法。脏乱只会导致缓慢！
6. 正确应对压力。长夜漫漫无心睡眠，无助于更快的解决问题。呆坐着烦躁不安也于事无补。而你可能会犯的更严重的错误，就是鲁莽仓促！要避免产生孤注一掷的想法。鲁莽仓促只会把你带入更深的深渊。相反，要放松下来。对问题深思熟虑。努力寻找可以带来最好结果的路径，然后沿着那条路经以合理稳定的节奏前进
7. 战胜压力煎熬的唯一方法，便是依靠那些你已经知道切实有效的东西——你平时遵守的纪律
8. 应对压力的诀窍在于，能回避压力时尽可能的回避，当无法回避时则勇敢直面压力。可以通过慎重承诺、遵循自己的纪律原则、保持整洁等来回避压力。直面压力时，则要保持冷静，与别人多沟通，坚守自己的原则纪律，并寻求他人的帮助

第12章 协作

1. 专业程序员的首要职责是满足雇主的需求
2. 代码不应该为个体所有。不正常的团队最糟糕的症状是，每个程序员在自己的代码周围筑起一道高墙，拒绝让其他程序员接触到这些代码。
3. 协作性的代码共有权。将代码所有权的各种隔断全部打破、由整个团队共同拥有全部代码。团队中每位成员都能签出任何模块的代码，做出任何他们认为合适的修改
4. 系统中不应该包含未经其他程序员复查过的代码。最有效率且最有效果的代码复查方式，就是以写作的方式完成代码编写——结对编程
5. 也许你认为自己一个人工作时会做得更好。也许确实如此，但这并不意味着你一个人工作时，整个团队会做得更好。况且，事实上，一个人单独工作时，不太可能会工作得更好
6. 如果我们真想终生能以编程度日，那么，一定要学会交流——和人们交流

第13章 团队与项目

1. 让一个程序员把一半的时间投入在项目A中，把其余时间投入在项目B中，这并不可行。事实上并没有半个人的这种说法
2. 由12人组成的理想团队人员配置情况：7名程序员、2名测试人员、2名分析师和1名项目经理
   1. 分析师开发需求，为需求编写关注业务价值的成功路径自动化验收测试
   2. 测试人员编写编写关注正确性的失败路径和边界路径自动化验收测试
   3. 项目经历跟踪团队的进度，确保团队成员理解项目时间表和优先级
   4. 其中有一名团队成员可能需要拿出部分时间充任团队教练或Master的角色，负责确保项目进展，监督成员遵守纪律
3. 专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕着项目来组建团队，这是一种愚蠢的做法。一个有凝聚力的团队能够同时承担多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目
4. 团队比项目更难构建。因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是较好的做法。并且，团队也可以同时承接多个项目。在组建团队时，要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎

第14章 辅导、学徒期与技艺

1. 在学校中所学的内容和在工作中发现的实际需要，这两者之间通常会有巨大的差异
2. 由于对软件开发人员培训不足，不少公司曾遭遇过巨额的经济损失。
3. 一些公司在雇用一些刚才学校里出来的毛头小孩后，就会立马将他们组织成“团队”，把他们仍到关键系统的开发中，类似这样的情形屡见不鲜。这真是荒唐透顶
4. 大师——他们是那些已经领到过多个重要软件项目的程序员。一般说来，他们已经拥有10年以上的从业经验，曾在多个不同类型的系统、语言和操作系统上工作过。他们懂得如何领到和协调多个团队，他们是熟练的设计师和架构师，能够游刃有余的变成。组织曾为他们提供管理职位，但是他们不是拒绝就是在接受管理职位后又回去了，或是将管理职位和主要承担的技术角色整合在了一起。他们通过阅读、研究、联系、实践和教学来维持自身的技术水平。公司会把项目在技术方面的主要职责交由大师承担
5. 专业主义价值观和技术敏锐度需要进行不断的传授、培育、滋养和文火慢炖，直至其深植入文化当中
6. 学校能够传授的是计算机编程的理论。但是学校并不会也无法传授作为一名编程匠者所需掌握的原则、实践和技能。这些东西只有经由师徒个体间多年的细心监督和辅导才能获得。软件行业中像我们这样的一批人必须要面对这一事实，即指引下一代软件开发人员成熟起来的重任无法寄希望于大学教育，现在这个重任已经落到了我们身上。建立一种包含学徒期、实习期和长期指引的机制已是迫在眉睫。

正文之后

1. 永远不要签入没有通过全部测试的代码。永远不要
2. 在未来，源代码控制系统是git和类似工具的天下
3. 对于普通规模的团队（5~12名开发人员）而言，问题列表的规模应该在数十个到百来个，不能是成千上万个。不能让跟踪工具成为“装问题的垃圾桶”
4. 持续构建工具：Jenkins - An extendable open source continuous integration server