友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
代码之道-第5部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
书包 网 。 想看书来
获取反馈
在规范书付诸实现之前，越多的眼睛看到它，它就会变得越好，并且将来要求的返工也会越少。如果你想很容易就能获得反馈，你也想别人很容易就能提出反馈，至少你要将规范书草稿放到SharePoint上，并进行变更跟踪和版本控制。做得更好一点，你可以把规范书放到一个维基站点上去，或者贴在功能团队主要活动区域的一块白板上。
撰写规范书的这个过程、反馈和变更管理需要有多正式呢？像我在前一个栏目讨论的那样（即本章的“停止写规范书”那个栏目），正式的程度取决于沟通是否直接，以及沟通的“带宽”有多大。在同一个共享区域、同一个时间、工作在同一个功能的人们，他们可以使用很不正式的规范书和过程；而在不同时区、不同时间、工作在不同功能的人们，他们则必须要有高度正式的规范书和过程。
不管怎么样，你想让规范书随时都可以修改，直到团队认为它不需要再改为止。那你怎么知道规范书不需要再改了呢？答案是，要等到测试团队验证规范书通过了所有的质量检查。
集成质量检查
这是我们目前正在使用的规范书最离谱的地方。各个部门不是把安全、隐私和许多其他问题当作质量检查，而是把它们一节一节单独地写在了规范书中。这是个灾难，原因是：
？ 规范书变得更大并且复杂得多。
？ 作者必须在各节中复制信息。
？ 读者对后面的节次重视不够，导致严重的质量缺口。
？ 设计变得难以理解，因为它们的描述分散在多节之中。
？ 错误和缺口很容易被忽略，因为没有一个节次对设计作了完整的描述。
？ 更新几乎是不可能的，因为一个最新的改动会影响多个节次，牵一发而动全身。
取而代之的是，采用适合于每一份规范书的质量检查，它以一个清单的形式出现，并且每个人都能触手可得。一开始的几个检查对于每个团队都是一样的：
？ 需求清楚、完整、可验证、并与有效的应用范例关联了吗？
？ 设计满足了所有的需求吗？
？ 所有关键的设计决议都被解决并存档了吗？
接下去的一套质量检查也相当基本：
？ 所有的术语都被定义了吗？ ？ 有没有兼容性问题？
？ 安全问题解决了吗？ ？ 故障和错误处理解决了吗？
？ 隐私问题解决了吗？ ？ 谈到安装和升级问题了吗？
？ 用户界面完全可达到吗？ ？ 维护问题解决了吗？
？ 为全球化和本地化准备好了吗？ ？ 备份和恢复问题解决了吗？
？ 对于响应和性能的期望是否清楚并可测量？ ？ 是否有足够的文档用于支持故障检修？
？ 源代码插桩和可编程能力定义清楚了吗？ ？ 有没有潜在的问题会影响打补丁？
各个团队还可以为他们自己或者他们的产品线增加更多的质量检查，解决他们常常面临的特殊的质量问题。
在线资料：规范书检查清单（Spec ）。
这里的关键是，设计节次对功能进行了完整的描述，而质量检查保证了没有东西被遗漏。是的，这意味着设计节次可能会变得非常庞大，以覆盖所有需要涉及的领域。但这些领域不再是把功能按照每一个质量要求展开的累赘品（比如对话框的安全、对话框的隐私、对话框的可达到性等）。
取而代之的是，所有的领域将是功能的逻辑组成部分（比如应用程序编程接口、对话框、菜单等）。重复消除了。每个功能组成部分完整地被描述出来，并且所有的质量要求都融合在了设计情境中。
作者注：一个奇怪而有趣的巧合：在本栏目发表之后的第二天，Office部门把他们的规范书模板做了简化，只使用单独的一个节次来描述设计，并且采纳了我发布的质量检查清单。尽管我不能对这个改变邀功，但我的成就感着实得到了满足。
书 包 网 txt小说上传分享
差别在哪？
如果增加了所有的这些检查和测试，你可能会怀疑我根本就没有对规范书作出简化。其实，这里的最大改动是：
？ 节次的数量减少到了只剩下3个（需求、设计和问题）。
？ 设计在一个节次中得到了完整的描述。
？ 所有功能和质量上的需求都可以被验证。
我也已经谈到了，我们还有机会把规范书写得不那么正式一点，并且更容易被理解。
那么谁该为糟糕的规范书负责呢？其实我们都有责任。不过，糟糕的规范书主要还是由不良的习惯和糟糕的工具造成的。只要做一些小小的改变，并且使用大大简化的模板，我们就能改进我们的规范书，改善部门之间的沟通，并且促进工种之间的关系。总而言之，这样做可以让我们在微软工作得更加开心而富有效力。
第9章
成为管理者，而不是邪恶的化身
本章内容：
2003年2月1日：“不只是数字——生产力”
2004年9月1日：“面试流程之外”
2004年11月1日：“最难做的工作——绩效不佳者”
2005年9月1日：“随波逐流——人才的保持和流动”
2005年12月1日：“我能够管理”
2006年5月1日：“不恰当的比较——病态团队”
微软文化中有这么一部分：“不要抱怨任何事情，除非你已经为它找到了建设性的改进意见。”没错，我常常抱怨我们的管理层。更糟糕的是，我在这个公司的12年时间中有8年是在做管理者。“那你对管理者的改进有什么建设性的意见呢？”很有趣，你应该这么问。
如今，新任的管理者可以得到相当多的扶持，但是当我第一次成为一名主管的时候，我与以前的管理者共事的经历成为了我惟一的资本。我做得还行，不过我也从工作中和我的导师那里学到了大量的东西。5年之后，我加入了现在的这个组织。给新任主管和经理提供我曾得到过的有效而具体的帮助，成了我工作中头等重要的事。I。 M。 Wright写的关于管理的文章中，很多都直接来自于我为新任管理者准备的资料。
在这一章中，I。 M。 Wright论述了如何进行有效的管理，而不必让你成为恶魔。第一个栏目教导管理者要合理使用度量，并指出了一名卓越工程师所具有的特征。第二个栏目谈到了面试和招聘。第三个栏目带你一起走过了管理绩效不佳者的敏感地带。第四个栏目涉及到了人才的保持和流动。第五个栏目揭示了成为一名优秀管理者的最低要求，以及如何才能从优秀提升到卓越。最后一个栏目传授了把一个病态团队变得健康而富有生产力的秘方。
坦率地说，我从来就没想要成为一名管理者。我已经做了17年成功的个体贡献者和架构师。我最后成为管理者，是因为我对产品有一些自己的想法，我想了解如何去运转起一个业务。令我惊讶的是，我发现管人比编程更加让我着迷和满足。也许其中的部分原因是我当上了爸爸——养育一群孩子跟发展一个团队在很多方面是相似的。但更主要还是因为跟人相比，电脑是可预测的、死板的。哈，当然，电脑能够给你带来惊喜和快乐，但那个程度还达不到人给你带来的。我仍然热爱编程，不过我发现跟人打交道要更加有益得多。
——Eric
小心你希望得到的东西
2003年2月1日：“不只是数字——生产力”
只有我是这样吗，还是外星人接管了我们所有管理者的大脑，让他们深信，数字能够精确地代表一个产品的质量或者一个开发者的价值？我们到底还要忍受多少令人作呕的数据收集、分析和预测，才能让那些被误导的管理者得到足够的满足，以使他们不再来打扰我们、让我们能够做自己的工作？如果我们能够集中精力在编码上面的话，我们其实能够完成比现在多得多的工作，难道只有我一个人内心深处有这种感觉吗？
不过，目前的趋势是，对我们创作的东西及其创作方式做越来越多的“度量”，并且使用这些度量去判断我们产品的优点——还有人的优点。似乎解放我们的大脑是有益的。你是否意识到，有多少自作聪明的管理者靠“编码成功度量”给团队成员评分，然后很轻易地就对他们判断最正确的人放马后炮？
作者注：《Interface》的编辑要求我写一篇关于度量的文章。我不认为这就是当初他们脑子里想要的东西，但最后期限摆在那里，我也交出了他们规定字数内的文字。
《Interface》上的文章是“度量开发者的生产力”，它很好地在用于衡量开发者的各种度量，与极度使用度量的弊病之间做出了平衡。这些弊病中最主要的是，度量很容易被当作“游戏”。管理者基本上总会得到他们所要求的东西。如果写更多行的代码能够让度量结果更好，那他们得到的代码行会比较多。如果更少的代码签入能够让度量结果更好，那他们看到的代码签入会比较少。并不是因为代码变好了或者开发者变好了，而只是因为那样做可以使度量的结果更好看。
只要人们相信他们被用数字来判断，他们就会采取任何必要的措施去确保他们的数字很好看，而不会去管那个度量系统的初衷。毕竟，如果抛开你的方式去做正确的事，结果却得不到你的肯定，他们又何必呢？
那是不是所有的度量都没用呢？不是，只要度量用于跟踪团队和产品的进度，以便达到明确而公认的目标（比如绩效、回归率、发现和修复率、解决客户问题所用的天数等），那它们就很有价值。度量有助于推动团队前进，并且赋予成就客观的内涵。然而，它们绝对不可以代替出色的判断。
作者注：我后来对建设性的度量有了更多的认识。你应该用它们度量令人想要的结果——在理想情况下，应该是基于团队的结果。结果关注在“什么”，而不是“如何”，这样就给大家的改进留出了空间。团队度量驱动的是共享的目标，而不是带有竞争性的病态。“代码行数”不大可能是令人想要的结果，而“从开始到结束，使用更少的时间开发出高质量的功能”才是令人想要的结果，而且这个结果取决于整个团队，而不是个人。
不要试图只在个体开发者的生产力上给一个数字，管理者更应该回答这样的问题，“一个优秀的开发者是由什么组成的呢？”如果答案跟指定一个数字那么简单，可能很久以前我们就都被定理证明的机器取代了。
扮演一个角色
度量开发者的价值的关键是，多想一想开发团队，而不是个人。不同的人给团队带来不同的力量。在判定各个开发者的贡献时，要考虑到他们在团队里扮演的角色。最好的开发者往往不是那些代码写得最好或最快的人。
你不希望整个团队都是主管或都是代码工人，也不希望整个团队都是架构师。每个团队都需要有一个才能上的平衡，这样才会有最好的效力和生产力。
卓越开发者的素质
不过，在“度量开发者”方面还有很多的边缘问题。下面，我将列出我认为的、卓越开发者具备的一些明显特征：
？ 他们知道他们正在做什么。当你问卓越开发者，为什么那里有特定的某行代码或某个变量，他们都能说出理由。有时候他们给的理由不那么美妙（“那行代码是我从其他地方抄过来的，它使用了那个结构”），但他们的理由永远不会是，“哈，我不知道，它看起来能够工作。”
？ 他们不相信魔法。这是上一条的必然结果，既然他们知道自己正在做什么。对于黑盒的应用程序编程接口、组件或算法，卓越开发者会感觉不舒服。他们想要知道那些代码是怎样工作的，以免被错误的假设或“有漏洞的”抽象伤害到（比如一个字符串类，它在实现简单的字符串连接时，隐藏了内存分配故障或所需的O（n2）运行时间）。
作者注：赏你一个我最喜欢的“Joel on Software”栏目：“The Law of Leaky Abstractions”。请访问。
译者注：有一种衡量算法复杂度的方法叫大O表示法，它把一个算法的运行时间用输入量n的函数来表示，典型如O（1）、O（log（n））、O（n）、O（n*log（n））、O（n2）等。O（n2）表示某个算法的运行时间随着元素个数的增加呈平方增长，显然其效率比较差。
？ 他们了解客户和业务。我在第7章“职业生涯历险”的“生活是不公平的”栏目中详细讨论了这一点。卓越开发者知道事情的实质，他们能够分出轻重缓急并且做出恰当的权衡。
？ 他们把客户和团队放在优先于自己的位置。卓越开发者不会亵渎任何任务，他们认为没有哪个客户是不重要的。
？ 他们有不妥协的精神和道德规范。尽管个人喜好可能会改变，卓越开发者会一如既往地关注他们如何完成工作，以及怎样去跟其他人互动。不管是他们选择的算法还是他们写的e…mail，他们都会对自己高标准、严要求，始终不会动摇他们的核心价值观。
？ 他们有杰出的人际沟通技能。尽管没有很多的开发者能够主持好游戏或演出，卓越开发者能够很好地跟别人相处，尊重别人，并且跟人进行清晰、有效、恰当的沟通。他们不选择欺凌或胁迫（尽管他们可以那么做），而选择合作。（关于这一点，请同时参考第8章“自我完善”的“要么听我的，要么走人”栏目。）
？ 他们有一个宽广的支持网络。卓越开发者能够认识到别人身上的卓越之处，并且他们相互欣赏。他们能快速发展起一个相互支持的联系网络，使得他们比单一个体要有效力得多。
关于卓越开发者的概括性特征，我还能列出其他更多的方面：关注质量、指导别人、表现出非凡的设计技能等等。
这些形容卓越工程师的特征中，没有哪个是可以被很容易地度量的。
你要做法官
在迫不得已的时候，作为管理者的你必须评判你的团队，你要尽可能地做到公平，并且考虑到他们每一个人所扮演的角色。从其他团队拿些例子过来参考，会有助于你观察你自己团队的开发者；这也是为什么说标度会议如此有价值、有启发性、并且承受它的痛苦也值得的原因了。
但是请记住，没有哪个标度或等级可以代表一个人。人实在是太复杂了，即使是最客观的度量也会被所用的透视法所扭曲。作为高等动物的人类，我们要去了解和尊重，这是完全释放人类潜能的关键！
2004年9月1日：“面试流程之外”
招聘像一个巨大的吸尘器，它把我所有的时间都吸到了校园。但在快速聘用到一位高质量的候选人之后，我就会觉得曾经花费的每一分钟都是值得的。所幸的是，在招聘过程的大部分时间内，我不依赖于任何人。这让大量候选人向我“滚滚涌来”。不过到了面试流程，情况就不一样了。
嘿，如果我能够跳过面试流程的话，我真想那么做！再没有时间安排的麻烦，没有为了一个时间空档而延误几个星期，没有可怕的面试问题，没有失踪的反馈，没有“两可”的聘用，没有含糊杜撰的垃圾标准，没有重复思想的负担，没有最后时刻的放弃。
但是，你不能跳过面试流程——绝对不允许。如果比尔？盖茨想要到我的团队来任职，我也将让他经历面试流程。我不是想冒犯他！只是想让他走过这个流程，确信他是否能够成功地融入到团队中去——如果他得不到聘用，�
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！