程序员的职业素养

 

成为专业的程序员，需要什么样的态度、原则、行动？

本书记录了作者一生所做的“蠢事”,磕磕绊绊成为一名毫不逊色的专业程序员。

《程序员的职业素养》——总结

前言

         在Bob大叔的整本书中，重点传达了一种精神，就是专业精神。解释出来会有很多种精神，但是我觉得概括下来，就是工匠精神，就是责任感。要对项目负责，对代码负责，对公司负责，对个人负责。对于整个项目而言，不合乎情理的需求，可能对项目造成很严重的损害。就像一个任务在保证质量的前提下，需要10天才能完成，可是提出需求需要3天完成，我们身为专业开发人士，不能一味的为了迎合需求，就勉强答应。而答应下来，必然的结果就是抛弃项目质量优先的原则，为了追赶工期，不顾项目的质量问题，从而勉强达到需求。这样导致的必然结果是这段糟糕的代码会对日后的工作产生更多负面的影响，影响其他模块的工作，拖慢工期，或者又需要拿出额外的时间来对这段糟糕的代码进行重构。不管哪种情况，都必然会导致更长的开发周期，为了节省着几天的时间，赔上更多的时间，得不偿失。所以，我们身为专业人士，应该站在专业人士的角度，理性的分析需求的可行性，如果可行，才对需求做出承诺，言必信，行必果，做出承诺就代表我们一定会完成这个任务。如果不可行，我们应该当即向业务人员或者客户说明，指出需求中的弊端，说明这样对整个项目的重大影响，对于这样的需求不能容忍包庇。在不接受需求的情况下，我们身为专业人员，应当尽可能的提供一种备用方案，在保证质量的前提下，来间接满足需求。很多时候，客户其实也并不知道他们想要的是什么，或者也并不是想要在这么短时间内完成，这只是客户用来和开发人员博弈的手段，我们在沟通过程中，做到坦诚相待，诚信，客户能体会到。

         在对项目负责的同时，我们身为公司的员工， 有义务为公司负责。公司付给我们薪水，给我们创造好的工作环境甚至还有生活环境，我们应该感恩，对于公司有认同感，有责任感。在接到公司任务时，应该对任务负责，精益求精，而不是敷衍了事。对于软件产品而言，任何一部分糟糕的代码，都将以整个软件的名义，给用户造成糟糕的用户体验，这对于整个软件项目来说，是恐怖的。如果说这段代码还对项目中别的模块造成恶性影响，那将简直是灾难。而且我们身为开发人员，对于我们编写的每一段代码，都是我们自有知识的固化，糟糕的代码，意味着我们的知识的糟糕、贫乏。对自己的代码不负责，就相当与对自己的知识不负责，我觉得任何人都不会想让自己看起来很没学问吧。一个项目团队，在编码方面，由架构师制定整个软件项目的结构，之所以不是由架构师直接完成整个项目，就是因为还需要程序员来负责细节方面的控制，这是程序员的责任和义务，所以，如果连细节和质量都控制不好，那也不好意思说自己是程序员，完成了程序员的工作。

         在完整看完本书之后，我对于Bob大叔想给我们传达的东西做了一些简单提炼，下面将分几个模块介绍一下。

