如何应对公司内部框架和SW工厂? [英] How to deal with internal company frameworks and SW factories?

问题描述

根据我自己的经验和朋友的经验，我看到很多公司都有一些奇怪的想法来开发自己的框架和软件工厂(为你构建应用程序的骨架).这些想法通常基于这样的信念，即自己的框架将比其他任何可用的框架都要好得多.如何处理这些想法以及如何解释它并不总是好方法?

Based on my own experience and on experience of my friends I see that many companies have some strange ideas to develop their own frameworks and SW factories (builds skeleton of application for you). These ideas are usually based on belief that own framework will be much better than anything else available. How to deal with such ideas and how to explain that it is not always good way to go?

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

Why I think internal frameworks / factories are not good:

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

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

Why I think companies are doing this:

• 傲慢与利己主义——公司里有人相信他可以做得更好.
• 无知 - 无视现有的框架/解决方案以及只有好的框架才能存活足够长的时间才能流行的事实.忽略用户组和 Internet 上已有的信息.
• 管理失败和无能 - 不了解该决定的影响(尤其是长期影响).基于错误信息的决定.没有软件开发背景的管理人员.

我知道有时需要针对特定​​场景使用自己的解决方案或框架，但我厌倦了所有这些用于创建 Web 或桌面应用程序的出色的内部框架".我错了吗?真的需要这些框架(.NET 和 Java 世界)吗?您能否提供一些示例或理由说明为什么拥有内部框架/工厂是件好事?

I understand that sometimes own solution or framework for specialized scenario is needed but I'm tired with all these "great internal frameworks" for creating web or desktop applications. Am I wrong? Are these frameworks really needed (.NET and Java world)? Can you provide me some example or reason why it is good to have internal framework / factory?

感谢您的回答，但我期待一些关于如何以开发人员(换工作除外)而不是经理的身份处理问题的建议.

Thanks for answers but I expected some advice how to deal with a problem as a developer (except changing a job) not as a manager.

推荐答案

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

In my experience the most common cause of excess frameworks is... bored developers! Uninspired developers find that developing frameworks to solve their problems is much more fun than actually solving those problems - the end result is frameworks that suffer from all of the above (because of course the developer only did the fun bits), and possibly don't even solve the actual problem (because the goal was to have fun, not to solve the problem).

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

The solution is tricky - its difficult to know what it is that motivates developers as everyone is motivated by different things, however motivated developers who are busy doing things that they enjoy don't see to suffer from this ailment!

也就是说，如果使用得当，经过深思熟虑的框架绝对是好东西 - 但是，如果它只在内部使用，那么最好将其视为 re 的扩展分解和代码重用，而不是作为一个框架.

That said, well thought out frameworks when properly used are definitely a good thing - However if its only going to be used internally then it might be better to instead think of it as an extension to re factoring and code re-use rather than as a framework.

一个典型的迹象表明某人患有无聊的开发者框架综合症，当开发一个框架来解决一般情况时当还没有针对特定情况的解决方案时:

A classic sign that someone is suffering from bored developer framework syndrome is when a framework is being developed to solve the general case when there isn't yet a solution for the specific case:

• 在至少解决一个具体案例之前，您如何知道如何解决一般案例?
• 在您必须解决一般情况几次之前，您只是猜测甚至需要一个框架.

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

The second case of course leads to the worst sort of framework - the mammoth generic framework that is only ever used once, to solve a problem which is far simpler than the framework itself.

相反，将这些类型的框架更多地视为广泛重构"的练习 - 如果生成框架是作为根据需要对公共代码进行分组和整理的一种方式，那么框架的大小和复杂性将动态增长 -在您开始制作框架之前已经解决了问题也很好，因为这意味着您已经是框架需要做的任何事情的专家.

Instead consider these sorts of frameworks more as an exercise in "extensive refactoring" - if the framework is produced as a way of grouping and tidying common code on an as-needed basis then the framework will grow in size and complexity dynamically - having already solved the problem before you start producing frameworks is nice too as it means you are already experts in whatever it is the framework needs to do.

最后，尽量不让开发人员感到无聊(否则他们会搞各种恶作剧！)

Finally, try to keep developers from being bored (they get up to all sorts of mischief otherwise!)

这篇关于如何应对公司内部框架和SW工厂?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！