问你们对特定于组织的框架有什么看法？

EN

框架所要做的是以某种方式简化或组织软件开发，这是有益的。不幸的是，除非该框架随着语言的新进步而发展，否则它所提供的这些优势可能会被事态发展所取代。例如，10年前有几个Java框架，但目前得到最广泛接受的是Spring。幸运的是，我记得我听说过春天，心里想，春天永远也不会降临。我错了。

重要的是要了解这个框架打算解决的问题(S)。如果您的组织出于任何原因必须支持10年前的Java安装，并且框架确保新代码将在旧VM上运行--这对公司来说是一个重要的优势。但是，如果旧的(可能是老化的)框架没有任何好处，那么您可能需要进行一些统计。

没有什么比数字更能说明问题了。当你向他们展示你的工作中有多少是因为给框架喂食，而不是花了多少时间去做它的另一种方式。如果你要解决框架中的一个特定部分，如果你改变了它，就会在白天给你另一个x小时的工作效率，那么这可能就不那么政治化了。

框架需要随着时间的推移而发展，就像所有的软件一样。随着一种语言中新特性的出现，需要对框架进行调整以利用它们。今天的春天根本不是最初推出的春天。

我见过这两种情况，有特定框架的组织，也没有其他组织。

拥有一个框架并严格遵守它意味着，至少在理论上，每个程序员都可以在任何项目的任何部分工作。这对一个大型组织来说是一个巨大的优势。显然，至少有两个缺点：( a)在某个时候，它过时了，但是你必须坚持它，因为所有使用它的数百万LOC；( b)你在每一个项目中都使用它，不管它是否合适；所以它是一个金锤子(见反模式)

另一方面，没有框架的组织倾向于为每个项目使用新的工具，因此有一个零碎的代码基，变得很难维护。“哦，2003年的项目需要更新，VB6程序员在哪里? Sh*t，他在2007年离开了！”

不足为奇的是，一些组织设法实现了两个世界中最糟糕的情况:一些项目的内部框架已经过时，其他项目的其他一些工具也不例外。

经常会出现组织框架，因为外部框架“不是在这里发明的”，而且同样频繁地“没有满足我们需求的当前任何东西”(这在J2EE的早期非常常见)。

• 这个明智的组织计划将自己的部分内部框架转移到行业标准(如JPA)上。

和/或

• 这个明智的组织计划改进他们自己的内部框架，以提高开发人员的生产力，同时保持所需要的特殊支持。

和/或

• 一个真正勇敢和开明的组织可能会开放源代码的部分或全部框架，以保持它的最新，相关等。

大多数组织都不这么做，也不这么做。

不足为奇的是，一些组织设法实现了两个世界中最糟糕的情况:一些项目的内部框架已经过时，其他项目的其他一些工具也不例外。

非常贴切:)