代码之殇

出版时间：2013-4  出版社：机械工业出版社  作者：Eric Brechner  译者：林锋  
Tag标签：无  

前言

【前言】 献给当初对我说“为什么不由你来写”的人Bill Bowlus。献给当初对我说“好的，我帮你编辑一下”的人我的妻子。你手上拿着的是一本关于最佳实务的书，它会比较乏味，但也许会有点吸引力，你能从中得到知识，读后甚至对你产生些许影响，但读起来肯定是干巴巴而无趣的。为什么这么说呢？最佳实务的书是乏味的，因为这个“最佳”是跟具体的项目、具体的人、他们的目标以及偏好紧密相关的。一个实务是不是“最佳”，大家可能看法不一。作者必须把实务列举出来让读者自己选，并分析在什么时候、什么原因选择哪个方案作为“最佳”。但是这种做法是现实的、是非分明的，它会让人感到乏味和厌烦。通过多个案例的研究使原本模棱两可的概念泾渭分明，从而会使文字有味一些，但作者仍必须把选择的机会留给读者，否则作者就会显得傲慢、教条并且死板。然而，人们喜欢看到傲慢、教条、死板的学者之间的针锋相对。大家喜欢引用学者们的观点片段，与朋友和同事一起讨论。为什么不将对这些最佳实务的争论作为观点栏目来发表呢？唯一的条件就是只要有人愿意将自己扮演成一个思想保守的傻瓜。本书的由来2001年4月，在历经了Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics及Boeing等公司总共16年的职业程序员生涯，并在微软做了6年的程序员和经理之后，我转而加入了微软内部的一个以在公司范围内传播最佳实务为职责的团队。当时这个组正在运作发行一个名叫《Interface》的月刊网络杂志的项目。它很有意义且富有知识性，但同样也是干巴巴而无趣的。我那时建议增加一个观点栏目。我的上司Bill Bowlus建议由我来写。我拒绝了。作为一个半大孩子，我努力使自己成为一个协调员，撮合多方产生成果，而成为一个爱唠叨的实务学者会毁掉我的名誉和效力。因此，我当时的想法是说服一个大家公认的偏执的工程师来写，他可能是我在微软6年工作经历中接触过的一位特别固执的开发经理。但Bill指出，我有22年的开发经验，4年的开发管理经验，写作技巧也还行，而且有足够的态度来做这件事，我只需要放下自身的心理包袱。另外，其他的开发经理都忙于常规的工作，不可能每个月来为我们写一些个人观点。最后Bill和我想出了一个用笔名撰稿的点子，于是“代码之殇”（Hard Code）栏目诞生了。从2001年6月开始，我使用“IMWright，微软逍遥的开发经理”（IMWright,Microsoft development manager at large）这个署名为微软的开发者和他们的经理写了91个“代码之殇”观点栏目。这些栏目的标签行都打上了“绝对诚实，直言不讳”（Brutally honest，no pulled punches）的标语。每个月，有成千上万的微软工程师和经理会阅读这些栏目。前16个栏目在内部网络杂志《Interface》上发表了。这些栏目都是编辑（Mark Ashley和Liza White）给我分配的。我和《Interface》的美工Todd Timmcke还一起制作了作者的很多搞怪照片。当网络杂志停刊的时候，我才得以有喘息的机会，但也停止了写作。14个月之后，在我们组的编辑Amy Hamilton（Blair）、Dia Reeves、Linda Caputo、Shannon Evans和Marc Wilson的帮助下，我又开始在内部站点上发表我的栏目。2006年11月，我将所有的栏目转移到一个内部的SharePoint博客上。2007年春天，正当我打算度过几年前奖励给我的假期的时候，我现在的经理Cedric Coco给了我在休假期间将《代码之殇》出版成书的授权。而微软出版社的Ben Ryan也同意了。同年，本书第1版出版。除了我已经提及的人，我还想感谢《Interface》的其他成员（Susan Fario、Bruce Fenske、Ann Hoegemeier、John Spilker和John Swenson），其他帮助本书出版的人（Suzanne Sowinska、Alex Blanton、Scott Berkun、Devon Musgrave和Valerie Wolley），支持我的管理层（Cedric Coco、Scott Charney和John Devaan），曾审核过我的栏目并提出过很多主题的团队成员（William Adams、Alan Auerbach、Adam Barr、Eric Bush、Scott Cheney、Jennifer Hamilton、Corey Ladas、David Norris、Bernie Thompson、James Waletzky、Don Willits和Mitch Wyle），以及写下第1版“前言”的Mike Zintel。关于第2版，我想重点提下本书的审核人员及长期读者（Adam Barr、Bill Hanlon、Bulent Elmaci, Clemens Szyperski、Curt Carpenter、David Anson、David Berg、David Norris、Eric Bush、Irada Sadykhova、James Waletzky、JDMeier、Jan Nelson、Jennifer Hamilton、Josh Lindquist、Kent Sullivan、Matt Ruhlen、Michael Hunter、Mitchell Wyle、Philip Su、Rahim Sidi、Robert Deupree（Jr）、William Adams和William Lees）；还有James Waletzky，他在我休假的时候为我的读者写了两篇专栏文章；Adam Barr和Robert Deupree（Jr），他们发动我为专栏记录了一段播客并发布出去；Devon Musgrave和Valerie Woolley，是他们让第2版顺利出版；我的上司（Peter Loforte和Curt Steeb）对我的努力给予了莫大的支持；Mitch为我写了第2版的“序”；以及我的妻子Karen，当我让编辑加入Xboxcom工作时，她接手了我的专栏编辑工作。最后，我要感谢我才华出众的中学英语老师（Alan Shapiro），以及那些慷慨给予我反馈的读者们。尤其是，我还要感谢妻子Karen和儿子Alex和Peter，他们让我做任何事情都充满信心。本书的读者对象组成本书的91个观点栏目最初是写给微软的开发者及其经理看的，尽管它们也是我过去在软件行业6个不同的公司、32年的工作经验中提炼出来的。编辑和我一起修改了语言表达，注解了那些微软内部的特殊用语，使得本书适合于所有软件工程师和工程经理阅读。我在这些栏目中表达的观点是我个人的，不代表我现在和以前任职过的任何一家公司，包括微软。我在栏目中的注解以及本简介中的言论同样都是我个人的，与任何公司无关。本书的结构根据主题的不同，我把所有栏目分成10章。前6章剖析了软件开发流程，接下来3章重点讨论人的问题，最后1章批判软件业务运转方式。解决这些问题的工具、技巧和建议遍布全书。本书的最后还附有术语表方便大家参考。每一章的各个栏目均按照当初在微软内部发表的时间顺序排列。每章开头我都给出了一个简短的介绍，随后就是当初我以“IMWright”笔名发表的栏目内容。当将其编辑成书的时候，我还适时在栏目中加上了“作者注”，以解释微软的术语，提供更新内容或者额外的背景知识。编辑和我尽力保持原有栏目的完整性。我们做的工作仅仅是纠正语法和内部引用。称得上改动的其实只有一处：就是将原来一个叫“你被解雇了”的栏目标题改成了“最难做的工作——绩效不佳者”，因为以前那个标题太容易让人误解了。每个栏目都以一段激昂的演说开场，然后是问题根源的分析，最后以我对这个问题如何改善的建议结束。我酷爱文字游戏、头韵和通俗文化，因此栏目中充斥着这些东西。特别是大部分栏目的标题和副标题都直接取材于歌词、电影对白和谚语。是的，我自娱自乐，但撰写这些栏目确实给我带来了些许乐趣，同时也使我得到了痛快宣泄。希望你也会喜欢！微软的组织结构因为这些栏目最初是写给微软的内部员工看的，因此有必要简要了解一下微软以及我在工作中扮演的角色，这有助于更好地理解这些文字。目前，微软的产品开发分成七大业务部门，各个部门相应负责我们的主营产品——Windows、Office、Windows Phone、Interactive Entertainment（包括Xbox）、服务器软件及工具（包括Windows Server和Visual Studio）、Dynamics以及在线服务软件（包括Bing与MSN）。每个部门大约包含20个独立的产品单元或管理小组。通常情况下，这些产品单元共享源代码控制、创建、安装、工作条目跟踪和项目协调（包括价值主张、里程碑安排、发布管理和持续性工程）。除了这些相应的服务之外，产品单元或小组还有高度的自主权，可以对产品、流程和人员做出自己的安排。持续性工程（sustained engineering）指直接发布软件产品而不像通常先出测试版改进后再出正式版，产品发布后根据用户使用情况再改进，然后再次发布新版本，如此反复。——译者注一个典型的管理小组通常由三个专职经理组成：项目组项目经理（Group Program Manager ，GPM）、开发经理（Development Manager）和测试经理（Test Manager）。一个产品开发单元通过这三个专职经理向产品单元经理（Product Unit Manager，PUM）负责。如果没有产品单元经理，那么他们分别向他们的上司并最终向部门主管汇报。其他工程领域，比如用户体验、内容发布（比如在线帮助）、创建和实施，这些可能单独对某个产品单元负责，也可能在整个部门中共享。每个工程领域抽出一个或多个代表组成一个虚拟团队，由该团队向这三个专职经理负责并为一个单独的功能模块工作，该团队称为功能团队（feature team）。有些功能团队选择敏捷方法，有些喜欢精益模型，有些采用传统的软件工程模型，有些则根据实际情况综合采用上述多种方法。微软如何整合所有这些多样化又独立自治的团队并使其朝向一个共同的目标有效地工作呢？这就是部门公共项目协调组所要扮演的角色了。例如，部门的价值主张是为所有的专职管理小组和他们的功能团队设置统一的关键示例、质量尺度和准则。示范工具和文档在线资料列表工具栏目 章节SprintBacklogExamplexls；SprintBacklogTemplatexlt敏捷子弹2ProductBacklogExamplexls；ProductBacklogTemplatexlt敏捷子弹2Spectemplatedoc；Specchecklistdoc糟糕的规范书：该指责谁？3InspectionWorksheetExamplexls；InspectionWorksheetTemplatexlt；Pugh Concept Selection Examplexls复审一下这个5InterviewRolePlayingdoc面试流程之外9系统要求本书提供的工具都是微软的Office Excel 2003和Office Word 2003格式的。只要你的电脑上安装有Word Viewer和Excel Viewer，就能使用这些文件。