第一节 说“不”和“是”

         在面对不专业的需求时，开发人员应当勇敢的提出异议，向客户或领导说明情况，从保证项目质量的角度出发，尽可能的贴近需求。不能为了讨好客户和领导，而偷工减料，以降低项目质量的代价，来达到客户和领导的要求。在需求不能接受的时候，开发人员和客户或领导应当进行协商，双方都明确的提出自己的需求，然后双方协商一个最好的方案进行。

         在项目周期中的任何时期都不能放松这个标准，不管在哪个时期放松标准，都将对整个项目造成严重的影响。当到了项目的关键时期时，越要更严谨一点，越要勇敢的说“不”，因为越到关键时刻，放松标准对项目的影响越大。

         身为专业人士，在做出决定前，要有专业人士的责任感，要对你做出的决定负责，要站在专业的角度，全面清晰的分析这个决定可能会造成的影响，在遇到会对项目质量造成损害的，应该提前说出来，避免拖到项目后期，对项目质量和项目工期产生更大的影响。

         在经过仔细的思考后，做出承诺，那就要说到做到。言必信，行必果。只有做到诚信，才能让别人感到专业，才能让你说出的话，提出的建议，更加的有重量

         对自己的承诺负责这是我们自己必须做到的，但是很多时候放在别人身上可能并不一样了。有时候，我们需要学会分辨他们口中的伪诺言，以免获取到错误的信息，从而影响自己的工作、项目的周期、项目的质量等。

         有些时候，我们对于任务的预估也会有些差错，可能会无法践行诺言，那么在这种情况下，最重要的是我们应该尽快向承诺对象发出预警，越快越好，越早越好，越快越早才能让承诺对象有缓冲期，可以调整策略，降低无法践诺将要造成的影响。

         我们身为专业人士，不一定需要对所有事情说“是”，但是，我们应该想到创新办法，尽可能做到有求必应。当我们做出肯定回答时，我们应该使用承诺用语，以确保各方能够明白无误的理解承诺内容。

第二节 编码

         在编码时，要有一个好的结构，模块化清晰。当开发增量时，不能破坏软件之前的功能。自己写的代码不应当对自己的写的代码之外的代码造成不好的影响。在开发过程中，要不断优化代码结构，在不断的重构中，代码性能和稳定程度都会得到增强。要勇于修改代码和善于修改代码。在编码的同时，一定要随时进行测试，对于每一个执行单元，都要设计单元测试。同时也要使用测试驱动开发方法来提高代码的可测试性。对于测试，应该保持认真和严谨，不能为了赶工期，应付式的进行测试，要保证整个项目的质量。认真严谨的测试，对于我们保持敏感的错误感知能力有很大的作用，在编码过程中，敏感的错误感知能力很重要，越早的发现Bug，对于项目影响就越小。在编码过程中，还要注意多从大局出发，不要把视角局限在一个角落，要保持自己理性的思考能力，局限在一个角落编写出来的代码，对于整个项目而言很鸡肋，后期还是需要进行重构的。

         专业人士应该对与自己的时间有一个很好的管理。知道什么该做，什么不该做，知道在什么时间做什么事情。就比如公司发给我们工资，那么我们就应该在工作时间为公司创造利益，而不是在工作时间做自己的事情，所以其实每周应该制定60小时的工作时间，其中40小给公司，20小时给自己。在20小时中，我应该多读书、多练习、多查阅，提高自己的职业水平，才能获得更好的职业待遇，过上更好的生活。同时，在遇到疲劳、焦虑、烦躁等状态时，不应该勉强编码，在这种状态下，很可能眼睛盯着屏幕，手放在键盘上，但是大脑中却有一个后台进程一直在不断进行，或者时根本无法集中精神，这样编码出来的结果很可能就是后期的重构。每个人的注意力都是有限的，Bob大叔在书中的原话是说每个人的注意力就像是地下城里面的疲劳值一样，会逐渐递减，但会缓慢回复。所以，每个人需要学会怎样高效的使用注意力。身为专业人士，应该对自己的能力、自己能保持饱满状态的时间，有一个清晰的认知，在自身无法聚精会神的时候，应当进行适当的休息，以保证自己写出的代码质量，避免匆忙之间写出的代码错误过多，造成后期的重构，需要更多的时间来填补这个坑。专业人士要确保自己已经将睡眠、健康和生活方式调整到最佳状况。这样才能确保在每天的8小时工作时间全力以赴。

