代码之道[试读]

    任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话,最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向,但它对于需要不断创新才能繁荣的技术公司来说,却是个致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀,深深地切入了组织内部看似无关紧要的东西。他毫不吝啬地打出了重拳——偶尔也会故意玷污自己的名声。尽管有一些隐语和例子对于微软内部的员工更有吸引力,但他的智慧和至理名言,大都可以成为整个软件行业的财富。     ——Clemens Szyperski,首要架构师     “I. M. Wright”写的关于开发时间表的文... 查看全部[ 读者对I. M. Wright’s “Hard Code”栏目的喝彩 ]

    长期以来,我一直在阅读Eric Brechner以I. M. Wright为笔名撰写的栏目。当我第一次见到作者本人的时候,我费了好大的劲才让自己相信,我是在跟同一个人说话。Wright先生非常地自以为是,然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好,他看起来更像Clark Kent。(译者注:Clark Kent是“超人”的名字,他具有超强的本领,是一个虚构的超级英雄,美国漫画中的经典人物。)     我很关注微软内部团队在软件开发的过程中,他们是如何去处理技术与人际交流之间的关系的;这类栏目总是我的最爱。看到大量的公司内幕被写了出来,我常常会感到吃惊——我不知道还有多少不为人... 查看全部[ 序 ]

    献给当初对我说“为什么不由你来写?”的人:Bill Bowlus     你手上拿着的是一本关于最佳实务的书。它会比较乏味。但也许会比较有意义,你能从中得到知识,读后甚至对你产生些许影响,但读起来肯定还是干巴巴而无趣的。为什么这么说呢?     最佳实务的书是乏味的,因为这个“最佳”是跟具体的项目、具体的人、他们的目标以及偏好紧密相关的。一个实务是不是“最佳”,大家可能看法不一。作者必须把实务列举出来让读者自己来选,并分析在什么时候、因为什么原因作出最佳选择。虽然这种做法是现实的、负责任的,但也是令人厌烦的,最终无法取悦读者。为释疑而设计的案例研究会使文字有味一些,但作者仍必须把选择的... 查看全部[ 简介 ]

    本章内容:     2001年7月1日:“迟到的规范书:生活现实或先天不足”     2002年6月1日:“闲置人手”     2004年6月1日:“我们开会的时候”     2006年7月1日:“停止写规范书,跟功能小组呆在一起”     2007年2月1日:“糟糕的规范书:该指责谁?”     正如我在第2章的“精益:比帕斯雀牛肉还好”栏目中所说的那样,浪费和灾难在工作中常常相依相伴。关于这一点,没什么比组织的沟通(本章的几个栏目都会涉及这个话题),以及项目之间的自由时间的合理使用来得更为明显。这些领域影响的不仅仅是个人,而且是整个团队。因此,它们的影响也是成倍于其他领域的影响。 ... 查看全部[ 根除低下的效率 ]

    也许在极端情况下,变更还不止一次。但这的确有可能发生。即使变更没有那么晚,规范书常常也是不完整的,或者在尚未被开发人员及时复审和检查之前就匆忙交付开发了。     结果怎么样呢?搅动代码,一次又一次地更改以前的实现。开发人员开始编码的时间太早了!规范书本身就有问题,因此代码自然也有问题。当有人指出这些问题的时候,特别会议召开了,但有人被遗漏、缺席了这个会议,代码返工重写之后,那个被遗漏的人发现了其他地方的错误,于是需要召开更多的特别会议,就这样周而复始、永无宁日。     有什么办法可以解决这个问题呢?有些人可能会说:“项目经理是人渣,应该缠着他,直到他把工作做好。”这听起来有点残酷,... 查看全部[ 对于每次变更,搅动,搅动,搅动 ]

    我最喜欢的方法是“规范书变更请求”(SCR,Spec Change Request),它还有一个扭曲的名字叫“设计变更请求”(DCR,Design Change Request)。这种方法是委员会议和走廊会议的组合,同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容,你的这个想法可能是你自己想出来的,也可能源于一次走廊对话,也可能受到了一次主管会议的启发。     不管你是项目经理、开发、测试或实施人员,你都可以把你的想法写到e-mai中去,并且e-mai的标题定为“SCR: <受影响的规范书> - <变更的简短描述>”。在e-mai结尾的... 查看全部[ 规范书变更请求 ]

    你的开发团队两周前达到了“零Bug反弹”(ZBB,Zero Bug Bounce), 你突然意识到,你又迎来了一个“工作淡季”。任何从事零售软件产品开发、并且碰到过零Bug反弹的开发人员都知道这个“工作淡季”。但如果你的团队是提供互联网服务的,你现在可以停止阅读了。(等一下,你一开始读本栏目的时间哪来的?回去干活!)     作者注:零Bug反弹(ZBB,Zero Bug Bounce)描述了第一次出现项目中的所有功能都完成了、并且所有工作条款都解决了的那个时刻。这个时刻很少会长时间持续。通过进一步的系统测试,通常在1小时之内就会有新的问题暴露出来,随后团队又必须埋头去工作。尽管如此,... 查看全部[ 2002年6月1日:“闲置人手” ]

    很好,我们已经知道了开会的理由,也知道了我们正在做什么。现在的问题是,为什么他们会在这里?我指那些不该在这里的人。这些人在问一些多余的问题,他们只是在重复别人的观点,他们只需在必要的时候表示一下同意。那么,为什么这些人会在这里呢?     会议的持续时间跟参加会议的人数是直接成比例的,说不定它们的关系还是线性的。你应该只邀请那些必须出现在会议上的人。      试图做一个决定?邀请可以做决定的人。其他所有人都可以在会议之后、通过e-mai了解到会议的情况。不是所有必要的、需要做决定的人都能参加吗?那就取消会议。立即取消!否则,你将不得不在所有人都能参加的时候重新召集会议。      状... 查看全部[ 为什么他们会在这里? ]

    我不是项目经理(PM,Program Manager)。我也从来没有担任过项目经理。我将来也不可能成为一名项目经理。这并不是我个人对项目经理的抵触。因为我的朋友之中不乏有出色的项目经理。很显然,我没有权利去教导项目经理怎么去做他们的工作。     尽管如此,项目经理应该停止写规范书。就这么简单!他们在浪费我的时间,浪费组织的时间,浪费整个公司的时间。你几乎可以听到残留着的、细微的、嘎扎嘎扎的声音,因为规范书像白蚁一样在一口一口咬掉公司和客户的价值。我对此深恶痛绝!     其实不仅仅是项目经理。开发者也必须停止写开发规范书。测试者则必须停止写测试规范书。疯狂必须停止!浪费必须停止!我们... 查看全部[ 2006年7月1日:“停止写规范书,跟功能小组呆在一起” ]