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

Question

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

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

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

为什么我认为公司这样做:

我知道有时需要自己的专用场景解决方案或框架,但我厌倦了所有这些"伟大的内部框架"来创建Web或桌面应用程序.我错了吗？这些框架真的需要(.NET和Java世界)吗？你能为我提供一些例子或理由说明为什么内部框架/工厂是好的？

编辑:

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

Answer 1

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

解决方案很棘手 - 很难知道是什么激励开发人员,因为每个人都受到不同的事情的激励,但是那些忙于做他们喜欢的事情的开发人员并没有看到这种疾病!

也就是说,经过深思熟虑的框架在正确使用时绝对是一件好事 - 但如果它只在内部使用,那么最好将其视为重新分解和代码重用的扩展,而不是作为框架.

有人患有无聊的开发者框架综合症的一个经典迹象是,当一个框架正在开发以解决一般情况时,还没有针对特定案例的解决方案:

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

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

最后,尽量让开发人员感到无聊(否则他们会遇到各种各样的恶作剧!)