第三节 团队与协作

         形成团队是需要时间的。团队成员首先要建立关系，需要进行沟通，经常的沟通能增进团队成员之间的互相了解，以及学习互相之间如何相处，如何配合，才能做到在项目中互相协作，成员之间需要了解彼此的癖好、强项、弱项，最终，才能凝聚成一个团队。在团队克服个体差异性，默契配合、彼此信任，形成真正有凝聚力的团队之后，不应该立即拆散这个团队，只需要不断的给这个团队任务就行，他们会不断的磨合，不断提升彼此的默契，从而不断的提升团队的工作效率。

         在团队开发中，要注意沟通。不要害怕让其他人看到你的代码，不要在自己的代码上树起围墙，要互相交流。真正的专业人士是不会阻止别人来修改自己的代码的，和别人分享交流是一种快速有效的学习方式。在开发时遇到问题，结对编程是解决问题最有效的方式。专业人士之所以结对，是因为结对是代码复查最好的方式，系统中不应该包含没被其他程序员复查过的代码。最有效率最有效果的代码复查方式，就是以互相协作的方式完成代码编写。

         在团队交流中，应当保持热情，积极交流。同时要互相帮助，给与帮助，接受帮助，乐于帮助。

         当你在团队中处于学徒期时，有一名老师手把手带你那当然是极好的。但是如果没有那种条件，那应该仔细观察他人的工作，从中学习，快速成长。在学徒期，应十分密集的进行结对编程，学徒要了解设计原则、设计模式、各种纪律和固定的操作方式等，还要学会TDD、重构、预估等技巧。

第四节 实用技艺

         1.专业人士必须精通的事项：

         设计模式，必须能描述GOF书中的全部24中模式，同时还要有POSA书中的模式的实战经验；

         设计原则，必须深刻了解组件设计原则和SOLOD原则：

                   1）一个对象只承担一种责任，所有服务借口只通过它来执行任务

                   2）程序实体，比如类和对象，只对扩展行为开放，对修改行为封闭

                   3）子类应该可以用来替代它继承的类

                   4）一个类对另一个类的依赖应该局限在最小的借口上

                   5）依赖抽象层（接口），而不是具体类

         方法，必须理解XP、Scrum、精益、看板、瀑布、结构化分析以及结构化设计等；

         实践，必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程；

         工件，必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图标、流程图和决策表；

         2.要想保持潮流，保持进步，就要多练习、多学习。读书、看相关文章、关注博客和微博、参加技术大会、访问用户群、多参与读书和学习小组。

         3.测试驱动开发。测试驱动开发应该是测试先行，将代码分成很多小模块，进行单元测试。这样，当代码有改动时，只要进行这些单元测试，便能知道是否会影响原有的功能。同时，由于单元测试做的很细，在对于错误排查方面也更加容易，更加能够跟踪到错误点。测试驱动开发所形成的大量单元测试，就相当于一份完善的文档，在单元测试中，可以看到关于方法的任何调用形式。测试代码的一个问题是隔离待测试代码，也就是解耦。如果要测试的代码调用了另一部分代码，那就需要想办法解除之间的耦合性，这就迫使你去思考什么是好的结构。测试驱动开发的三条法则：

                            1）在编写失败的单元测试之前，不要编写任何产品代码

                            2）只要有一个单元测试失败了，就不要编写测试代码；无法通过编译也是一种错误情况。

                            3）产品代码恰好能够让当前失败的测试代码通过即可，不要多写。

         4.预估方法。在项目中，进度安排管理是很重要的事情，要安排好进度任务，那就要对任务耗时有一个正确的预估。Bob大叔在书中介绍了一种预估办法—PERT方法，主要包含三个要素，乐观预估（O）、标准预估（N）、悲观预估（P）。由这三个基础量，可以得出一个比较靠谱的期望完成时间：u = （O+4N+P）/ 6，同时概率分布标准差，既波动范围，

m = （P - O）/ 6

 

 

---

1.专业主义

测试工作：编写好代码，没有完全测试就交付了。后期维护所花的时间和精力都是现在的几十倍！

对不完美的代码负责，尽可能少点BUG。

不要破坏程序的结构，结构良好的代码更灵活。

所有软件项目要易于修改。

童子军训练守则：每一次检入代码都要比上一次更加简洁。

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

        设计模式。必须能描述GOF书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验。

        设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。

        方法。必须理解结构化设计。

        实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成、结对编程

        工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图、决策表。

业精于勤。真正的专业人士往往勤学苦干，以求自身技能的纯熟精炼。

学习的第二个最佳方法是与他人合作。一起编程、一起练习、一起设计、一起计划、这样他们可以从彼此身上学到很多东西，而且能在短时间内更高质量的完成更多的工作。

了解业务领域。你未必需要成为该领域的专家，但你 仍需要勤勉，付出相当的努力来认识业务领域。开始新领域的时候，应当读一两本该领域的书，或者与客户、专家交流了解他们的原则和价值观念。

