这是与语言无关的主题，尽管我将提供Java示例，但这适用于每种语言。
反对使用框架的通常论点是：
- 它非常复杂，我们不需要
- 我们可以创建自己的框架，这对我们会更好
- 我们怀疑他们的质量，不认为他们能胜任
- 我们不想学习另一个框架，核心java应该足够了
- 我们从来没有听说过这些……他们有什么好处？
坏事是你不能和这些人争论。 如果他们碰巧是主管或架构师–这是另一个固定项目。 不，请不要误会我的意思–在很多情况下，最好不要使用这些框架。 但是它们并不是那里的共同项目。 让我讨论以上每个论点
“它非常复杂，我们不需要它” –复杂性确实是框架的问题。 自动打包可能需要一周的时间。 但是复杂性才刚开始，直到团队熟练使用给定的框架。 然后，复杂性保持在固定水平。 我可以从经验中看出这一点–我来到我目前的公司，他们有一个使用spring和hibernate的大型项目。 大约一周后，我可以修复该项目中的所有内容。 因为Spring项目不能变得复杂。 它会变得越来越大，并且具有固定的复杂性。 这与算法复杂性无关，而与结构和配置有关。
这就是“我们可以创建自己的框架对我们更好”的问题。 随着这种复杂性可能会增长到无限。 并非总是如此，但是本土化框架和重新发明轮子常常导致无法维护的项目。
更不用说您的团队只有5到6人，他们必须创造业务价值，而没有时间去编写框架。 与之相比，在开放源代码框架上花费了数千小时，而在这些框架上进行编程并发现各种可能的问题则花费了数百万小时，这使得“我们怀疑它们的质量，认为他们无法做到”这份工作”的论点看起来不合理。 流行框架的质量远远高于普通团队在项目生命周期内所能达到的质量。
但是，确实有些人倾向于另一个方向，即过度设计。 我认为，过度设计是项目可能发生的最糟糕的事情。 而且“我们不想再学习另一个框架，核心Java应该足够了”看起来像是朝着正确方向迈出的一步。 但这是变相的另一件事–能力不足或无法/缺乏学习欲望。 我听说过太多关于Spring过于复杂和过膨胀的抱怨（包括有关stackoverflow的问题），或者说冬眠使您无法控制并且产生了很多问题。 我不会去解释这些说法到底以什么方式错了，但是之所以存在，是因为人们对这些框架的理解不深。 而且看似更简单的方法是删除它们。
另一方面，人们倾向于仅仅因为流行而抛出他们不了解的框架。 然后其他人指责框架。 您可以发现共同的主题–导致问题的不是框架，而是人们不理解的框架。
好吧，这并不意味着所有框架都是好的。 EJB 2不是。 Struts 1不是。 但是，如果您知道框架的真正问题以及如何解决这些问题，您就只能责怪该框架。 加文·金和罗德·约翰逊知道。 其他人使用EJB 2，并且可能比自制一个更糟糕的框架做出了更好的选择。 是的，我知道您是超级建筑师，而您却更好。 如果您愿意，请随时给我链接您的spring / hibernate / etc.-killer。
然后，“反框架主义者”可以大呼“为什么我要学习那里的每个新框架”。 首先-您之所以获得高薪是因为您应该每天学习新事物。 第二–流行的框架推广了最佳实践和概念。 它们使您学习针对典型情况的最佳方法。 还有另一个优势–作为Spring专家，您可以轻松学习任何其他依赖项注入框架。 作为冬眠专家，您可以轻松地学习任何ORM（或实际上-用于将对象映射到非OO数据存储（包括NoSQL）的任何工具）。 换句话说，配置和方法已记录在案，可以轻松检查。 概念对于每个框架都至关重要。
因此，这就涉及到人们选择是否使用给定框架，他们是否可以正确评估优缺点以及对当前项目的适用性的技能和理解。 框架可以简化开发，而不是使其变得更复杂。 他们引入了最初的复杂性，但是好的方法随后将复杂性降低到较低的水平。
参考： Bozho的技术博客上的JCG合作伙伴 Bozho 提出的 那些邪恶框架及其复杂性 。
相关文章 ：
翻译自: https://www.javacodegeeks.com/2011/08/those-evil-frameworks-and-their.html
4902
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
