按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
微软怎么能包容所有这些多样性和产品的区域自治、还能为朝着一个共同的目标有效地工作呢？这就要靠产品线公共的项目协调了。举例来说，产品线的价值主张为所有的产品单元和他们的功能团队设置并统一关键应用范例、质量尺度和框架体系。
为了促进跨部门和产品线的协调和共享，特别是为提高质量和效率，微软还设立了一个组织叫Microsoft Trustworthy puting and Excellence。它是我的上级组织。具体来说，我的工作职责是，要让微软全球超过1万名的开发者在构建令人兴奋的、高质量的用户体验时，能够做得更加开心、更富有效力。不用说，这是一项长期的工作。
献给当初对我说“为什么不由你来写？”的人：Bill Bowlus（3）
我的团队每月将开发部门的领导层聚集在一起，谈论问题并指导我们的工作。我们研究公司范围内乃至整个行业内的工程方法，以期找到新的机会和领域去提高。我们通过网络共享工具、最佳实务，以及实施职业生涯指导。我们举办各种活动和奖项评比，与各种团队商讨，为开发中的各个级别、各种角色提供技术培训。非常棒的工作！另外，我每月还在写着观点栏。
示范工具和文档
本书提到的示范工具和文档，作为本书的附属内容，都可以通过如下地址下载到：
在线资料列表
工具 栏目 章节
Sprint backlog： ；
敏捷子弹 2
Product backlog： ；
敏捷子弹 2
Spec template： Spec 糟糕的规范书：该指责谁？ 3
Spec checklist： Spec 糟糕的规范书：该指责谁？ 3
Pugh Concept Selection：；
复审一下这个 5
Inspection Worksheet： ； 复审一下这个 5
Interview Role Playing； a how…to guide：
面试流程之外 9
本书的支持
为了保证本书及其附属内容的准确无误，我们尽了最大的努力。本书所有的修正和改动都会搜集起来并放到微软的知识库中去。微软出版社通过如下站点对本书及其附属内容提供支持：。
问题和意见
如果你对本书及其附属内容有任何意见、建议或问题，并且通过访问上述站点仍然无法解决，请给微软出版社发送电子邮件： mspinput@，或者按照如下方式邮寄：
Microsoft Press
Attn： I。 M。 Wright’s “Hard Code” Editor
One Microsoft Way
Redmond； WA 98052…6399
请注意，上面的地址对微软的软件产品不提供支持。
书包 网 。 想看书来
读者对I。 M。 Wright’s “Hard Code”栏目的喝彩
任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话，最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向，但它对于需要不断创新才能繁荣的技术公司来说，却是个致命杀手。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个基本的问题。第一个是，程序代码太容易被改变了。跟机械或土木工程不一样，它们在现有系统上做一次改变总是要付出实实在在地拆毁某些东西的代价，而软件程序的改变只需要敲敲键盘就行了。如果对一座桥的桥墩或一架飞机的引擎做一个错误的结构性更改，由此产生的后果，即使不是专家也很容易就能看出来。然而，如果在一个现有程序上做修改，对于其风险，即使经验丰富的软件开发者进行了充分的讨论，其结果常常还是错的。
建筑隐喻实际上可以很好地适用于软件。基于程序代码在系统中所处的层次，它们可以被比作为“基础、框架和装饰”。“基础”代码具有高度的杠杆作用，它们的改动常常会引起严重的连锁反应。“装饰”代码比较容易改动，而且也需要被经常改动。问题是，累积了几年的改变之后，复杂的程序就跟历经过几次装修的房子差不多了——电源插座躲到了橱柜的后面，浴室风扇的出风口通向了厨房。再做任何改变的话，其副作用或最终的代价都是很难预知的。
第二个基本问题是，软件行业还太年轻，关于可复用组件的正确标准实际上还没有被发现或建立起来。大