如何处理公司内部框架和软件工厂？

Question

根据我自己的经验和我朋友的经验，我发现许多公司都有一些奇怪的想法来开发自己的框架和SW工厂（为您构建应用程序框架）。这些想法通常基于相信自己的框架将比任何其他可用框架更好。如何处理这样的想法，以及如何解释它并不总是好的方法？

为什么我认为内部框架/工厂并不好：

• 预算&资源 - 通常只有一些初步的预算，以创建框架。没有人会考虑维护和支持框架所需的预算。没有人可以估算维护所需的预算和资源。起初没有人会考虑维护多个版本的框架来支持现有的应用程序。
• 缺乏经验 - 框架通常是由没有任何此类经验的人员或“顾问”支持人员创建的 - 通常是具有相似技能的昂贵人员。
• 架构/设计 - 框架中的任何架构问题都会影响使用此框架构建的所有应用程序。框架中糟糕的设计决定会迫使开发人员以糟糕的方式编写应用程序。
• 技术债务 - 框架中的坏代码是技术债务。
• 银弹的虚假信念 - 管理者认为自己的框架/工厂是银弹。所有应用程序将以相同的方式编写，并且易于维护。我的经验是，这很简单，而不是真相。即使在SW工厂，每个应用程序也是特定的
• 文档不足 - 文档首先受低预算影响。没有文档的框架是无用的。反射器（.NET）是我最好的朋友。
• 用户组不足 - 内部框架只有很小的用户组。小型用户群意味着小的体验。如果我使用的是公共工具/框架，并且遇到问题，我可以在SO（或类似网络）上提问，或者试着在Google上找到答案。有了内部框架，这是不可能的。
• 政策 - 公司政策强制您使用框架来维护框架成本。迄今为止，在收集第一个需求之前选择框架。
• 禁止向投诉框架投诉。
• 禁止使用其他框架。

为什么我觉得公司这样做是：

• 傲慢&利己主义 - sombody在公司相信自己能够做的更好。
• 无知 - 忽略现有的框架/解决方案，以及只有好的框架才能存活到足以流行的事实。忽略Internet上的用户组和已有的信息。
• 管理失败和无能 - 不了解这个决定的影响（特别是长期）。基于不正确的信息进行裁决。没有SW开发背景的管理。

据我所知，有时候需要专门场景的解决方案或框架，但我厌倦了用于创建Web或桌面应用程序的所有这些“优秀的内部框架”。我错了吗？这些框架是否真的需要（.NET和Java世界）？你能否提供一些例子或理由说明为什么有内部框架/工厂是好事？

编辑：

感谢的答案，但我预计一些建议如何处理一个问题，因为开发者（除了改变工作），而不是作为一个经理。

Answer 1

在我的经验中，过度框架最常见的原因是... 无聊的开发人员！没有灵感的开发人员发现，开发解决问题的框架比实际解决这些问题要有趣得多 - 最终的结果就是遭受上述所有问题的框架（因为开发人员只是做了一些有趣的事情），并且可能不会甚至解决实际问题（因为目标是获得乐趣，而不是解决问题）。

解决方案很棘手 - 很难知道激励开发人员的是什么，因为每个人都被不同的事物驱动，但是忙碌的开发人员却忙于做自己喜欢的事情，却不会患上这种疾病！

这就是说，经过深思熟虑的框架正确的使用绝对是一个好事 - 但是如果只打算在内部使用，那么它可能会更好，而不是把它作为一个扩展再保理和代码重用 - 而不是一个框架。

的经典标志，有人从无聊开发框架综合征痛苦是当正在开发一个框架，解决了一般情况下时，有没有针对具体情况的解决方案：

• 如何知道如何解决一般情况，直至解决至少一个特定情况？
• 直到你不得不解决一般情况几次，你只有猜测，一个框架甚至需要。

第二种情况当然会导致最糟糕的框架 - 只有一次使用的庞大通用框架来解决比框架本身简单得多的问题。

反而将这些框架视为“广泛重构”中的一个练习 - 如果框架是按照需要分组和整理通用代码的方式生成的，那么框架的动态规模和复杂性将会增加 - 在开始生成框架之前就已经解决了这个问题，因为这意味着无论框架需要做什么，您都已经是专家。

最后，尽量保持开发人员从无聊（他们起床各种恶作剧否则！）

Answer 2

泛化是不好的，但这里是我已经注意到了，尤其是在大型企业项目：

• 这种行为通常是由几个软件工程师的一个驱动（它们通常命名themselve 软件架构师）属于你在你的问题中写的描述。每个人都需要为某些事情感到自豪，有勇气在早晨醒来。我将补充一点，他们通常是由于这个原因的CV驱动，并尝试应用最新的设计模式，而不考虑业务影响和ROI。关键不是雇用那种人（或者试图教他/她理解他/她的选择的商业后果）。试图让他们为公司工作感到自豪，而不是在他们的框架上工作也可能会有所帮助。

• 错过了最后期限，错误，高转换倾向于通过使用奇怪的方法（通常很糟糕的实施），如scrum或聘请高价格的顾问，会让事情变得更糟......，而不是去除（或指导）那些本来不应该被雇用的人。

• 除去有问题的人在大多数情况下是坏事，因为他拥有这个东西。所以教他/她理解他/她的选择的后果可能是解决问题的最合适的方式。但要做到这一点，你需要一个好经理。

所以，我唯一的建议是：

服务更好的管理者是很明白的商务和开发软件。他们不会雇佣那种人，或者试图教他们除了纯软件开发以外如何考虑业务。他们也会明白，为员工提供的最强大的动力燃料是让他们为感到自豪为该公司工作。

Answer 3

我想补充这些东西发展一些其他的原因，我已经在一个以上的看到了这一点地点： - 开发人员锁定。一旦你的开发人员编写了不可转让的技能集，他们很难离开。 - 作者锁定。一旦有多个应用程序依赖于框架进行维护，则组织依赖于管理组。 - 政治控制。集权使框架成为政治控制的渠道。