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

Question

我前几天正在和一位同事讨论为您的开发组织实施软件工厂的相似之处，而不是像使用更多的活动记录这样的脚手架解决方案。我们都认为，当你有一大批开发人员并且希望在代码库中保持一定程度的一致性和约定时，实施软件工厂可能被某些人认为是一个好主意。

再想一想，我意识到我非常喜欢软件工厂供个人使用的想法，因为它们让我更容易地编写我工作的项目，因为它们为我节省了很多时间头疼的书面“样板”代码。话虽如此，我敢打赌，在较大的组织中强制使用软件工厂可能会导致团队内部发生冲突，因为一些开发人员可能认为这会对他们的创造能力造成侵害。

所以，我想知道（从你们谁已经已经实现工厂组织的一部分）是什么标准则需决定在组织内部使用的工厂，当风险可能是一群不开心的开发者？

Answer 1

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

用回调或其他扩展点组织构建的构件也很重要（也是完全可能的！关键是要确保开发者能够看到你的工作是支持他们，而不是他们替代他们。

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

Answer 2

本着SO的精神，恕我直言，没有哪个组织可以从软件工厂中获得更多的利益，相比于良好的框架（Spring，Windsor，Active Record）。

软件工厂对于那些打造工厂的人来说只是一件有趣的事，工厂的比喻非常适合。在SF环境中，编码可能会变得重复和无聊，你实质上是在告诉你的团队，顺便说一句，你实在太愚蠢了，所以我们要确保你不会犯任何错误。我知道这听起来很刺耳，但这就是它的表现方式（当然，当我们尝试时，我在这个方程式的有趣一面）。一致性和惯例可以通过各种手段来加以实施（我讨厌强制执行），代码审查是最好的，但很难做到，代码分析（FxCop等）是最糟糕的，但它们确实涵盖了基础知识。

SF方法的另一个问题是，当工厂不满足特定需求时，那么编码器会丢失，他们已经与基础技术隔离，以至于他们没有关于发生什么事情的概念模型上。这就像要求生产线无人机建造引擎，他们不知道从哪里开始。另一方面，一个体面的机械师会知道该怎么做（或去哪里）。你应该用强大的工具赋予你的团队力量，而不是用不必要的工厂方法来限制他们。