您使用什么标准来确定是否实施软件工厂？

Question

前几天我与同事讨论了为您的开发组织实施软件工厂与使用更多脚手架解决方案（如活动记录）的相似之处。我们都认为，当您拥有更多的开发人员并希望在代码库中保持一定程度的一致性和约定时，某些人可能会认为实现软件工厂是一个好主意。

再考虑一下，我意识到我非常喜欢软件工厂的想法供个人使用，因为它们让我更容易编写我工作的项目以获得乐趣，因为它们为我节省了很多写“样板”代码令人头痛。话虽这么说，我敢打赌，在大型组织中强制使用软件工厂可能会在团队中引起一些冲突，因为一些开发人员可能认为这会侵犯他们的创造能力？

所以我想知道（来自那些已经成为已经实施工厂的组织的人）是 标准 需要指示使用一个组织内的工厂，当风险可能是一群不开心的开发人员？

Answer 1

我建议这取决于你的工厂生产什么。肯定有许多“陈词滥调”代码的例子，其生产可以自动化，允许开发团队将他们的创造力集中在真正需要人类智能的代码部分。

使用回叫或其他扩展点组织构造的工件也很重要（并且完全可能！）;关键是要确保开发人员能够看到你的工作支持他们，而不是取代。

以上意味着您（和您的团队）将强制进行更多的前期规划，以最小的摩擦来实现协调，“哦，我们忘记了 - 我们 - 还需要......“事件。这可能会产生一些抱怨。但是，如果你做对了，你就可以在某个时候加强并通过调整工厂来处理一些外部需求，而不会中断他们自己的工作。在那时，他们中的更多人应该开始将你视为盟友。

Answer 2

本着SO的精神，与良好的框架（Spring，Windsor，Active Record）相比，没有大型或小型的组织可以从软件工厂获得更多。

软件工厂只对建造工厂的人有趣，工厂类比非常贴切。在SF环境中，编码可能变得重复而且无聊，你实际上是在告诉你的团队，顺便说一句，你实际上太愚蠢了，所以我们要确保你不会犯任何错误。我知道这听起来很刺耳，但这就是它的结果（是的，当我们尝试它时，我就处在等式的有趣方面）。一致性和约定可以通过各种方式包含（我讨厌强制执行），代码审查最好，但很难做到，代码分析（FxCop等）是最差的，但它们确实涵盖了基础知识。

SF方法的另一个问题是，当工厂不满足特定需求，然后编码器丢失时，他们已经与基础技术隔离到如此程度，以至于他们没有关于正在发生的事情的概念模型。这就像要求生产线无人机构建引擎，他们不知道从哪里开始。另一方面，一个体面的机械师将知道该做什么（或去哪里）。您应该使用优秀的工具为您的团队赋权，而不是通过不必要的工厂方法限制他们。