与客户保持一致。客户的问题就是你的问题，每次开发，都应该站在客户的角度去思考。

---

2.说“不”

专业的程序员遇到需求不能短时间完成时会坚决说不。

Mike：“我要整个登录界面，必须要能登录！”

Paula：“要完成需要2周的时间，现在可以给你做一个假的登录页面。如果你把密码忘记了，也没有办法修改密码的时候发邮箱；页面顶部不能有新闻栏在滚动；帮助按钮和浮出说明不能用；没法保存cookie以便下次登录；也不会有任何权限限制。但你确实可以登录，这样可以吗？”

Mike：“好极了！”

这个例子，他们达成了最佳结果。

为什么重要吗？

需要解释为什么登录要花那么长时间吗？其实，“为什么”远不如“事实”重要。事实是登录页面还需要2周来完成，为什么需要2周，只是个细节。

要有团队精神

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

试试看

“尝试”二字都这么讲究啊！作者的意思是：如果你对上级说了“我试一下”，说明还有余力可施，那么就意味着你在前面的工作中并没有尽全力；意思是你在加把劲可以达成目标；而且，这也是一种表示你将再接再厉去实现目标的承诺，这样压力就由你来扛了。

如果承诺“尝试”，你其实也在承诺将改变自己原来的方案。你是在承认原来的方案存在不足。如果承诺“尝试”，其实是在告诉他们，你有新方案。新方案是什么，你对自己的行为作出哪些改变？你说你“尝试”，那么你的做法将会有什么不同？

如果你此前并未有所保留，如果你没有新方案，如果你不会改变你的行为，如果你对自己原先对估计有充分对自信。从本质上讲，承诺“尝试”就是一种不诚实对表现。你这么做对原因可能是为了护住面子或避免冲突。

---

3.说“是”

我们常常会因为直觉摔跟头。有时我们轻信他人会说话算话说到做到，但事实上他并没有像承诺但那么去做。

真正的承诺听起来是怎样的？

真正的承诺是说话的人显得在“我”的掌控范围内，而不是表现的自己是某种情势的受害者。说出完全肯定的话语。

未做到言必信，行必果的原因

·    寄希望于别人身上做这件事

你只能承诺自己完全掌控的事。如果你的目标依赖于另一个团队的模块，你虽然无法自己承诺可以完成并无缝集成。但是你可以采取一些具体行动，你可以承诺：和基础设施组长谈谈，彻底理清模块间的依赖关系；在本周内，至少和负责构建的同时碰头三次，确保你对代码改动没有影响；编写自用的构建脚本，对模块进行集成测试。

·    不确信是否真的可以完成

如果无法在发布前修复余留的bug，你也应该坚持采取行动，缩短与最终目标的距离：把bug全部过一遍，努力重现这些bug；和发现bug的QA谈谈，看下bug重现的现场；用本周能支配的时间，尝试逐一修复bug。

·    也有真的无能为力

有些事情你可能没有预料到，这很现实。但如果你仍然希望自己能够不负众望，那就赶紧去调整别人对你的预期，越快越好。

场景：

Marge：XXX任务真的需要在下周一之前完成，真的至关重要。你能在想象其他办法吗？

Peter：这样，周末加班我能保证在下周一早上之前完成任务。甚至下周一早上我还会过来公司看看，确保进度顺利。不过之后我就会回家休息，知道周三才会来上班，你看这样行吗？

总结：

这样很公平，Peter知道自己如果加班的话，一定可以完成代码修改和文档编写的任务。但他也明白，在这之后需要几天休整，才有精力回来继续工作。专业人士对自己的能力极限了如指掌。他们十分清楚自己还能保持效率加班多长时间，也非常明白要付出的代价。

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

---

4.编码

能够感知错误非常重要。如果你具备出错感知能力，说明你已经能够非常迅速的获得反馈，能够更快的从错误中学习。作者发现，要精熟掌握一项技艺，关键是要具备“信心”和“出错感知能力”。

下面是作者个人的一套编码原则：

·    编码要聚精会神，因为编码时你必须平衡互相牵制的多种因素。

