代码之道(Microsoft核心技术丛书)
点此进入淘宝搜索页搜索分類: 图书,计算机与互联网,软件工程及软件方法学,综合,
品牌: Eric Brechner
基本信息·出版社：机械工业出版社
·页码：192 页
·出版日期：2009年
·ISBN：7111251679/9787111251675
·条形码：9787111251675
·包装版本：1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：Microsoft核心技术丛书
产品信息有问题吗？请帮我们更新产品信息。
内容简介《代码之道》揭示关于编码、测试和项目管理的残酷现实：一位微软的内部人士如实地向你述说。I.M.Wright的“Hard Code”故意煽情，几年来在微软内部成千上万的工程师之间引起了激烈的争论。现在（也顾不上“家丑不外扬”了），我们把他的观点向所有人公开。《代码之道》收录了49个栏目。Eric Brechner重拳出击，对最令他苦恼的问题提出了最佳实践的解决方案，另外还加上了他坦诚的注解。他解剖了开发过程，审查了棘手的团队问题，批判了软件业务的运转方式：自始至终充斥着机灵的幽默和讥讽的风趣。他的想法并不总是很受欢迎（他也不关心那个），但它们的的确确激发起了人们的讨论和想象，推动着软件相关的活动走向卓越。
作者简介Eric Brechner微软公司“卓越开发”部门的总监，在软件行业已经积累了20多年的经验。他从2001年开始写“HardCode”栏目，作为一种资源提供给微软的员工。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今。这些观点走出了微软，走向了整个开发社区。
编辑推荐《代码之道》是《代码大全》姊妹篇！
微软公司内部所有工程师的必读之书！
——Peter Isensee，微软公司开发经验
了解未经掩饰的真相：
怎样提高软件的质量和价值，从设计到安全；怎样切合实际地管理项目的时间表、风险和规范书，怎样为常见的低效率开发瘦身，怎样应用过程改进方法、避免固执盲从，怎样驱动一个成功的、令你自己满意的职业生涯，怎样不变成暴君、发展并管理一个欣欣向荣的团队！
目录
序
前言
第1章 项目的不当管理
2001年6月1日：“开发时间表、飞猪和其他幻想”
里氏震级估计
风险管理
客户赢了
2001年10月1日：“竭尽所能：再论开发时间表”
软件工程绝对是含糊的
相信一半你看到的，别信你听到的
激励：不能光靠比萨和啤酒
在日期上沉沦
2002年5月1日：“我们还开心吗？分诊的乐趣”
战争是地狱
这不是个人的事情
分诊的5条黄金法则
魔鬼藏在细节里面
很难进行下去，不是吗？
谨小慎微
2004年12月1日：“向死亡进军”
暗箭伤人
对失败的连祷
转折点
很少有人走过的路
2005年10月1日：“揭露真相”
遭受错觉之苦
拿把叉子扎进我的身体
给我个坦率的回答
给猪抹口红
看看所有这些传言
我想知道真相
第2章 过程改进，没有魔法
2002年9月2日：“六西格玛？饶了我吧！”
啊！这是什么巫术？！
召集骑兵
在混沌之外建立秩序
2004年10月1日：“精益：比帕斯雀牛肉还好”
任何事情都要适中
俭则不匮
过量生产
走向深处
运输
多余动作
等待
过程不当
库存
缺陷
合作共生
2005年4月1日：“客户不满”
但愿不知道
太过分，太迟了
敏捷错觉
回退你的步伐
更多用武之地
使用正确的工具
布基胶带和打包钢丝
客户满意
2006年3月1日：“敏捷子弹”
真理的敌人
拨乱反正
准备改变了吗？
让他说话
你完善我
有点极端
准备玩橄榄球！
最后你要知道的
第3章 根除低下的效率
2001年7月1日：“迟到的规范书：生活现实或先天不足”
对于每次变更，搅动，搅动，搅动
走廊会议
委员会议
规范书变更请求
预防是最好的治疗
2002年6月1日：“闲置人手”
宝宝做了件极坏的事情
告诉我该做什么
俭则不匮
2004年6月1日：“我们开会的时候”
为什么我们会在这里？
我们正在试图做什么？
为什么他们会在这里？
为什么我现在才听到这个？
接下去要做什么？
2006年7月1日：“停止写规范书，跟功能小组呆在一起”
你失去理智了吗？
在那里进退两难
特殊要求
我不记得了
坚持做一件事情
你准备好了吗？
2007年2月1日：“糟糕的规范书：该指责谁？”
树立靶子
沟通分解
保持简单容易
变得稳健
获取反馈
集成质量检查
差别在哪？
第4章 跨越工种
2002年4月1日：“现代临时夫妇？开发与测试”
我怎么爱你？让我来数一下有多少种方式
必要的邪恶或珍贵的伙伴？
每个人都要知道自己的弱点
你完善我
2004年7月1日：“感觉性急——测试者的角色”
高级保护
改变一下对你有好处
黎明时分
充分利用数据
非常酷——我保证你
2005年5月1日：“模糊逻辑——君子之道”
包罗万象
他们跟我们不一样
通过安检
着手去改变
更好地在一起
2005年11月1日：“废除工种——有什么理由搞专业化？”
历经未来的日子
考察它的极限
足球是门科学
两者之间的距离
你深陷其中
第5章 软件质量不是梦
2002年3月1日：“你对你的安全放心吗？”
小心晃动的钟摆
做正确的事
安全受制于最薄弱环节
领导、跟随或者离开
2002年11月1日：“牛肉在哪里？为什么我们要质量”
情况变了
足够好还不行
艰难的选择
终于有足够的时间了
再检查一遍
医生，治好你自己的病
步步为营
太多疑问？
2004年4月1日：“软件发展之路——从手工艺到工程”
工艺制桌子，工程造汽车
其实你知道
真实面对自己
数字的含义
各人有各人的习性
大处着想，小处着手
从优秀到卓越
2005年7月1日：“复审一下这个——审查”
糟糕的混合
完美风暴
谁来负责？
你有什么想法？
正是这个形式
孩子，准备好了吗？
再检查一遍
神奇的汇总会议
审查的诀窍
走上正道
2006年10月1日：“对质量的大胆预测”
谜？我不这么认为
邪恶双煞
嫌疑惯犯
你会喜欢它的
停止卖弄愚蠢
质量就是没有意外
第6章 有时间就做软件设计
2001年9月1日：“错误处理的灾难”
恐怖，恐怖
使用异常
别丢弃，用上它！
2002年2月1日：“厨师太多烧不好菜——惟一权威”
一幅图片抵得上一千个字
有人确切知道现在几点了吗？
只能有一个
万物皆有联系
2004年5月1日：“通过设计解决”
如何才算足够好？
设计完成
细节，细节
让我看看你是由什么组成的
当心缺口
成功处方
2006年2月1日：“质量的另一面——设计师和架构师”
你必须比那做得更好
改变一下对你有好处
他这么做不对
正确的做法
下一次，试试雕塑
关键要有正确的工具
打破这些壁垒
2006年8月1日：“美妙隔离——更好的设计”
分解难做
正确的做法
团队不需要“我”
循序渐进
猫狗不分家
第7章 职业生涯历险
2001年12月1日：“当熟练就是目标”
每个人都要知道自己的弱点
享其成但不坐等
我希望他们尊重我
我们都牵连其中
2002年10月1日：“生活是不公平的——考核曲线”
我不想再逆来顺受了
知识就是力量
关注业务
前进，让我快乐
伸出手去接触某人
有了柠檬？制作柠檬水
改变你的主意
方向盘后面的人
2006年11月1日：“职业阶段中的角色”
一个人同时扮演很多角色
搞清楚职业阶段
我是有抱负的
资历过高
我是特殊的
只能选一个
你想成为什么？
2007年5月1日：“让你自己与世界相连”
你认识的人
我利用习惯
难道你不好奇？
你得到了我们的感谢
我回头再找你
欢迎来到这个世界
第8章 自我完善
2002年12月1日：“要么听我的，要么走人——协商”
一个你无法拒绝的方式
逐渐长大
我脑子里闪过的阴影和凶兆
不要伤害Messenger
皆大欢喜
2005年2月1日：“最好学会平衡生活”
平衡是关键
光说不练
我甚至不能平衡我的支票簿
平衡好，一切都好
2005年6月1日：“时间够用了”
直接告诉我
免受打扰之苦
找到你的乐园
我们谁也不笨
我们必须共同承担
告诉我必须做什么
他还是个孩子
你应该休息一下
这里秩序井然
坦诚相待
大有可为
2005年8月1日：“有理有节地控制你的上司”
我没辙了
知彼知己
他们能自我适应
把水卖给鱼
势利的眼睛
付诸行动
敢于做梦
2006年4月1日：“你在跟我说话吗？基本沟通”
为我着想一下
告诉我你想要什么
你什么时候想要？
缩小注意力跨度
就这样完了？
2007年3月1日：“不只是开放和诚实”
那不是理由
我会对你诚实
那不容易
他们似乎有个开放政策
无处隐藏
跟我想的不一样
走上正道
第9章 成为管理者，而不是邪恶的化身
2003年2月1日：“不只是数字——生产力”
小心你希望得到的东西
扮演一个角色
卓越开发者的素质
你要做法官
2004年9月1日：“面试流程之外”
抱怨得不到帮助
90%是准备
那就是问题
白板编译器
帮招聘专员准备
再次帮面试官准备
友情提醒
最后的难题
2004年11月1日：“最难做的工作——绩效不佳者”
你期望什么？
知难而进
寻求专业援助
没人想失败
目标是成功
无所求，则无所获
你不会总能如愿
2005年9月1日：“随波逐流——人才的保持和流动”
我只是想环球旅行
不错的水坝？
像河水一样流动
新鲜血液
分享就是关爱
成长空间
我必须要旅行
放任自流
2005年12月1日：“我能够管理”
持续送出的赠品
优秀就够了
草率行事
我想要工作
我不是东西
从优秀到卓越
我服务于人
2006年5月1日：“不恰当的比较——病态团队”
想要挑起战争
这不是竞争
我会给你些提示
团结在一起
第10章 微软，你会喜欢它的
2001年11月1日：“我是怎么学会停止焦虑并爱上重组的”
沿着巴别塔下来
地狱里的生活
很少有人走过的路
容忍问题还是主动去解决？
2005年3月1日：“你的产品单元经理是个游民吗？”
有计划的人
我等不及要去实施了
魔鬼藏在细节里面
道路规则
回到正确的跑道上
2006年9月1日：“有幸成为Windows的主宰者”
你还有别的要求吗？
准备轮船
设置路线
启航
导航
责任
下一代Windows
2006年12月1日：“Google：严重的威胁还是糟糕的拼写？”
他们步伐踉跄，我们手舞足蹈
注定要失败
聪明人需要智能客户端
保持警惕
一马当先
2007年4月1日：“中年危机”
你已经变了
日子照过，只不过要掌握一点窍门
不轻易冒险
我认为他们还不能胜任
不再年轻了
不要惊慌失措
没有人是完美的
术语表
……[看更多目录]
序言长期以来，我一直在阅读Eric Brechner以I. M. Wright为笔名撰写的栏目。当我第一次见到作者本人的时候，我费了好大的劲才让自己相信，我是在跟同一个人说话。Wright先生非常地自以为是，然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好，他看起来更像Clark Kent。（译者注：Clark Kent是“超人”的名字，他具有超强的本领，是一个虚构的超级英雄，美国漫画中的经典人物。）
我很关注微软内部团队在软件开发的过程中，他们是如何去处理技术与人际交流之间的关系的；这类栏目总是我的最爱。看到大量的公司内幕被写了出来，我常常会感到吃惊——我不知道还有多少不为人知的故事没有说出来。
大型项目中的软件工程管理者面临着3个基本的问题。第一个是，程序代码太容易被改变了。跟机械或土木工程不一样，它们在现有系统上做一次改变总是要付出实实在在地拆毁某些东西的代价，而软件程序的改变只需要敲敲键盘就行了。如果对一座桥的桥墩或一架飞机的引擎做一个错误的结构性更改，由此产生的后果，即使不是专家也很容易就能看出来。然而，如果在一个现有程序上做修改，对于其风险，即使经验丰富的软件开发者进行了充分的讨论，其结果常常还是错的。
建筑隐喻实际上可以很好地适用于软件。基于程序代码在系统中所处的层次，它们可以被比作为“基础、框架和装饰”。“基础”代码具有高度的杠杆作用，它们的改动常常会引起严重的连锁反应。“装饰”代码比较容易改动，而且也需要被经常改动。问题是，累积了几年的改变之后，复杂的程序就跟历经过几次装修的房子差不多了——电源插座躲到了橱柜的后面，浴室风扇的出风口通向了厨房。再做任何改变的话，其副作用或最终的代价都是很难预知的。
第二个基本问题是，软件行业还太年轻，关于可复用组件的正确标准实际上还没有被发现或建立起来。大头钉是否应该放在离开16英寸的地方，以同时适应水平或垂直的4x8英尺的干垒墙或夹板？我们不仅在这类问题上还没有取得一致意见，甚至我们还没有决定，是否像大头钉、干垒墙和夹板这样的组合更可取，还是我们要去发明像泥浆、稻草、石头、钢铁和碳化纤维这样的组合。
最后一个问题实际上是第二个问题的另一种表现形式。每个项目中重复发明的软件组件，它们也被重复命名了。软件行业里对现有的概念发明新的名字是很常见的，即使用的名字相同，这些名字也以新的方式被重用。行业里有一个心照不宣的秘密：关于软件开发最佳方法的相当多的讨论，参与的实际上都是同一群人，只不过他们用了不同的名字，他们甚至对彼此正在说的东西都没有一个哪怕是很朦胧的想法。
表面上看来，这些都是很简单的问题。建立一些标准，然后强制实行它们。在快速进步的大容量、高价值、低成本的软件世界里，这可是一个让你的业务落败的捷径。实际情况是，软件最大的工程障碍，同时也是它最大的优势。无处不在的软件（运行在低成本的个人电脑和互联网上），已经使得以惊人的步伐去创新成为可能。
随着微软的成长，公司已经不再能在最佳工程实践的研究方面大量地投入，然后经过深思熟虑，挑选出其中具有最好质量的方法。个人电脑和Windows的成功，已经把公司从按传统方式做些小项目的形态转变出来，转而要去谱写开发有史以来最庞大、最复杂软件的新篇章。
为了能够创建出平衡风险与效率、创新的最佳系统，微软面临着持续不断的挣扎。考虑到我们的一些项目有着极度的复杂性，这些努力甚至可以称得上“英勇无畏”。在过去的一段时间以来，我们已经设置了专员、建立了专门的组织，他们都一心一意、致力于这个行业里最困难的事情——“软件发布”。我们已经学会了很多的民间传说、风俗、文化、工具、过程和大拇指规则（译者注：Rules of Thumb，是指没有经过科学实验、直接从实践中总结出来的方法和规则；它们在很多情况下都有用，但并不是放之四海皆准），那些都有助于我们建造和发布这个世界上最复杂的软件。但与此同时，每天都处理这些问题难免也让人心惊胆战、士气受挫。Eric的栏目正是大家跟我们一起分享和学习的极好方式。
文摘第1章项目的不当管理
本章内容：
2001年6月1日：“开发时间表、飞猪和其他幻想”
2001年10月1日：“竭尽所能：再论开发时间表”
2002年5月1日：“我们还开心吗？分诊的乐趣”
2004年12月1日：“向死亡进军”
2005年10月1日：“揭露真相”
我的第一个栏目是在2001年6月刊的微软内部网络杂志《Interface》上发表的。为了进入I.M.Wright的人物角色，我需要一个真正能让我伤脑筋的主题。而工作的时间安排和进度跟踪再好不过了。
项目管理的伟大神话至今都让我疯狂，它的威力远胜过其他任何主题。这些神话是：
1.人们能够按期交付被要求实现的功能（事实上，项目可以按期交付，但人们按期交付功能的概率不会高于击中曲棍球的概率）。
2.有经验的人估计日期比较准（事实上，他们能够较好地估计工作，但不是日期）
3.人们必须按照项目预定的日期按时交付项目（事实上，因为人们不能按期交付被要求实现的功能，而你若想你的项目能够按期交付的话，你必须进行管理风险、范围和通过沟通来减轻人性的弱点可能给项目带来的负面影响）。
在本章中，I.M.Wright讨论了如何通过管理风险、范围和进行沟通，来保障你的项目能够按时完成。前两个栏目专门讨论开发工作的时间安排，接着讨论善后事宜的管理（我们称之为“Bu9分诊”），最后是一篇对死亡行军的声讨，以及一个关于人们为什么要撒谎的哲学栏目。
不得不提的是：通过我在微软多年的工作经历，以及对我所在组织的观察，我发现，项目管理行为和方法在不同规模和抽象层次的组织中，其表现大不相同。这些层次包括：团队或功能层次（10人左右），项目层次（50～5000人，他们一起致力于某个特定的产品发布），以及产品层次（由高层人员主管的多次产品发布）。敏捷方法在团队这个层次能够很好地发挥作用，组织方法在项目这个层次比较适用，而长远的战略规划方法在产品这个层次功效显著。然而，一个人几乎不可能同时在多个层次上工作。时间长河为每个人将这些经历错开了。当一个人从一个层次转到另一个层次工作的时候，他可能会想，在以前那个层次上有效的方法在其他层次上应该也同样有效。灾难就这么产生了！原因很简单：小型、紧凑的群体跟大型、松散的机构在运转方式上是不同的。因此要因地制宜，选择最适合的方法。
——Eric
2001年6月1日：“开发时间表、飞猪和其他幻想”
一匹马走进酒吧，说道：“我能在两天内完成那个功能。”开发成本计算和时问安排是个玩笑。
……[看更多书摘]
