按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话，最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向，但它对于需要不断创新才能繁荣的技术公司来说，却是个致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀，深深地切入了组织内部看似无关紧要的东西。他毫不吝啬地打出了重拳——偶尔也会故意玷污自己的名声。尽管有一些隐语和例子对于微软内部的员工更有吸引力，但他的智慧和至理名言，大都可以成为整个软件行业的财富。
——Clemens Szyperski，首要架构师
“I。 M。 Wright”写的关于开发时间表的文章真的是太棒了！它在我所属部门参与的基础设施项目上同样适用。
——Ian Puttergill，部门经理
你没有受到任何死亡威胁，是吗？
——Tracey Meltzer，高级测试主管
这一定是个笑话——很坦率地说，这类纯粹的谬论危机四伏。
——Chad Dellinger，企业架构师
Eric是我本人崇拜的英雄——很大程度上是因为他长期以来一直代表着开发社区的一种声音。
——Chad Dellinger，企业架构师
软件工程师很容易就会迷失在他们的代码中，甚至更糟糕的是，他们迷失在过程中。那正是他们迫切需要Eric在“Hard Code”中提出的实用建议的时候。
——David Greenspoon，总经理
我刚刚读完这个月的栏目……我不得不指出，这是我第一次认为你正在推行一个对公司完全错误并且带有灾难性的想法。
——David Greenspoon，总经理
Eric你真了不起？ 几个月之前，我跟我的产品单元经理和一些开发主管恰恰进行过这样的一次对话。
——Scott Cottrille，首要开发经理
我真的很喜欢这些栏目。它们是如此实用，而且还很全面！我喜欢它们的另外一个原因是，当我在指导初级开发人员的时候，我可以把这些栏目推荐给他们；他们也会记住这些栏目，因为它们都是那么地有趣。
——Malia Ansberry，高级软件工程师
Eric，干得好！我觉得你在这个栏目中说得非常中肯。我想，该给管理者传递这样的信息，“不要害怕试验。”事情的真实情况跟理想化的理论之间差别是非常大的。
——Bob Fries，合作伙伴开发经理
我只是想让你知道我有多喜欢你写的文字——它们充满智慧、见解深刻，你还神奇地把本来很严肃的问题变得如此有趣（采用的方法很不错）。
——Niels Hilmar Madsen，开发者传教士
你那篇关于死亡行军的栏目来的正是时候。我们正打算在未来几周内开会讨论功能削减的事情呢！那些我们以前付出很大代价才学到的教训，不知怎么回事，总是轻易就被忘记了；你的栏目对大家起到了很好的提醒作用。
——Bruce Morgan，首要开发经理
我想让你知道的是，我真的很喜欢并感谢你在EE站点上发表的所有文章。不过，直到今天，当我读了“停止写规范书”这个栏目之后，我不得不说，我强烈不同意你的观点。
——Cheng Wei，项目经理
你到底是谁？你跟Eric Brechner都做了些什么？
——Olof Hellman，软件工程师
Eric，我刚刚读完你写的那篇叫“不恰当的比较”的文章。你不知道我有多感激你！你实际上把这个观点传达给了公司里面成千上万的人……你致力于正确领导和管理团队，并把其中的奥秘跟大家分享，对于你的这种热情我真的非常欣赏！
——Teresa Horgan，商务项目经理
序
长期以来，我一直在阅读Eric Brechner以I。 M。 Wright为笔名撰写的栏目。当我第一次见到作者本人的时候，我费了好大的劲才让自己相信，我是在跟同一个人说话。Wright先生非常地自以为是，然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好，他看起来更像Clark Kent。（译者注：Clark Kent是“超人”的名字，他具有超强的本领，是一个虚构的超级英雄，美国漫画中的经典人物。）
我很关注微软内部团队在软件开发的过程中，他们是如何去处理技术与人际交流之间的关系的；这类栏目总是我的最爱。看到大量的公司内幕被写了出来，我常常会感到吃惊——我不知道还有多少不为人知的故事没有说出来。
大型项目中的软件工程管理者面临着3个基本的问题。第一个是，程序代码太容易被改变了。跟机械或土木工程不一样，它们在现有系统上做一次改变总是要付出实实在在地拆毁某些东西的代价，而软件程序的改变只需要敲敲键盘就行了。如果对一座桥的桥墩或一架飞机的引擎做一个错误的结构性更改，由此产生的后果，即使不是专家也很容易就能看出来。然而，如果在一个现有程序上做修改，对于其风险，即使经验丰富的软件开发者进行了充分的讨论，其结果常常还是错的。
建筑隐喻实际上可以很好地适用于软件。基于程序代码在系统中所处的层次，它们可以被比作为“基础、框架和装饰”。“基础”代码具有高度的杠杆作用，它们的改动常常会引起严重的连锁反应。“装饰”代码比较容易改动，而且也需要被经常改动。问题是，累积了几年的改变之后，复杂的程序就跟历经过几次装修的房子差不多了——电源插座躲到了橱柜的后面，浴室风扇的出风口通向了厨房。再做任何改变的话，其副作用或最终的代价都是很难预知的。
第二个基本问题是，软件行业还太年轻，关于可复用组件的正确标准实际上还没有被发现或建立起来。大头钉是否应该放在离开16英寸的地方，以同时适应水平或垂直的4x8英尺的干垒墙或夹板？我们不仅在这类问题上还没有取得一致意见，甚至我们还没有决定，是否像大头钉、干垒墙和夹板这样的组合更可取，还是我们要去发明像泥浆、稻草、石头、钢铁和碳化纤维这样的组合。
最后一个问题实际上是第二个问题的另一种表现形式。每个项目中重复发明的软件组件，它们也被重复命名了。软件行业里对现有的概念发明新的名字是很常见的，即使用的名字相同，这些名字也以新的方式被重用。行业里有一个心照不宣的秘密：关于软件开发最佳方法的相当多的讨论，参与的实际上都是同一群人，只不过他们用了不同的名字，他们甚至对彼此正在说的东西都没有一个哪怕是很朦胧的想法。
表面上看来，这些都是很简单的问题。建立一些标准，然后强制实行它们。在快速进步的大容量、高价值、低成本的软件世界里，这可是一个让你的业务落败的捷径。实际情况是，软件最大的工程障碍，同时也是它最大的优势。无处不在的软件（运行在低成本的个人电脑和互联网上），已经使得以惊人的步伐去创新成为可能。
随着微软的成长，公司已经不再能在最佳工程实践的研究方面大量地投入，然后经过深思熟虑，挑选出其中具有最好质量的方法。个人电脑和Windows的成功，已经把公司从按传统方式做些小项目的形态转变出来，转而要去谱写开发有史以来最庞大、最复杂软件的新篇章。
为了能够创建出平衡风险与效率、创新的最佳系统，微软面临着持续不断的挣扎。考虑到我们的一些项目有着极度的复杂性，这些努力甚至可以称得上“英勇无畏”。在过去的一段时间以来，我们已经设置了专员、建立了专门的组织，他们都一心一意、致力于这个行业里最困难的事情——“软件发布”。我们已经学会了很多的民间传说、风俗、文化、工具、过程和大拇指规则（译者注：Rules of Thumb，是指没有经过科学实验、直接从实践中总结出来的方法和规则；它们在很多情况下都有用，但并不是放之四海皆准），那些都有助于我们建造和发布这个世界上最复杂的软件。但与此同时，每天都处理这些问题难免也让人心惊胆战、士气受挫。Eric的栏目正是大家跟我们一起分享和学习的极好方式。
Mike Zintel，微软公司Windows Live内核开发部门总监
2007年8月
第3章
根除低下的效率
本章内容：
2001年7月1日：“迟到的规范书：生活现实或先天不足”
2002年6月1日：“闲置人手”
2004年6月1日：“我们开会的时候”
2006年7月1日：“停止写规范书，跟功能小组呆在一起”
2007年2月1日：“糟糕的规范书：该指责谁？”
正如我在第2章的“精益：比帕斯雀牛肉还好”栏目中所说的那样，浪费和灾难在工作中常常相依相伴。关于这一点，没什么比组织的沟通（本章的几个栏目都会涉及这个话题），以及项目之间的自由时间的合理使用来得更为明显。这些领域影响的不仅仅是个人，而且是整个团队。因此，它们的影响也是成倍于其他领域的影响。
在我的恐怖字典中，规格说明文档（规范书）和会议始终占据着特殊的位置。我想可能是因为工程师花了太多的时间在会议上，而且常常还是在讨论规范书的原因吧。尽管我很希望这两样东西在我们熟知的世界中消失，但它们之所以存在必定还是有它们的用途的。我们能做的，是要关注那个真实的用途，而把其他多余的东西统统抛弃。
在这一章中，I。 M。 Wright介绍了一些策略去消除常见的低下效率。第一个栏目谈到了最后时刻的规范书变更。第二个栏目解决了项目之间的空闲时间的合理使用问题。第三个栏目聚焦在如何尽力消除会议的弊病。最后两个栏目竭力想彻底抛弃规范书，如果那不可行，至少也要让规范书短小精悍一点。
其他栏目在组织沟通方面会有更加充分的论述——从跨团队协商到跟非技术人员交流的方方面面。那些栏目还介绍了“个人”可以采取的改进措施。但本章这些栏目重在讲述“组织”能够采取的措施，以便最好地使用它们有限的时间。
——Eric
对于每次变更，搅动，搅动，搅动
2001年7月1日：“迟到的规范书：生活现实或先天不足”
你已经达到了“编码完成”（Code plete）的阶段，你正在全力修复Bug，这时候看看你的邮箱里收到了什么？啊，太有趣了，居然是一份新的规范书！把它一脚揣开，如何？请稍等，这可是以前的规范书不小心遗漏掉的一个关键功能，或者像我们常说的那样，“代码本身就是规范书。”
作者注：编码完成（Code plete），是指开发者认为对于某个功能所有必要的实现代码都已经签入到源代码控制系统的一种状态。通常这只是一个主观判断，而更好的做法实际上应该基于质量标准来度量（那时候经常称作为“Feature plete”，即“功能完成”）。
可以想象，测试人员被激怒了。因为他们没有及时拿到规范书，并且他们觉得“被排除在了项目开发周期之外”。实在太晚了！代码的表现跟规范书不符，但他们还没测试过。开发人员也感到焦躁不安，因为他们原以为功能已经完成了，但实际上测试人员却