内容概要

《华章程序员书库:代码之殇(原书第2版)》是《代码大全》的姊妹篇，资深软件开发专家30余年工作经验结晶，被誉为“软件行业的财富”，微软公司软件工程师必读之书。它从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题（大多数问题可能会给公司或软件项目带来毁灭性灾难），并给出了问题的解决方案和最佳实践，值得所有软件工程师和项目管理者研读。
《华章程序员书库:代码之殇(原书第2版)》将这90余个问题分为10章：第1章讨论如何通过管理风险、范围和沟通来保障项目按时完成；第2章介绍消除经验主义的大量过程改进的方法与技巧；第3章讨论消除低效率的策略；第4章主要讨论开发者与其他工种之间的关系；第5章重点阐释软件质量问题；第6章解析软件设计的基本原理和错综复杂的本性；第7章探讨如何规划职业生涯；第8章分析工作与生活中存在的缺点的原因与纠正措施；第9章讨论如何进行有效管理；第10章分析如何成功应对一个软件业务所面临的挑战。

作者简介

作者：（美国）Eric Brechner 译者：林锋Eric Brechner，微软公司“卓越开发”部门总监，在软件行业拥有超过30年的经验积累。他曾担任过开发部门负责人、开发部经理、开发部总裁等工作，曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司从事职业程序员生涯，后加入微软公司。他从2001年开始为微软公司员工写“Hard Code”栏目。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。