首先，代码能够正常工作。必须了解当前要解决什么问题以及该如何解决。必须确保编写的代码忠实遵循解决方案。必须管理好解决方案的每一处细节，并且使语言、平台、现有架构以及当前系统的所有问题和平共处。

其次，代码必须能够帮你解决客户提出的问题。很多时候，客户提出的问题其实并没能真正解决他们的问题。这有赖于你去发现这些问题并与客户交流，以确保代码能够满足客户的真实需求。

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

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

同时还要平衡好所有这些关注点颇为困难。长时间维持高度的聚精会神是很有难度的。再加上在团队或阻止中工作时常会遭遇到各种问题与干扰，以及需要留和关注各种日常琐事。总之，编码时无可避免的会收到各种干扰。

在心烦意乱的状态下工作，只会造成严重的浪费。如果感到心烦意乱，千万不要编码。要找到一种方法来消除干扰，让心绪平静。

疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指要遵循纪律原则而非成为时间工作的工作狂。要确保自己已经将睡眠、健康的生活方式调整到最佳状况，这样才能做到每天的8小时工作时间内可以全力以赴。

·    焦虑时写代码

如果我为妻子发生的争吵、客户危机或者家中生病的小孩而感到忧心忡忡，就无法集中注意力。这时我不该写代码，而应该先解除焦虑情绪。

关键所在是学会如何关闭这些“后台进程”，或至少要能够降低其优先级，这样焦虑就不会造成持续的干扰。

我使用将时间分块的方法来解决问题。我会花专门的一块时间，也许是一个小时，来处理造成焦虑的问题，而不是强迫自己忍受着内心的焦虑煎熬继续编程。如果小孩生病来，我会打个电话询问一下情况；如果和妻子之间有争论，我会打电话和她好好沟通清楚；如果出现金钱问题，我会花些时间思考如何才能处理好财务问题。

专业开发人员善于合理分配个人时间，以确保工作时间中尽可能富有成效。也就是说，在家中就应该专门安排时间去解决焦虑，这样就不会把焦虑情绪带到办公室。

流态区(关于高效率状态)

一些曾经进入这种状态但终又从中摆脱出来的人给处了一点儿忠告：避免进入流态区。这种意识状态并非真的极为高效，也绝非毫无错误。这其实只是一种“浅层冥想”状态，为了追求所谓的速度，理性思考的能力会下降。问题就是，在流态区的状态下，你其实没有顾及全局，因此，你可能会做出一些后来不得不推到重来的决策。

我感觉自己要进入流态区时，就会走开几分钟换换脑筋。

中断

假设你在专心工作，有人打断了你，你会怎样回应？你会粗暴相待吗？粗暴相对的回应方式通常是因为流态区所致，你被他人从流态区拉出来。

但是，有时候并非是因为流态区的责任。而只是你正在努力理解一些十分复杂的东西，这要求你必须全神贯注。有一些解决办法可以应对：

结对是用以应对中断的好办法，当你被中断时你的搭档能很快的帮你恢复被打断前的思维。

另一种是采用TDD。如果有一个失败的测试，它就能帮你维护代码进度的上下文。

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

阻塞

有时候，死活就是写不出代码。干坐在电脑前，但什么都写不出来。

这时候，通常你会去找一些其他事情干。去查看邮件，去翻阅推特，去翻看些书，检查进度或者读点文档。

哪些原因会导致这些阻塞呢？前面我们已经谈及许多因素。对于我而言，另外一个主要都因素就是睡眠。如果睡眠不足，我就什么代码也写不出来。其他因素还包括焦虑，恐惧和沮丧等。

·    有一个很简单都好办法可以解决问题，这个办法几乎屡试不爽：结对编程。

·    “创造性输出”依赖于“创造性输入”

我平时广泛阅读，不放过各种各样都资料。包括软件、政治、生物、航天、物理、化学、数学等等，不过，科幻小说最能激发我的创造力。

保持节奏

软件开发是一场马拉松。你无法全程一直以最快都速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜。专业程序员同样也应该保存好自己的精力和创造力。

·    知道何时应该离开一会

没解决这个问题就不能回家？不，你应该回家。创造力和智力来自于大脑都高速运转。当你感到疲劳时，他们就不翼而飞了。

