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

Question

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

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

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

为什么我认为公司会这样做：

• 傲慢与傲慢自我主义 - 公司的sombody认为他可以做得更好。
• 无知 - 忽略现有的框架/解决方案以及只有好的框架能够存活足够长时间才能流行的事实。忽略用户组和Internet上已有的信息。
• 管理失败和无能 - 不理解这种决定的影响（特别是长期）。基于错误信息的决策。没有软件开发背景的管理。

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

修改

感谢您的回答，但我期待一些建议如何作为开发人员处理问题（除了更换工作）而不是作为经理。

Answer 1

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

解决方案很棘手 - 很难知道是什么激励开发人员，因为每个人都受到不同事物的激励，但是那些忙于做他们喜欢的事情的开发人员并不会感到受到这种疾病的影响！

也就是说，经过深思熟虑的框架在正确使用时肯定是好东西 - 但是如果它只在内部使用那么最好将其视为re的扩展因子分解和代码重用而不是框架。

有人患有无聊的开发者框架综合症的典型标志是，当一个框架正在开发以解决一般情况时，还没有针对特定情况的解决方案< / EM>：

• 在解决至少一个特定案例之前，您怎么知道如何解决一般案例？
• 除非您必须解决一般情况，否则您只是猜测框架甚至需要。

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

相反，将这些类型的框架更多地视为“广泛重构”的练习 - 如果框架是作为一种按需分组和整理公共代码的方式生成的，那么框架将在动态上增加大小和复杂性 - 在开始生成框架之前已经解决了这个问题也很好，因为这意味着你已经是框架需要做的任何专家。

最后，试图阻止开发人员感到无聊（否则他们会遇到各种各样的恶作剧！）

Answer 2

泛化很糟糕，但这是我注意到的，特别是在大型企业项目中：

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

• 错过最后期限，错误，高额转换往往通过应用花哨的方法（通常是糟糕的实施）来解决，比如scrum或聘请高价位的顾问会让事情变得更糟，......而不是去除（或指导） ）不应该在第一时间雇用的人。

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

所以我唯一的建议是：

聘请更好的经理，他们非常了解业务和软件开发。他们不会雇用那种人，或者会尝试教他们如何考虑商业以及纯软件开发。他们还会理解，员工最强大的动力是让他们为该公司工作自豪。

Answer 3

我会在这些事情发展过程中添加其他一些原因，我在不止一个地方看到了这个：   - 开发人员锁定。一旦你的开发人员在不可转让的技能组合中编码，他们就很难离开。   - 作者锁定。根据框架，在维护中有多个应用程序，您的组织将依赖于管理组。   - 政治控制。集中化使框架成为政治控制的渠道。