书籍目录

本书赞誉译者序序前言第1版前言第1章项目管理失当12001年6月1日：“开发时间表、飞猪和其他幻想”22001年10月1日：“竭尽所能，再论开发时间表”42002年5月1日：“我们还开心吗？分诊的乐趣”72004年12月1日：“向死亡进军”112005年10月1日：“揭露真相”142008年9月1日：“我得估算一下”182009年5月1日：“一切从产品开始”212009年9月1日：“按计划行事”252010年5月1日：“敏捷的团队合作”28第2章过程改进，没有灵丹妙药312002年9月2日：“六西格玛？饶了我吧！”322004年10月1日：“精益：比五香熏牛肉还好”332005年4月1日：“客户不满”392006年3月1日：“敏捷子弹”442007年10月1日：“你怎么度量你自己？”502010年10月1日：“有我呢。”542010年11月1日：“我在缠着你吗？Bug报告。”582010年12月1日：“生产第一”622011年2月1日：“周期长度——生产力的老生常谈”65第3章根除低下的效率702001年7月1日：“迟到的规范书：生活现实或先天不足”712002年6月1日：“闲置人手”732004年6月1日：“我们开会的时候”772006年7月1日：“停止写规范书，跟功能小组呆在一起”792007年2月1日：“糟糕的规范书：该指责谁？”822008年2月1日：“路漫漫，其修远——分布式开发”852008年12月1日：“伪优化”892009年4月1日：“世界，尽在掌握”912011年4月1日：“你必须做个决定”94第4章跨越工种982002年4月1日：“现代临时夫妇？开发与测试”992004年7月1日：“感觉性急——测试者的角色”1012005年5月1日：“模糊逻辑——君子之道”1052005年11月1日：“废除工种——有什么理由搞专业化？”1092009年1月1日：“持续工程的鬼话”1112011年5月1日：“测试不该不受尊重”114第5章软件质量不是梦1182002年3月1日：“你对你的安全放心吗”1192002年11月1日：“牛肉在哪里？为什么我们要质量”1212004年4月1日：“软件发展之路——从手工艺到工程”1272005年7月1日：“复审一下这个——审查”1312006年10月1日：“对质量的大胆预测”1362008年5月1日：“碰撞测试：恢复”1382008年10月1日：“盯紧标称”142第6章有时间就做软件设计1462001年9月1日：“错误处理的灾难”1472002年2月1日：“太多的厨师弄馊了一锅好汤——唯一权威”1492004年5月1日：“通过设计解决”1512006年2月1日：“质量的另一面——设计师和架构师”1552006年8月1日：“美妙隔离——更好的设计”1582007年11月1日：“软件性能：你在等什么？”1612008年4月1日：“为您效劳”1642008年8月1日：“我的试验成功了！（原型设计）”1672009年2月1日：“绿野中长满蛆了”170第7章职业生涯历险记1742001年12月1日：“当熟练就是目标”1752002年10月1日：“人生是不公平的——考核曲线”1772006年11月1日：“职业阶段上的角色”1802007年5月1日：“与世界相连”1832007年11月1日：“找个好工作——发现新角色”1872007年12月1日：“要么带头做事，要么唯命是从，要么赶紧离开”1902008年7月1日：“猩猩套装中的机遇”1942010年3月1日：“我是很负责的”1962010年4月1日：“新来的伙计”2002010年６月１日：“升级”2032010年９月１日：“辉煌时代”2072011年１月１日：“个体领导者”210第8章自我完善2132002年12月1日：“合作还是分道扬镳——协商”2142005年2月1日：“最好学会平衡生活”2162005年6月1日：“有的是时间”2192005年8月1日：“寓利于乐，控制你的上司”2242006年4月1日：“你在跟我讲吗？沟通的基础”2282007年3月1日：“不是公开与诚实那么简单”2312009年3月1日：“我听着呢”2342009年7月1日：“幻灯片”2362009年12月1日：“不要悲观”2402010年8月1日：“我捅娄子了”2432011年3月1日：“你也不赖”245第9章成为管理者，而不是邪恶的化身2482003年2月1日：“不仅仅是数字——生产力”2492004年9月1日：“面试流程之外”2512004年11月1日：“最难做的工作——绩效不佳者”2552005年9月1日：“随波逐流——人才的保持和流动”2582005年12月1日：“管理我在行”2622006年5月1日：“比较的恶果——病态团队”2662008年3月1日：“必须改变：掌控改变”2692009年6月1日：“奖赏，很难”2722009年10月1日：“招人总是后悔”2752009年11月1日：“管理馊了”2782010年1月1日：“一对一与多对多”2802010年7月1日：“文化冲击”284第10章微软，你会喜欢它的2872001年11月1日：“我是怎样懂得不再焦虑并爱上重组的”2882005年3月1日：“你的产品单元经理是个游民吗？”2902006年9月1日：“有幸成为Windows的主宰者”2932006年12月1日：“Google：严重的威胁还是糟糕的拼写？”2982007年4月1日：“中年危机”3012008年11月1日：“虚无主义及其他的创新毒药”3052010年2月1日：“我们是功能型的吗？”308术语表312

