Question

在软件开发领域，有许多关于工具、形式模型、建模的著作。很多人声称UML和模型驱动架构（Model-Driven Architecture, MDA）是未来的趋势，还有很多人声称RUP和CMM过程模型是拯救行业的良方。

但是，正如所有关于银弹的想法一样，人们很快就发现这不那么容易。虽然这些工具和模型有自己的用途，在合适的环境中可能有效，但是它们当中却没有一个能成为梦想中包治百病的灵丹妙药。更糟糕的是，滥用这些方法将会得不偿失。

模型是工具，而非镜子。

The model is a tool, not a mirror.

有趣的是，护理专业在工具和形式模型的使用方面也存在类似的问题。他们像许多架构师和设计者那样掉进了同一个陷阱：忘记了模型是一个工具，而不是一面镜子。

规则无法告诉你在某种情况下应该采取的最合适行为或者正确路线。它们充其量也就是“自行车的辅助轮”——可以帮助启动，但是却限制并大大妨碍了以后的表现。

Deborah Gordon博士编写了Benner著作中的一章内容。在这一章中，她概述了过分依赖护理专业形式模型所造成的一些危害。根据我们行业的特殊性，我重新诠释了她的见解，但是即便是Gordon博士的原文，听起来也会让你觉得非常熟悉。

混淆模型和现实

模型不是现实，但是很容易混淆这两个概念。有一个关于年轻项目经理的老故事：团队里的高级程序员宣布她怀孕了并将在项目期间分娩，这位经理抗议道：“这不在项目计划中。”

低估不能形式化的特性

良好的问题解决能力对我们的工作很重要，但解决问题是一件很难形式化的事情。例如，你应该坐下来思考问题多长时间？10分钟？一天？一周？你无法对创造力和发明限定时间，因而，你也无法建立相应的技术。即使希望团队拥有这些特性，你仍可能发现管理部门根本不会重视它们——仅仅是因为这些特性无法形式化。

规定违背个人自主性的行为

你不希望一群猴子敲打键盘编写代码。你需要能思考、负责任的开发人员。对形式模型的过度依赖往往会鼓励羊群行为^〔18〕而贬低个人创造力^〔19〕。

偏袒新手，从而疏远了经验丰富的员工

这是一个非常危险的副作用。针对新手创建一套工作方法，对经验丰富的团队成员来说，你会建立一个恶劣的工作环境，他们会直接离开你的团队或组织。

阐明太多细节

阐明太多细节会适得其反。这会引发一种称为无限倒退（infinite regress）的问题：一旦你详细解释了一系列假设，你就提前暴露了本应简单提出的下一个层次的假设。如此下去，只会带来恶性循环。

把复杂局势过于简单化

Rational统一过程（和一些新方法）的早期支持者坚持声称，你需要做的仅仅就是“按部就班”。一些极限编程的支持者坚称你需要做的就是“只要遵循这12——不，等一下，也许是13种——实践方法”，然后所有问题都可以解决。这两种观点都是错误的。每个项目、每种情况都比那更复杂。每当有人开始说“你需要做的仅仅是……”或者“只需要做这个……”，他们十之八九错了。

追求过度一致

同样的标准不可能放之四海而皆准。上一个项目里最管用的东西对当前这个项目来说可能是一场灾难。就算Eclipse能提供给Bob和Alice巨大的生产力，它也有可能会毁掉Carol和Ted。后者宁愿选择IntelliJ或者TextMate或者vi^〔20〕。

忽视情境的细微差别

形式方法针对典型情况，而不是特殊情况。但是，“典型”真的会发生吗？情境对专业表现至关重要，而形式方法往往会在它们的公式中丢掉情境的细微差别（它们不得不如此；否则，它们得花费数千页纸来描述早晨如何喝到咖啡）。

在遵从规则和自行判断之间犹豫

什么时候适合打破规则？任何时候？永远不能？还是介于两者之间？你如何知道？

故弄玄虚

语言表达如果过于口号化，它就会变得微不足道，并最终完全失去意义（例如，“我们是一个以客户为中心的组织！”）。敏捷方法正因为这个问题很快失去效力。

形式方法有其他优点和用途，但是在实现这些目标时不起作用。虽然它可能有助于为较低技能水平的人建立基准规则，但是判断力是无法取代的。随着判断力增强，对于规则的依赖必须放宽，伴随着严格的制度执行。

诀窍6

如果你需要创造力、直觉或者独创能力，避免使用形式方法。

不要屈服于工具或者模型的虚假权威。没有什么可以替代思考。