Java EE 的更敏捷替代方案
简而言之，我正在尝试寻找一种用于 Web 应用程序开发的流程/技术堆栈，该堆栈易于/快速/灵活地进行原型设计，但具有通往强大生产平台的清晰升级路径。
我对下面的冗长描述表示歉意，但问题出在技术和流程之间，我找不到任何简单/简短的方式来表达它。是的，我读过“好主观，坏主观”文章。
目前，我们正在使用 Java EE 以及各种功能（敏捷、持续集成、问题跟踪、单元测试、hibernate/spring/stripes/jquery 堆栈...）。我们还使用灵活的项目定义/分析过程，与 GUI 模型（感谢 Balsamiq 模型）创建和后来的 HTML 静态页面原型并行进行功能收集。在开发过程中，我们经常根据客户评论进行中间构建。因此，一旦我们进入测试阶段，功能就达到了 90% 的目标，所需要的只是一些错误修复和最终的稳健性完善。
对于我们的传统客户（即银行和制药公司）来说，上述流程/技术堆栈就像一个魅力。
不过最近，我们正在为互联网初创公司进行开发。在这种情况下，过程就完全不同了。我们从一些基本的模型开始，然后制作第一个非常原始的原型（大量静态页面+一些覆盖核心场景的基本功能）。然后我们开始开发完整的应用程序。
这里是关键一步！当应用程序公开时，营销/业务人员会收到早起鸟儿的反馈，观察竞争，他们得出结论并想要更改应用程序。 很多！ 但此时我们不再处于原型模式，我们有一个强大的、生产质量的 Java EE 应用程序，内置了数百个单元测试。我们可以改进它，但它肯定既不简单也不敏捷。
1）在流程方面，我们尝试使用所有可用的视觉和形式工具来确定规范，但徒劳无功；在市场说话之前，没有人能够确定规格。
2）我们尝试了更“灵活”的环境，例如 RubyOnRails 和 PHP。
2.a) 对于生产级质量，与 Java EE 相比，这些似乎仍然有点弱（是的，我知道一些最重要的服务/应用程序是用 PHP 编写的）
2.b) 如果我们在“灵活”的方式，它们非常适合原型设计，但随后我们获得的代码很难达到生产质量。
2.c) 如果我们实现所有最佳实践（分层、单元测试...），复杂性将与我们已有的标准 Java EE 的复杂性相当。
3）当应用程序上线时，它必须经过精心设计和健壮，因此不能选择易于制作的原型。
4）如果我们建议制作一个一次性原型，客户拒绝将其视为一次性产品，并要求将其提高到生产质量（不愿意支付从头开始开发的费用）。
所以基本上，我们在流程中过早地放置了“质量”（预期的结构、稳健性），而此时并不需要它，而且它仍然妨碍了变化和灵活性。
有什么想法吗？
In a nutshell, I'm trying to find a process/technology stack for web applications development, that is easy/fast/flexible to prototype, but has a clear upgrade path to a robust production platform.
I apologize for a lengthy description below, but the problem is between the tech and the process and I can't find any easy/short way to express it. And yes I read "Good Subjective, Bad Subjective" article.
Currently we are using Java EE with all the blows and whistles (agile, continuous integration, issue tracking, unit testing, hibernate/spring/stripes/jquery stack ...). We also use a flexible project definition/analysis process with feature gathering in parallel with GUI mockups (kudos to Balsamiq Mockups) creation and later HTML static pages prototype. During the development, we do frequent intermediate builds with client reviews. So once we get to the testing phase the functionality is 90% on target and all is needed is some bugfixing and the final robustness polish.
For our traditional clients ie banks and pharmaceuticals, the above process/technology stack works like a charm.
Lately though, we are developing for the internet startups. In this case the process is quite different. We start with some basic mockups, then the first very raw prototype is made (lots of static pages + some basic functionality to cover the core scenarios). Then we start developing the full blown application.
Critical step here! When the application goes public, the marketing/business guys receive the feedback from the early birds, observe competition, they make their conclusions and want to change the application. A LOT!
But at this point we are not in the prototype mode any more, we have a nice robust, production quality Java EE application with hundreds of unit test built in. We can evolve it, but it certainly is neither easy nor agile.
1) On the process side, we tried to nail down the spec with all the visual and formal tools available, but in vain; nobody is able to fix the spec before the market speaks.
2) We tried more "flexible" environments like RubyOnRails and PHP.
2.a) For the production grade quality, those still seem a little bit week compared to Java EE (yes, I know that some of the most important services/apps are written in PHP)
2.b) If we use them in "flexible" way, they are great for prototyping, but then we obtain the code that is difficult to rise to the production quality.
2.c) If we implement all the best practices (layering, unit testing ...), the complexity becomes comparable to the standard Java EE's complexity that we already have.
3) When the app goes live, it has to be polished and robust, so an easy to make prototype is no option.
4) If we propose to make a throwaway prototype, the client refuses to see it as a throwaway and asks to bring it to production quality (not willing to pay the start-from-scratch development).
So basically, we are putting "quality" (intending structure, robustness) too early in the process, when it is not needed and when it stays in the way of change and flexibility.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
变得灵活。
说真的，你还需要看看自己和团队，而不仅仅是“技术栈”。
许多人都站在你现在的位置，只要迈出一步，采取“灵活”的替代方案即可。
你会对你能产生的力量感到惊讶。我们都知道，权力伴随着责任，所以它不仅仅是知道如何使用工具。它的意义远不止于此。
也许你不需要其他选择，你只需要深入挖掘当前的麻烦并解决它们。这不是我们应该做的吗？提高我们的工艺水平？
哦，不仅仅是互联网初创企业，你提到的银行和制药公司也在转向灵活的替代方案。
Become flexible.
Seriously, you also need to look at yourself and the team, rather than just the 'technology stack'.
Many have stood where you are, just take the leap and take on a 'flexible' alternative.
You'll be surprised with the power you can yield. We all know that with power comes responsibility so its not just knowing about how to use a tool. Its a lot more than just that.
It may be that you don't need an alternative, you just need to dig deep into your current troubles and fix them. Isn't that what we're supposed to do? Improve our craftsmanship?
Oh, its not just the internet start ups, the banks and pharmaceuticals you mention are also moving to the flexible alternatives.