当你碰到困难而受阻时，当你感到疲倦时，就离开一会儿。

进度延迟

你总有一天会遭遇延迟都情况。管理延迟都诀窍，是早期检测和保持透明。你应该根据目标定期衡量进度，使用三个考虑到多种因素的期限：乐观预估，标称预估，悲观预估。尽量严守这三个时间点。

加班加点

你老板会说加班加点行吗，周末加班行吗？肯定有办法挤出时间准时完成开发需求的。加班确实游泳，而且有时也有必要。但是这么做风险很高，在额外加班20%的工作时间内，其实你并无法完成20%的额外工作。

因此，不应该采用额外加班加点工作方案，除非以下三个条件可以满足：个人能挤出时间；短期加班，最多加班两周；你的老板有后背预案。最后一条最关键。

交付失误

在各种不专业的行为中，最糟的是明知道任务没有完成却谎称已经完成！

定义“完成”

可以通过创建一个确切定义的“完成”标准来避免交付失误。最好的方法是让业务分析师和测试人员创建一个自动化的验收测试，只有完全通过这些验收测试，开发任务才能算完成。

帮助

编程并非易事，越年轻的程序员对此可能越没有什么感觉。毕竟代码只不过是一堆if和while语句，随着经验渐长，你会开始意识到把这些if和while语句组装在一起的方式十分重要。

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

帮助他人

因此，互相帮助是每个程序员的职责所在。在帮助他人上，不要让自己看起来十分仓促，仿佛只是随便应付，要全情投入到任务中。当你离开时，可能会发现自己从中收获的东西比给予的还要多。

接受他人的帮助

如果有人向你伸出援手，要诚挚接受，心怀感激地接受帮助并诚意合作。不要因为自己进度压力很大，就推开伸来的援手，不妨给他半个小时的时间。如果到时那个人不能真正的帮助你，再礼貌的致歉用感谢结束谈话也不迟。要记住！如同要以乐于助人为荣一样，也要以乐于接受别人的帮助为荣。

辅导

辅导缺乏经验的程序员是那些经验丰富的程序员的职责。培训课程，书本都无法替代。因此，花时间手把手的辅导年轻程序员是资深程序员的专业职责所在。同样道理，向资深导师寻求辅导也是年轻程序员的专业职责。

---

5.测试驱动开发(TDD)

三项法则：

·    在编好失败单元测试之前，不要编写任何产品代码

·    只要有一个单元测试失败了，就不要在写代码；无法通过编译也是一种失败情况

·    产品代码恰好能够让当前失败的单元测试成功通过即可。不要多写。

---

7.验收测试

需求的沟通

通常业务方会突然更改需求，所以一般需要一个地方记录。

过早的精细化

业务方还没启动项目，就要精确知道最后能得到什么；开发方还没有评估整个项目，就希望精确知道要交付什么。

·    不确定原则：东西画在纸上和真正做出来是不一样的。业务方看到真正的运行情况就会意识到，自己想要的根本不是这样的。一看到已经满足的需求，关于到底要什么，他们会冒出更好的想法。

·    预估焦虑：开发人员也会掉进精确化的陷阱。首先，即便拥有全面准确的信息，评估也通常存在巨大的变数。

“完成”的定义

完成有各种说法，例如已经有足够的信心把这项功能部署到生产系统；可以准备QA程序；已经写完了代码并且跑通了；还没有真正测试过。

专业程序员所说的完成意味着代码都写完了，所有的测试都通过了，QA和需求方已经认可。

怎样达到这种程度的完成，同时不影响迭代的速度？你应该编写整套的自动化测试，他们全部通过意味着满足了所有的要求。专业开发人员会根据自动化验收测试来定义需求。他们与业务方和QA一起工作，确保自动化测试能够真正覆盖完成所需的各项指标。

验收测试

手工测试成本真的太高了，专业程序员会编写自动化测试验收自己的代码。

有许多开源的可以完成自动化的验收测试。借助这些工具，你不是程序员也可以阅读、理解、编写。

验收测试什么时候写，由谁来写？在理想状态下，是由业务方和QA写作编写测试，程序员来检查测试之间是否由冲突或矛盾。但实际上，业务方通常没有时间，或者有时间也难以达到所需要的细致程度，所以他们通常会把测试交给业务分析员、QA和开发人员。

