适当使用Grails，Rails等？

Question

我们公司现在（全球）有一个Excel电子表格，可以捕获有关每个国家/地区技术使用情况的各种信息。问题在于它会消失，变化，但它们永远不会显而易见，而且经常会发生冲突 - 然后我们必须将它们粉碎在一起。对我来说，工作簿只不过是一个等待写入的垃圾输入/垃圾输出类型的应用程序。

在一家拥有足够人员和知识致力于企业项目的公司中，出于某种原因，敏捷和语言/框架（如Rails，Grails等）不受欢迎。也就是说，我不禁认为这几乎完全适合需要，因为脚手架功能非常简单，只需要几次查找即捕获原始字段（即预定义的类别）。我认为这将被认为是对这些框架的恰当使用。

有没有人在通常大规模，严厉的企业环境中成功地使用这些类型的快速和脏应用程序？有关向非技术管理人员传达这种需要/适当性的任何提示吗？

Answer 1

在严格的组织中实现这一目标的唯一方法是让它工作并进行演示 - 无需批准。管理层很难对已完成的项目说“不”。

Answer 2

我为一家非常大的公司工作已经编写了许多基于Rails的实用程序应用程序（以及对一些较大的Rails项目的贡献）。也就是说，最大的担忧不是应用程序的质量，而是当你离开或受到公共汽车撞击时谁将支持/维护它。

恕我直言，企业组织的主要担忧 - 特别是如果应用程序对其核心业务变得更加重要 - 是如何支持它。如果它不适合它的小盒子支持技术，它不太可能发生。

公司过去曾多次被这些公司所困扰。在引进新技术时要谨慎。

因此，如果您可以鼓励更多人在您的小组（或您公司的其他地方）学习Ruby / Rails，那么您可以为此做好准备。否则，伤心地说，你可能会更好过在SharePoint上实现的东西： - （

Answer 3

如果您已经拥有Java基础架构，那么创建Grails应用程序几乎不需要额外的IT支持和维护。支持和维护成本和工作量应与Java应用程序相同（即在Tomcat上运行Grails应用程序，使用相同的JVM，使用相同的诊断/分析工具等）。

根据我的经验，较大的IT组织在其尚未加入工具链时更难以支持Ruby，因为它是一种新语言，新的部署环境，并且需要大量的支持和维护。

我会开发一个最小的可行产品，然后与IT中的某个人交朋友，他们可以帮助您将其部署到临时或生产环境中。然后让一些用户加入其中并像测试Beta产品一样进行测试。之后，向更多的观众开放。

正如其他人所说，宽恕许可，但要明智地对IT组织产生影响。