Java EE 的更敏捷替代方案

Question

简而言之，我正在尝试找到一个用于 Web 应用程序开发的流程/技术堆栈，它易于/快速/灵活地制作原型，但具有通往强大生产平台的清晰升级路径。

对于下面冗长的描述，我深表歉意，但问题在于技术和流程之间，我找不到任何简单/简短的方式来表达它。是的，我读过“主观好，主观不好”的文章。

目前我们使用的 Java EE 具有所有优点（敏捷、持续集成、问题跟踪、单元测试、hibernate/spring/stripes/jquery 堆栈...）。我们还使用灵活的项目定义/分析过程，与 GUI 模型（对 Balsamiq Mockups 的赞誉）创建和后来的 HTML 静态页面原型并行的特征收集。在开发过程中，我们会经常进行中间构建并进行客户评论。因此，一旦我们进入测试阶段，90% 的功能就达到了目标，所需要的只是一些错误修复和最终的健壮性抛光。

对于我们的传统客户（例如银行和制药业）而言，上述流程/技术堆栈就像是一种魅力。

不过，最近我们正在为互联网初创公司进行开发。在这种情况下，过程是完全不同的。我们从一些基本模型开始，然后制作第一个非常原始的原型（大量静态页面 + 一些涵盖核心场景的基本功能）。然后我们开始开发完整的应用程序。

这里是关键一步！ 当应用程序公开时，营销/业务人员会收到来自早期鸟类的反馈，观察竞争，他们得出结论并想要更改应用程序。 很多！ 但此时我们不再处于原型模式，我们有一个非常健壮、生产质量的 Java EE 应用程序，其中内置了数百个单元测试。我们可以改进它，但它肯定既不容易也不敏捷。

1) 在流程方面，我们尝试使用所有可用的可视化和正式工具来确定规范，但徒劳无功；在市场说话之前，没有人能够修复规范。

2) 我们尝试了更“灵活”的环境，例如 RubyOnRails 和 PHP。

2.a) 就生产级质量而言，与 Java EE 相比，这些似乎还差一些（是的，我知道一些最重要的服务/应用程序是用 PHP 编写的）

2.b) 如果我们以“灵活”的方式使用它们，它们非常适合进行原型设计，但我们获得的代码很难提高到生产质量。

2.c) 如果我们实施所有最佳实践（分层、单元测试......），复杂性将与我们已经拥有的标准 Java EE 的复杂性相当。

3) 应用上线后，它必须经过完善和稳健，因此无法选择易于制作的原型。

4) 如果我们提出做一次性原型，客户拒绝将其视为一次性原型，并要求将其提高到生产质量（不愿意支付从头开始的开发费用）。

因此，基本上，我们将“质量”（预期结构、稳健性）放在流程中太早了，因为它是不需要的，而且它阻碍了变革和灵活性。

有什么想法吗？

Answer 1

变得灵活。

说真的，您还需要审视自己和团队，而不仅仅是“技术堆栈”。

很多人都站在你现在的位置上，只要迈出一大步，采用“灵活”的替代方案。

你会惊讶于你可以产生的力量。我们都知道，权力伴随着责任，所以不仅仅是知道如何使用工具。远不止这些。

可能您不需要替代方案，您只需要深入挖掘当前的问题并解决它们。这不就是我们应该做的吗？提高我们的工艺？

哦，不只是互联网初创公司，你提到的银行和制药公司也在转向灵活的替代方案。