前几天我正在与一位同事讨论为您的开发组织实施软件工厂与使用更多像活动记录这样的脚手架解决方案的相似之处。我们都认为，当您拥有更多的开发人员并且您希望在代码库中保持一定程度的一致性和约定时，实施软件工厂可能被某些人认为是一个好主意。
再想一想，我意识到我真的很喜欢供个人使用的软件工厂的想法，因为它们让我更容易编写我正在从事的有趣的项目，因为它们让我在写作时省去了很多麻烦“样板”代码。话虽如此，我敢打赌，在更大的组织中强制使用软件工厂可能会在团队内部引起一些冲突，因为一些开发人员可能认为这会损害他们的创造力？
所以我想知道（来自那些已经实施工厂的组织的成员）是什么标准来决定组织内工厂的使用，当风险可能是一群不开心的开发人员时?
我建议这取决于你的工厂生产什么。肯定有许多“陈词滥调”代码的示例，其生产可以自动化，从而使开发团队可以将他们的创造力集中在真正需要人类智能的代码部分。
用回调或其他扩展点组织构建的工件也很重要（并且完全有可能！）；同样，关键是要确保开发人员能够看到您的工作正在支持他们，而不是取代他们。
上述情况意味着您（和您的团队）将被迫做更多的前期计划，以最大限度地减少摩擦和“哦，我们忘记了，我们也需要......”事件的协调。这可能会产生一些抱怨。然而，如果你做得对，你会在某个时候站出来，通过调整工厂来处理一些外部需求，而不会中断他们自己的工作。到那时，他们中的更多人应该开始将您视为盟友。
本着 SO 的精神，恕我直言，与一个好的框架（Spring、Windsor、Active Record）相比，没有任何组织能够从软件工厂中获得更多收益。
软件工厂只对那些建造工厂的人来说是有趣的，工厂的比喻非常贴切。在 SF 环境中，编码可能会变得重复和无聊，您实际上是在告诉您的团队，顺便说一句，您实际上太愚蠢了，无法弄清楚这一点，因此我们将确保您不会犯任何错误。我知道这听起来很刺耳，但这就是结果（是的，当我们尝试它时，我处于等式的有趣方面）。可以通过各种方式鼓励（我讨厌强制执行）一致性和约定，代码审查是最好的，但很难做到，代码分析（FxCop 等人）是最差的，但它们确实涵盖了基础知识。
SF 方法的另一个问题是，当工厂不能满足特定需求时，编码人员就会丢失，他们与底层技术隔离到如此程度，以至于他们没有关于正在发生的事情的概念模型。这就像要求生产线无人机制造引擎，他们不知道从哪里开始。另一方面，一个体面的机械师会知道该做什么（或去哪里）。你应该用优秀的工具来授权你的团队，而不是用不必要的工厂方法来限制他们。