摘要: 你曾听说过一名专业软件开发人员应该掌握一种驱动方法吗？这些驱动方法可能是：领域驱动设计（Domain-Driven Design）、测试驱动开发（Test-Driven Development）、行为驱动开发（Behavior-Driven Development） ...
谁创建了它？ 在建立他们的突破性概念时，Ken Beck、Dan North、Eric Evans、Steve Freeman、Ivar Jacobson和其它心理框架的作者们已经在各类项目、不同人群、领域和技术上积累了多年的经验。那些生搬硬套使用这些框架（认为它将改变他们的生活）的人有哪些经验呢？本文后面将再回到这个问题。 如果让我改述一个关于建房子的流行说法，我会说我们的第一个系统是给敌人建的，第二个系统是给朋友建的，只有第三个系统才是给我们自己的。想想你的职业生涯，最初的编码留下了多少坑。接下来你的代码使用了很多润滑和工程相关的东西，以至于你自己都不理解。再经过一段时间，你终于做到了中庸之道（有趣的是你无法平分成黄金比例）和实用主义。 根据Singley和Anderson的著作The Transfer of Cognitive Skills以及Woltz、 Gardner和Bell的文章Negative transfer errors in sequential cognitive skills，当你在一个项目上工作，又开始另一个项目的工作，你通常会体验到知识迁移，意思是迄今为止你所掌握的技能能够用于另一个项目，并且能让你更有效地开发新的、有用的技能。这种迁移被称为正迁移，是我们最需要的。然而，负迁移也是有可能的，因为掌握了一种技能可能使另一种技能更难掌握。 所有这些心理框架的作者已经转战于各种项目并有丰富的经验。因此，他们体验了学习的正迁移并获得特定的知识、技能和专业技术。在某个时刻，他们经历了我所说的“启迪”（或者更常用的说法，灵光一闪、啊哈！效果或模式转变）。这常常是偶然发生的，有时候是在梦里，触发了思维过程的整个链条，启迪了这些作者。基于经验、思考和总结，他得出了一种思想，例如红-绿-重构。这种思想把有序带入现有知识中，并给它灌输更深入和更普遍的意义。从技术上讲，这是归纳概括（如图1）。基于他的专业知识并通过归纳推理的方法，作者建立了一个概括其个人经验的理论。然后他开始向世人介绍这个新的心理框架。他或她开始写书。 图1 心理框架是如何建立的？ 归纳的结果 归纳有一个问题：它不能保证结论是正确的。这不是大问题，因为框架没有必要逻辑“正确”，它只需要“在给定的上下文环境中是有用的”。现在我们来到了这个点，即上下文环境是个关键，它就是概括出新想法的那些经验。当作者想分享他的探索，并开始写书，新的未曾预料的问题出现了。如何在他不熟悉的其它上下文环境中使用框架？如何将框架应用于他不了解的项目、架构和技术中？他接下来该怎么做呢？他使用推论（如图2）。 图2 如何在别的上下文环境中使用框架？ 基于他自己的经验和想出来的这个框架，他进行推理和论证并得出结论，在这个新的上下文环境中，应该以特定的方式使用框架。在这个阶段，不同类型的论证是必要的。归纳推理使框架能够基于实际经验。通过逻辑思维演绎推理该框架，避免其与现实冲突。当然，冲突是有可能的，但它可能要数年时间，并且竞争从未停止。 演绎推理在有些情况下能够得出正确的结论。而另一些情况下，结果可能有所不同。有时候只需要重温和回顾就能得出结论。Eric Evans的书《领域驱动设计:软件核心复杂性应对之道》就是个例子，特别是战略设计这部分。当我们观察Evans先生的活动，我们将发现当他使用DDD时，他的结论是书中的部分观点应该更准确或者应该换种方式突显出来。我们发现了一些更新：介绍了Domain Language Model Exploration Whirlpool过程，特别强调有边界上下文（Bounded Context）角色、领域事件（Domain Event）的更准确定义以及它与有边界上下文更准确的关系。 谁能使用它？ 当作者遇到新的、未知的环境，他的框架不起作用时，他会怎么办？他将依赖自己的经验，做一些小的尝试，跟踪其效果，然后对其想法做一些小修正。绝大多数情况下，心理框架的作者拥有丰富的经验和相当专业的知识，知道如何面对新情况。换言之，作者明白如果框架的教条越多，则其价值将越少。基于他利用的是自己的经验（这总是很方便）这个事实，如果他认为它是没有意义的，他可能会立即停止使用他的框架。他会根据自己的经验选择别的解决方案，或者修改框架。 现在让我们想像一下这样一个场景。一个缺乏经验的开发人员使用某种驱动方法，结果会怎么样呢？当他按书中和网上的教程开始编程，一切看起来好像很顺利。但事实上，我们几乎不会去开发一个教程那样的系统，很快问题就会出现。开发人员马上就要面对下面的问题：如何在新的、未知的环境中使用这种驱动方法？我们的这名开发人员经验很少，正在不断犯错误，也在不断取得成功。他没有足够的专业知识，他孤立无援。面对时间压力，他可能会做以下事情： 寻求有经验人士的帮助（这是最好的选项）； 开始努力尝试并最终得出正确的方法（成本有点高，但可接受）； 在互联网上寻找解决方案（不一定正确）； 以教条的方式使用心理框架，即使它没有任何意义，也排除万难完成任务； 停止使用框架，回到他的老习惯。 以上5种情形中，有3种情形的结果是令人沮丧的，框架相关的承诺并未实现。也许你认为这并不意味着该驱动方法没有效果。开发人员只是没有相关的经验来正确地使用驱动方法。心理框架的典型特征是他们是非常通用的。很难写一个适用于任何场景的详细过程。我甚至认为这是不可能的。心理框架需要解释。当你开始使用它们，并期望只收获好处，你就需要在给定的上下文环境中解释它们。而这种解释依据的就是你自己的项目经验。 当然，有些开发者已经具备了某个心理框架所需的经验。他们会采用什么样的方法呢？他们通常有自己的思考和属于自己的框架。当他们有些人看到一个新的“革命性的”驱动方法时，会发现它的有趣面并意识到他们已经在使用它的一些元素。他们会从新框架中汲取他们想要的长处，或者完整地使用它，毕竟它有一个简洁又好记的名字。框架将会丰富他们的资源，使他们的工作更加有序。 根据我的粗略观察，我发现刚才提到的这些开发者有以下特征： 他们具有超过10年的经验； 他们具有各种各样的经验：不同的公司、不同的项目、不同的技术和不同的人群； 他们具有从独立的、看似无关的经验中概括一些模式，创造出广义概念的能力； 他们具有很好的工作方法，能够准确区分接口与实现，因此他们更多地关注要实现的目标，而不是实现目标的具体手段； 他们回顾性地评估自己的资源； 他们花时间拓展自己的知识面、提升自己的技能； 许多情况下，他们从自身行为中寻找失败的原因，而不是归因于外部环境； 他们有能力控制任务的规模。 最后两个特征通常是最大的挑战。要掌握它们，你需要不同寻常的巧遇，或者通常是多年广泛领域的强化训练。在我们看来，这些特征是每个开发者夯实他的心理框架的关键因素，对于推出他自己的驱动方法来说则更加重要。没有这两个特征，他也能获得大量关键知识和技能，足以轻松工作。这样的人很少关心心理框架，因为他通常更加了解。 所以，现在你知道为什么所谓的驱动方法没有改变任何事情了？因为当开发者没有所需的经验时，框架没有什么帮助，它在产生干扰。他认为自己在做专业的开发，但实际上他得到了更多的知识和更少的技能。因为他无法在特定的上下文中创新性地解释框架，因此他以不同的方式使用框架。如果开发者有所需的经验，他已经设计了自己的框架或者对它不感兴趣，因为他认为它不适合于自己的场景。 |