如果只能由开发人员来写测试，应当确保写测试的程序员与开发测试功能的程序员不是同一个人。

通常，业务分析员测试“正确路径”，以证明功能的业务价值；QA测试错误路径、边界条件、异常、例外情况。

测试的协商与被动推进

写测试的人也是普通人，也可能犯错误。身为专业开发人员，与编写测试的人协商并改进测试是你的职责。绝不能被动接受测试，更不能对自己说：“测试是这么要求的，我就这么办”。请记住，你的职责是协助团队开发出最棒的软件。也就是说，每个人都需要关心错误，并协力改正。

验收测试和单元测试

验收测试不是单元测试。单元测试是程序员写的，它是正式的设计文档，描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。

验收测试是业务方写给业务方的(虽然可能最后是身为开发者的你来写)。它们是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。

尽管两者测试的可能是同一个对象，其机制和路径却是不同的。单元测试是深入系统内部进行，调用特定类的方法；验收测试是系统内部，通常是API或者是UI级别进行。

单元测试和验收测试首先是文档，然后才是测试。它们的主要目的是如实描述系统的设计、结构、行为。但是，它们真正的价值不在测试上，而是在具体指标上。

图形界面与其他因素

尽可能的减少GUI测试。GUI很容易变化，GUI测试越多，维护它们的难度就越大。

持续集成

务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。整套持续集成系统应该由源代码管理系统出发。只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试，测试结果会用电子邮件的方式发送给团队所有人。

持续集成如果失败了，团队里的所有人都应该停下手机的活，看看如何让测试通过。在持续集成系统里，失败的集成应该视为紧急情况。

总结

交流是件麻烦事。尤其是开发方和业务方交流关于程序的细节时，更是如此。通常，各方握手言欢，以为其他让都明白自己的意思。双方以为取得了共识，然后带着截然不同的想法离开，这种事太平常了。

要解决开发方和业务方沟通问题，我所知的唯一有效的办法是编写自动化测试的验收测试。这些测试很正式，所以结果具有权威性。它们是无可挑剔的需求文档。

---

9.时间管理

严格的时间管理的例子：

·    我每天早上5点起床，骑自行车上班，6点可以到办公室。这样，在一天的嘈杂开始之前，我有两个半小时安静时间。

·    一到公司，我就拟定当天的计划。以一刻钟为单位，写下这段时间要做的事情。

·    头3个小时安排的很满。每小时都会流出15分钟的激动时间，这样可以处理计划外的紧急状况，同时也不干扰计划内的工作。

·    午饭后的时间没有安排，因为那时候工作节奏并不快，我也得静心准备下午的工作。午后这段时间难得没有任何干扰，我会安心做最重要的事情，直到突发状况出现。

会议

会议的成本是每人每小时200美元。这个数字包含了工资、福利、设备损耗等因素。下次开会，不妨算算会议的成本。

有两条真理：会议是必须的；会议浪费了大量的时间。

拒绝

受到邀请的会议没有必要全部参加。参加的会议太多，只能证明你不够专业。你应该理智的使用时间，所以必须谨慎选择，应该参加哪些会议，礼貌拒绝哪些会议。

邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。所以，如果你受到会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则不必参与。

确定议程与目标

有时候确实需要所有参与者坐在一起来实现某个目标。为了合理使用与会者的时间，会议应该有清晰的议程，确定每个议题所花的时间，以及明确的目标。

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

迭代计划会议

在敏捷开发武器库中，这大概是难度最大的会议了。如果做的不好，可能浪费大量的时间。开好这种会议需要技巧。

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

凭我的经验，每轮迭代中，这类会议所花的时间不应当超过5%。如果一周为一个迭代周期，这类会议时间应当限制在2小时内。

迭代回顾和DEMO展示

这类会议在迭代的末尾召开。团队成员讨论本轮迭代中什么做的对，什么做的不对。业务方可以看到最新工作成果的demo。如果组织不当，这类会议可能浪费很多时间，所以不妨在最后一天下班前45分钟召开。20分钟回顾，25分钟来演示。请记住，这类会议只牵涉到最近一两周的工作，所以没有太多内容要讨论。

