花痴流口水颜文字_如何因流口水或任何其他工具/框架/库而失败

花痴流口水颜文字

我在会议上最喜欢的是关于某人没有做或实施某事的报告，因为他们是最好的学习来源。 Java Zone 2011上的Know IT的C. Dannevig的“ 如何用Drools失败”（挪威语）就是其中之一。 我想总结一下他们学到的知识，并根据自己的痛苦经验将其扩展到一般情况下引入工具，框架或库。

他们决定从自己的本地规则实现切换到Drools规则管理系统（又名JBoss Rules）v.4，以将所有规则代码集中在一个地方，以使事情变得更简单易懂，并缩短产品上市时间。添加规则时，无需重新部署。 但是，由于以下原因，Drools造成的负担比帮助大得多：

• 为学习Drools提供的时间和资源太少，由于基于声明式编程和规则匹配（ 某些背景 ）而导致学习曲线比较陡峭，这与常规的命令式/ OO程序员完全不同。
• Drools对开发和操作的支持不佳–仅适用于Eclipse的IDE，调试困难，失败时无堆栈跟踪。
• 他们的领域模型与Drools不太吻合，需要大量的努力才能使其被规则使用。
• 用户习惯了当前的系统并对此感到满意，并希望保持面向他们的部分，例如规则管理UI而不是Drools自己的UI，从而降低了软件的价值（同时增加了整体复杂性，我们可以添加）。

最后，他们删除了Drools并重构了代码，以仅使用简单的旧Java将所有规则都集中到一个地方–这对他们来说效果很好。

从工具，框架和库的介绍中学到的教训

虽然Know IT团队遇到了一些Drools特有的问题，但他们的经验与许多其他情况（当引入工具，框架或库来解决某些任务和问题，但事实证明更多的问题）有很多共通之处。他们自己。 我们可以从这些失败中学到什么，以预期的成本实现预期的收益？ （实际上，这样的举措通常被认为是成功的，即使收益比计划的要小，成本（通常是相当大的）也比计划的要大。）

在引入[重量级]工具或框架之前，请三思而后行或三或四次。 尤其是在需要全新的思维或工作方式时。 您不能使用简单的旧Java / Groovy / WhateverYouGot以更简单的方式解决它吗？ 使用开箱即用的解决方案听起来非常简单，尤其是在销售会议上，但实际上通常非常复杂。 正如里奇·希基（Rich Hickey）最近在演讲中很好地解释的那样 ，我们应该努力降低复杂性，而不是优先考虑相对和误导性的简便性（在“易于接近，理解，使用”的意义上）。 我敢肯定，我们中的许多人都已经经历过“我将为您做所有的事情，让您开心和放松”工具变成主要的障碍和痛苦的源泉-至少我在Websphere ESB 6.0中经历过。 （它需要重型工具，只有少数工具可以掌握，实际上是1.0版，而且无论如何，必须手动实现许多承诺的功能等）。

我们永远不会忘记，引入新的库，框架或工具要付出代价，而这通常是我们经常低估的。 成本具有多个方面：

• 复杂性–复杂性是IT项目中最糟糕的事情，您确定增加它会有所收获吗？ 基础设施，内部结构的复杂性……。
• 能力–学习曲线（对于Drools来说是相当高的水平），有多少人知道这一点以及可以在遇到麻烦时提供帮助的专家
• 开发–该工具是否以某种方式阻碍了开发，测试或调试，例如f.ex。 是通过使其变慢，变得更加困难，还是需要特殊的工具（尤其是在没有工具的情况下）？ （想想J2EE x Spring）
• 操作–对应用程序在生产中的可观察性（如果不提供失败的堆栈跟踪信息，对Drools而言），对故障排除，性能，部署过程有什么影响？
• 缺陷和局限性–每个工具都有缺陷和局限性，尽管它们似乎已经成熟（它们已经有Drools的第4版）； 您通常会在很晚时遇到限制，很难甚至不可能立即发现它们-并且很难估计作者做出的灵活性（如果解决方案是开源的，尤其糟糕）
• 长寿–该工具会在1、5、10年内出现吗？ 向后兼容性又如何支持向更高版本的迁移呢？ （我工作的公司决定在一年后停止在其基础架构中支持Websphere ESB，而我们不得不从中迁移–这浪费了资源！）
• 依赖关系–它具有什么依赖关系，它们是否与应用程序或其环境中的其他内容冲突？ 十年后会怎样？

而且我确定我错过了某些尺寸。 因此请注意，使用某些东西的实际成本可能比您的最初估算高出几倍。

另一个教训是，对开发的支持是任何工具，框架，库的关键特征。 它引入的任何减慢都必须至少乘以106，因为所有这些减慢都会散布到团队和项目的整个生命周期中。 我经历了太多次了–需要在所有其他更改之后重新部署的框架，需要我们手动通过向导进入要测试的页面的应用程序，这会导致IDE缓慢执行测试。

最后要记住的是，您应该知道工具和背后的设计是否与您的业务领域和流程（包括开发流程本身）完全吻合。 如果存在不匹配，您将需要为它们付费-OOP与RDBMS的区别（您不知道有人在听到“ ORM”之后开始发抖吗？）。

结论

请注意，所有事情都有其成本，请务必加以考虑，并当心我们在估计收益和成本时都过于乐观的趋势（可能雇用经验丰富的悲观主义者或任命恶魔的拥护者）。 始终首先考虑使用现有工具，但听起来可能很无聊。 我并不是说我们永远都不要引入新内容，而只是想让您对此更加谨慎。 我最近关注了一些关于“企业”应用程序如何不必要地获得以及自身对库和框架造成的伤害的讨论，我同意它们，我们应该更加小心并尝试使事情保持简单。 上面的工具成本维度可能希望帮助您发现新工具成本中不太明显的部分。

参考： 如何从我们的JCG合作伙伴 Jakub Holy的 Drools或任何其他工具/框架/库中失败 ，请访问“ Holy Java”博客 。

相关文章 ：

• 框架使开发人员愚蠢吗？
• 开源Java库和框架–优点和缺点
• 那些邪恶的框架及其复杂性
• Java教程和Android教程列表

翻译自: https://www.javacodegeeks.com/2011/11/how-to-fail-with-drools-or-any-other.html

花痴流口水颜文字