查字典图书网
当前位置: 查字典 > 图书网 > 编程 > 代码之道 > 试读

代码之道[试读]

读者对I. M. Wright’s “Hard Code”栏目的喝彩

    任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话,最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向,但它对于需要不断创新才能繁荣的技术公司来说,却是个致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀,深深地切入了组织内... 查看全部[ 读者对I. M. Wright’s “Hard Code”栏目的喝彩 ]

    长期以来,我一直在阅读Eric Brechner以I. M. Wright为笔名撰写的栏目。当我第一次见到作者本人的时候,我费了好大的劲才让自己相信,我是在跟同一个人说话。Wright先生非常地自以为是,然而站在我面前说话的人却那么谦虚、彬彬有礼、非常友好,他看起来更像Clark Kent。... 查看全部[ 序 ]

简介

    献给当初对我说“为什么不由你来写?”的人:Bill Bowlus     你手上拿着的是一本关于最佳实务的书。它会比较乏味。但也许会比较有意义,你能从中得到知识,读后甚至对你产生些许影响,但读起来肯定还是干巴巴而无趣的。为什么这么说呢?     最佳实务的书是乏味的,因为这个“最佳”是跟具体... 查看全部[ 简介 ]

根除低下的效率

    本章内容:     2001年7月1日:“迟到的规范书:生活现实或先天不足”     2002年6月1日:“闲置人手”     2004年6月1日:“我们开会的时候”     2006年7月1日:“停止写规范书,跟功能小组呆在一起”     2007年2月1日:“糟糕的规范书:该指责谁?” ... 查看全部[ 根除低下的效率 ]

对于每次变更,搅动,搅动,搅动

    也许在极端情况下,变更还不止一次。但这的确有可能发生。即使变更没有那么晚,规范书常常也是不完整的,或者在尚未被开发人员及时复审和检查之前就匆忙交付开发了。     结果怎么样呢?搅动代码,一次又一次地更改以前的实现。开发人员开始编码的时间太早了!规范书本身就有问题,因此代码自然也有问题。当有... 查看全部[ 对于每次变更,搅动,搅动,搅动 ]

规范书变更请求

    我最喜欢的方法是“规范书变更请求”(SCR,Spec Change Request),它还有一个扭曲的名字叫“设计变更请求”(DCR,Design Change Request)。这种方法是委员会议和走廊会议的组合,同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容,你... 查看全部[ 规范书变更请求 ]

2002年6月1日:“闲置人手”

    你的开发团队两周前达到了“零Bug反弹”(ZBB,Zero Bug Bounce), 你突然意识到,你又迎来了一个“工作淡季”。任何从事零售软件产品开发、并且碰到过零Bug反弹的开发人员都知道这个“工作淡季”。但如果你的团队是提供互联网服务的,你现在可以停止阅读了。(等一下,你一开始读本栏目... 查看全部[ 2002年6月1日:“闲置人手” ]

为什么他们会在这里?

    很好,我们已经知道了开会的理由,也知道了我们正在做什么。现在的问题是,为什么他们会在这里?我指那些不该在这里的人。这些人在问一些多余的问题,他们只是在重复别人的观点,他们只需在必要的时候表示一下同意。那么,为什么这些人会在这里呢?     会议的持续时间跟参加会议的人数是直接成比例的,说不定... 查看全部[ 为什么他们会在这里? ]

2006年7月1日:“停止写规范书,跟功能小组呆在一起”

    我不是项目经理(PM,Program Manager)。我也从来没有担任过项目经理。我将来也不可能成为一名项目经理。这并不是我个人对项目经理的抵触。因为我的朋友之中不乏有出色的项目经理。很显然,我没有权利去教导项目经理怎么去做他们的工作。     尽管如此,项目经理应该停止写规范书。就这么简... 查看全部[ 2006年7月1日:“停止写规范书,跟功能小组呆在一起” ]