争论

Kent Beck 曾告诉我一个深刻的道理：凡事不能在5分钟内解决的问题，都不能靠辩说解决。争论之所以要花更多的时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。

技术争论很容易走入极端。每一方都有各种说法来支持自己的观点，只是缺乏数据。在没有数据的情况下，如果观点无法在短时间内达成一直。唯一的出路是：用数据说话。

有人会表现的非常被动。他们同意结束争论，之后却消极对待结果，拒绝为解决问题出一份力。他们会安慰自己：既然其他人想这么办，就这样吧。这可能是非专业的行为中最糟糕的了。千万不要这样做。如果你同意了，就必须拿出行动来。

要小心这类会议：它们的目的是发泄情绪，或者让大家站队。如果会议上只有一面之辞，就要避免参加。

注意力点数

编程是需要持续投入精力和注意力的智力活动。注意力是稀缺的资源，它类似于魔力点数。如果你用光了自己的注意力点数，必须花一个小时或者更多时间做不需要注意力的事情，来补充它。

忧虑和分身也会消耗注意力点数。昨晚上的夫妻吵架，今儿早上的汽车剐蹭，上周忘记付款的账单，都会迅速耗光你的注意力点数。

睡眠

睡眠的重要性怎么强调都不为过。好好睡上7个小时。专业开发人员会安排好他们的睡眠，保证清晨有饱满的注意力点数去上班。

恢复

在你不集中注意力的时候，注意力点数可以缓慢恢复。漫步一段长路，与朋友聊天，看看窗外，都有助于恢复注意力点数。

或者沉思，反省，小睡一会。

时间拆分和番茄工作法

我用来管理时间最有效办法之一。其基本思想：把计时器设定到25分钟，倒计时期间不要任何事情打扰你工作。如果电话响了，接起来并礼貌告诉人家，请25分钟后打过来；如果有人来打断你的问题，礼貌的问他是否能过25分钟再来问。

计时器响后，停下手上的工作，去处理25分钟内遇到的其他的事情。之后休息5分钟。然后，在把定时器设定为25分钟，开始新的一个番茄时间。每完成4个番茄时间，休息30分钟左右。

总结

专业开发人员会用心管理自己的时间和注意力。他们知道优先级错乱的诱惑，他们也珍视自己的荣誉，所以会抵制优先级错乱。他们永远有多种选择，永远敞开心扉听取其他解决方案，他们从来不会执拗于无法放弃的解决方案。

---

10.预估

问题在于，不同的人对预估有不同的看法。业务方觉得预估就是承诺。开发方认为预估就是猜测。两者相差迥异。

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

不幸的是，大多数开发人员都很不擅长预估。这不是因为他们没有掌握关于预估的诀窍—根据没有这样的诀窍。预估的偏差总是很大，原因在于我们并不理解预估的实质。预估不是定数，预估的结果是一个中概率分布。

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

---

11.压力

不要惊慌失措

正确的应对压力。长夜漫漫无心睡眠，无助于更快的解决问题。呆坐着烦躁不按也于事无补。而你可能最会犯的最严重的错误就是鲁莽仓促。要避免产生孤注一掷的想法。相反，要放松下来。对问题深思熟虑，努力寻找可以带来最好结果的路径。

沟通

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

依靠你的纪律原则

当事情十分困难时，要坚信你的纪律原则。之所以你会将之奉为纪律，是因为它们可以指引你度过高压时期，这时候要更加留意全部的纪律原则。

寻求帮助

当你头难发热时，结对编程会让你前进的更快，而缺陷更少。结对伙伴会帮助你坚守原则纪律，防止你手足失措。搭档会捕捉住你疏忽一楼的事情，会提出有帮助的想法，会在你注意力迷失的时候接过你手中的工作继续前进。

总结

应对压力的诀窍在于，能回避压力时尽可能的回避，无法回避是则勇敢直面压力。

---

12.协作

当团队成员能够十分专业的互相协作时，整个团队是最为高效的。

也许我们不是因为编程可以和人互相协作才选择从事这项工作的。但真不走运，编程就意味着与人协作。我们需要和业务人员一起工作，我们之间也需要互相合作。