编辑推荐

《华章程序员书库:代码之殇(原书第2版)》编辑推荐：《代码大全》姊妹篇，资深软件开发专家30余年工作经验结晶，微软公司软件工程师必读之书，被誉为“软件行业的财富”。从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题并给出了解决方案，值得所有软件工程师研读。

名人推荐

任何大型组织都会有成为自身文化牺牲品的危险。关于业务模式及行为准则的神话想当然地成为金科玉律。任何组织都会存在这种倾向，但对于需要不断创新才能兴旺的技术公司来说，这却是致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀，深度剖析了存在于组织中的这种谬误。他毫不客气地亮出了利剑——往往一针见血。尽管有一些隐语和例子对于微软内部的员工更具吸引力，但他的智慧和至理名言，大都可以成为整个软件行业的财富。——Clemens Szyperski，首席架构师I M Wright写的关于开发时间表的文章真的太棒了！它在我所属项目组参与的基础项目上同样适用。——Ian Puttergill，项目经理你不打算遇到死亡威胁这样的事，是吧？——Tracey Meltzer，高级测试主管这很可笑——很坦率地说，这类十足的谬论很危险。——Chad Dellinger，企业架构师Eric是我个人崇拜的英雄——很大程度上是因为他长期以来一直代表着开发社区的一种声音。——Chad Dellinger，企业架构师软件工程师很容易就会迷失在代码中，更糟糕的是，甚至会迷失在过程中。此时迫切需要Eric在本书中提出的实用建议。——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，商务项目经理

用户评论 (总计5条)

•   1.如果能早两年翻译出版，能避免自己工作中很多错误的尝试。2.都说中国在IT领域和美国只有50年的差距，差距在哪里？可以在这本书中找到大部分的答案。3.这本书的翻译和排版质量是有足够诚意的。
•   虽然网上本书的电子书已经泛滥,但是买一本时常翻翻.
•   书很不错，很适合英文不好的同学学习，毕竟是微软的大牛写的，很浅显易懂，对自己代码提升很有作用！
•   书还没有认真看，不过应该适合大牛。
•   还以为是代码方面的，结果都是项目管理方面的，就是bbs内容整理出来的，感觉比较散