您使用什么标准来确定是否实施软件工厂？
前几天，我与一位同事讨论了为开发组织实施软件工厂与使用更多脚手架解决方案（如活动记录）的相似之处。 我们都认为，当您拥有更多的开发人员并且您希望在代码库中保持一定程度的一致性和约定时，某些人可能会认为实现软件工厂是一个好主意。
再想一想，我意识到我真的很喜欢供个人使用的软件工厂的想法，因为它们让我更容易编写我为了好玩而从事的项目，因为它们让我在写作方面省去了很多麻烦。 “样板”代码。 话虽这么说，我敢打赌，在较大的组织中强制使用软件工厂可能会在团队内部引起一些冲突，因为一些开发人员可能认为这会侵犯他们的创造力？
所以我想知道（来自那些曾经参与过工厂实施的组织的人）是需要什么标准来决定工厂的使用在一个组织内部，什么时候风险可能是一群不高兴的开发人员？
I was discussing with a co-worker the other day the similarities of implementing a Software Factory for your development organization vs. using more of a scaffolding solution like active record. We both thought that implementing a Software factory may be considered by some to be a good idea when you have a larger group of developers and you want to maintain a certain level of consistency and convention within your code base.
Thinking about it a little more, I realized that I really like the idea of Software Factories for personal use, because they make it easier for me to code up the projects that I work on for fun as they save me a lot of headache in writing "boilerplate" code. That being said, I would bet that enforcing the use of a Software Factory in larger organizations might cause some strife within the team because some developers may think that it would be an infringement on their ability to be creative?
So what I'm wondering (from those of you who have been part of an organization that has implemented factories) is what criteria would it take to dictate the use of a factory within an organization, when the risk may be a bunch of unhappy developers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议这取决于你的工厂生产什么。 当然有很多“陈词滥调”代码的例子，它们的生产可以自动化，从而使开发团队能够将创造力集中在真正需要人类智能的代码部分。
使用回调或其他扩展点来组织构建的工件也很重要（并且完全可能！）； 同样，关键是要确保开发人员能够看到您的工作正在支持他们，而不是取代他们。
上述情况意味着您（和您的团队）将被迫做更多的前期规划，以最小化摩擦和“哦-我们-忘记-我们-也-”来实现协调需要……”事件。 这可能会引起一些抱怨。 然而，如果你做得正确，你就会在某个时候站出来，通过调整工厂来处理一些外部需求，而不会中断他们自己的工作。 到那时，他们中的更多人应该开始将你视为盟友。
I suggest that it depends on what your factory is producing. There are certainly many examples of "cliche" code whose production can be automated, allowing the development teams to focus their creativity on the parts of the code that really take human intelligence.
It is also important (and entirely possible!) to organize the constructed artifacts with call-backs or other extension points; again the key is to make sure that the developers are able to see that your work is supporting them, rather than displacing them.
The above mean that you (and your teams) will be forced to do more up-front planning to achieve the coordination with a minimum of friction and "oh-we-forgot-that-we-also-need..." events. That will likely produce a bit of grumbling. However, if you do it right, you'll get to step up at some point and handle some external demand by tweaking the factory, with no interruption to their own work. At that point, more of them should begin to see you as an ally.
本着 SO 的精神，恕我直言，与良好的框架（Spring、Windsor、Active Record）相比，无论大小的组织都无法从软件工厂中获得更多收益。
软件工厂只对那些建造工厂的人来说是有趣的，工厂的比喻非常贴切。 在 SF 环境中，编码可能会变得重复和无聊，你本质上是在告诉你的团队，顺便说一句，你实际上太愚蠢了，无法弄清楚这一点，所以我们将确保你不会犯任何错误。 我知道这听起来很刺耳，但结果就是这样（是的，当我们尝试它时，我处于等式的有趣的一面）。 可以通过各种方式鼓励（我讨厌强制执行）一致性和约定，代码审查是最好的，但很难做到，代码分析（FxCop 等人）是最差的，但它们确实涵盖了基础知识。
SF 方法的另一个问题是，当工厂不能满足特定需求时，编码员就会迷失，他们与底层技术隔离开来，以至于他们对正在发生的事情没有概念模型。 这就像要求生产线无人机制造发动机一样，他们不知道从哪里开始。 另一方面，一个好的机械师会知道该做什么（或去哪里）。 您应该为您的团队提供强大的工具，而不是用不必要的工厂方法来限制他们。
In the spirit of SO, IMHO there is no organisation large or small that would get more out of a Software Factory compared to a good framework (Spring, Windsor, Active Record).
Software factories are only fun for those who build the factory, the factory analogy is very apt. Within an SF environment coding can become repetitive and boring, you're essentially telling your team, BTW you're actually too stupid to figure this out so we're going to make sure you can't make any mistakes. I know that sounds harsh, but that's how it pans out (and yes I was on the fun side of the equation when we tried it). Consistency and convention can be encoraged (I hate enforced) by all kinds of means, code review is best, but hard to do, code analysis (FxCop et al) are the worst but they do cover the basics.
Another problem with the SF approach is when the factory doesn't meet a particular need, then the coders are lost, they've been insulated from the underlying tech to such an extent that they have no conceptual model of what's going on. It's like asking a production line drone to build an engine, they don't know where to start. On the other hand a decent mechanic will know what to do (or where to go). You should be empowering your team with great tools, not restricting them with an unnecessary factory approach.