【IT168 技术文章】
软件开发组织比以往更能意识到适当地拥有一个有效过程的重要性。当我谈到有效这个词时，意思是指一个通过帮助管理风险、变更、时间表、质量、以及所有对软件开发项目成 功有贡献的事情从而帮助组织达到它的目标的过程。这个月我们将思考如何在您的组织中实现这样一个过程。
无论怎样，我们将间接地处理这个问题。也就是说，我们不是考虑那些帮助改善过程的积极行为，而是关注那些看起来能够大幅度提高我们的过程，但实际上使事情变得更糟糕的 行为。这些负面的行为通常是按照下面的反模式标题进行分类的。
模式（Pattern）与反模式
模式是当今软件专业人员工具箱中的一部分。明确地说，我们学习设计模式——设计我们程序的方法，使它们功能更强大、更灵活、更准确。Erich Gamma 在90年代初期他的博士论文中提出了软件设计模式的基础。Gamma 从 Christopher Alexander 那获得很多灵感，Christopher Alexander 是一位研究体系结构学科（不是软件体系结构）中模式概念的架构师。1995年设计模式一书的出版使模式的发展成为软件开发学科。 1
模式仅仅是一个解决普遍发生问题的被证实过的方法。模式并不是您仅仅只需要剪切和粘贴的具体解决方法，而是一个您如何解决问题的方法。模式与只需要在空白处填写内容的模板 并不完全一样。
模式不是发明。您不需要在遇到一个问题的时候坐下来专门创造一个模式来帮助您解决这个问题。事实是我们把模式看作可再度使用的组件，它应该给我们这样的警告：我们 发现了模式而不是发明了模式。我们可能经常认为我们要编写一个可重用的软件组件，事实上重用就表明在前面已经使用过。因此 我们真的不知道我们所创建的可重用组件是否是一件很好的事情，直到有人使用我们的组件，然后又有人重用。对于模式也是这个道理。我告诉我的学生们一个简单地经验： 一次是事件，两次是偶然，三次就是该想想您是否发现了模式的时候了。
模式因为能够让软件开发人员使用一种常见的语言而变得十分流行。他们使用像“适配器（adapter）”和“门面（facade）”等术语就像工匠使用“燕尾接合”一样。这种语言用能够传输大量语义的 单词丰富了我们的词汇量。一旦模式变得流行起来，模式就开始出现在软件开发的其它领域，如过程，需求分析等等。每个专业领域都想引入这个以新的眼光观察世界的方法。模式是 90年代的“下一个重大事件”。现在已经有一些关于过程、需求管理、软件构架、测试、项目管理等模式的书籍和文章。从业者和理论家们都想采取一种很好的方法让它适合于我们 所做的任何事情。我只热爱80年代中期面向对象的 pen。我仅仅是说 pen.write ，它就能够神奇地完成它的工作。 2
在我看来，这种寻找模式的热潮导致了一种典型的情景：因为树木挡住了道路所以我们看不到森林。突然之间所有的事物都变成了一种模式，从持有一个编码标准到支持代码走 查以及选择一个程序设计的语言。应用模式需要思考，理解这些问题，判断使用这种模式的后果，以及经验。
发现和应用模式的后果之一是，模式就像药品，会导致滥用或错用。换句话说，我们对一个特定的模式开处方，但是令我们感到懊恼的是，这个病人（在我们 的例子中是一个软件开发组织）的病情变得更加严重，甚至可能死去。在我们观察这些效果时，我们发现了一种反模式。当一个似乎能够很好解决问题的方法实际上使 问题变得更加糟糕时，就会出现一种反模式。我认为 Fred Brooks 所描述的就是首批反模式之一，他说在一个进度延迟的项目中增加更多的人员会导致进度更加延迟。 3
在先前的文章中我曾经描写了一些在为您的组织和团队执行过程时值得思考的重要问题。 4 然而在这里我将展现一些在您考虑调整小组的过程时需要密切关注的反模式。
描述过程反模式
反模式，跟模式一样，可以用一定的形式来描述它们。也跟模式一样，没有普遍适用的方式可以描述它们。出于对我们的目的的考虑，我将用下面我曾描述过的说明形式对过程 反模式进行描述:
. 名称： 名称为反模式提供了一个简短，描述性的标签。
. 上下文： 描述了您将要解决的问题。
. 影响力： 这种影响力描述了这样一些事情，在组织上下文关系中，它促使您考虑利益以及优势等方面的问题，并引导您向解决问题方法的方向靠近。
. 解决方案：这是反模式中最关键的一点。在考虑到这些影响力之后，您选择了这种方法。您这样做是因为它看起来是合乎逻辑的，正如 Brooks 所说的在延迟的项目中增加人员的例子那样。然而 ，实际的经验告诉我们这种解决方案实际上会导致更多的问题。
. 后果： 描述了使用这种模式的负面效应。
. 替代方案： 这是一种替代的解决方案，您可以考虑用来避免这种负面效应。
免责声明
我选择用来表现反模式的描述并不是唯一的。我已经从 Coplien 和 Harrison 所著的Organizational Patterns of Agile Software Development中拷贝了绝大多数他们的观点。我向每一位想要学习如何提高软件开发组织效果的人推荐这本书。
我还要向大家说明的一点是我的列表中的这些反模式并没有经过实际验证。这些模式反映了我个人的观察结论，这些结论是我从组织以及那些我曾参与、观察，或者学习过的项 目中得到的。从学术的观点来看，这些仅仅是更严格研究的开端。Coplien 和 Harrison 已经完成了他们的预备工作，并对他们书中所提到的模式进行了深入地研究。我 并不是说这篇文章能够让人产生跟他们一样的信息。然而，我确实认为您可以找到一些能与您经历产生共鸣的例子，并让您产生深入的思考。
现在，了解一下反模式...
我总是对这个反模式出现的高频率感到诧异。对我来说是增量地进行变更似乎是一种常识。在上个世纪九十年代，我曾见到许多组织都尝试大规模地改变他们做事情的方法 ，而不管他们要实施的过程。我在那些设法利用 Rational 统一过程，RUP，软件工程研究所的能力成熟度模型(CMM)以及像类似极限编程 (XP)一样的敏捷过程的组织中也观察到相同的现象。我们想要相信采取一个新过程最好的方法是停止按照当前处理事情的方式去做，转而采取新的方法来做事情。但是我们往往丢 弃了我们组织中颇有价值的做事方法，因为在新的、更好的、更现代的过程中对它们应该做更加详细的定义。
