大量变异

任何阅读过我作品的人都知道，我非常支持演化式设计。尽管我对这种方法充满热情，但没有一种技术是完美的，我很乐意报告它的问题，就像我报告它的成功一样。

到目前为止，我在两个项目中遇到了这个问题，尽管表现形式略有不同。

演化式设计期望团队在项目进行过程中修改设计；既要应对需求变更，也要利用学习成果。你可以把它看作是在设计中添加变异，以应对这些变化。这种变异是件好事，也是必要的，但就像很多好事一样，你也会过量。

第一个项目是一个大型项目，大约有 100 名开发人员。在这种情况下，过度变异的发生是因为不同的子团队会以不同的方式解决一个共同的问题。这可能是通过构建不同的框架或整合不同的外部框架来实现的。

第二个项目是一个中等规模的项目，有 12 名开发人员，但人员流动性很大。随着新人的加入，他们会查看解决问题的旧方法，不理解它或发现它有缺陷，然后转向新的方向。问题是，在新人进来发现这个半成品解决方案有缺陷之前，事情还没有完成……你明白我的意思。

在这两种情况下，最终结果都是用多种方法尝试解决同一个问题。不仅重复工作是浪费，而且它还使软件比必要时更复杂。

我应该强调，与同一组织中的其他系统相比，整体设计健康状况仍然相当不错。特别是，对自动化测试的关注使演化比通常更安全，这两个项目的缺陷率都明显较低。

冒着滥用隐喻式提问的风险，你可能会认为这是一个环境没有淘汰较弱变异的案例。理想情况下，当出现竞争设计时，它要么很快消亡，要么淘汰现有设计。这里的问题是，两者都没有发生。所以问题就变成了：如何才能迫使劣质设计退出系统？

在这两种情况下，我与之交谈的人员都认为缺乏整体设计领导力。在大型项目中，这是通过一个架构团队来实现的，该团队制定了一种解决这些问题的基本方法，然后密切沟通正在进行的工作。第二个团队目前还没有解决这个问题，但它被视为对更稳定的设计领导力的需求。因此，与其说是演化式隐喻，不如说是育种者鼓励良好性状，抑制不良性状。（这是达尔文的灵感来源。）

抛开隐喻不谈，我认为从根本上来说，这归结于遵循原则“持续关注技术卓越和良好设计，提高敏捷性”。演化式设计需要关注、技能和领导力。这仅仅是一种不同类型的领导力，与许多人通常认为的领导力不同。