发布要求（R2R）

R2R历程及其问题

从需求到发布（R2R）的过程包括3个主要阶段。 设计，开发和部署（3D）。 当一个阶段结束而下一阶段开始时，没有明显的区别。 所有这三个阶段都需要并行进行，以不断地基于起始种子的想法来获得最终的最终产品。 但是，频繁更改的设计会影响开发阶段，从而导致开发人员感到疲劳，从而导致错误和错误的代码。 另一方面，设计人员需要等待很长时间才能看到其设计工作，因此必须返回并调出设计以进行更正和修改。 这导致思想思路的丧失，从而错过了被遗忘的设计的机会。

从瀑布模型到敏捷方法，已经采取了许多SDLC流程来克服这些问题。 每种方法仍然存在一个或其他主要缺点。 瀑布模型迫使设计人员在开发开始之前就了解所有需求并仔细考虑所有场景。 除非手动测试了工作产品，否则了解所有情况显然不切实际。 敏捷方法试图通过一次设计小块组件来克服这一问题。 但是，这带来了“无远见”的问题。 设计变得过于分散，并且引入了许多重写和重新设计。

总体而言，具有手动编码扩展的特性开发周期并陷入人为错误的情况对产品有害。

需要什么？

真正需要的是将3个主要阶段减少到2个主要阶段 。 设计和部署（2D）。 发展的 需要 ，是偶然和代码很容易地从设计在最短的时间内创建。 敏捷方法仅在设计和编码可以无延迟且无需补偿开发人员和设计人员之间的通信失败的情况下才能发挥作用。 敏捷方法的当前实施被延长到2周的周期，并受开发人员的速度和理解的驱动。 速度越高，对开发人员的了解越好，就可以更轻松地按要求进行设计。

从表面上看，虽然设计和开发似乎是不同的阶段，但实际上它们只是一个阶段。 他们分为两个阶段，要么是因为设计人员不编写代码（技能设置不同），要么是设计人员太有经验，不想花时间编写和调试无脑的代码，并陷入低级编码的棘手问题中。任何新生都可以做。 开发人员本身要么经验不足，要么对域零了解，无法根据要求进行设计。 代码生成解决了此类问题，但是当前实现的代码生成量仅限于POJO或数据库保存，它们可以模拟技术设计师预先考虑或IDE支持的特定模式。

小时的需要是一种工具，让设计的连续增量周期 。 在一个连续的增量周期中，设计人员必须能够设计功能，生成代码，测试功能，调整设计，生成代码，测试功能，如此反复反复，直到最终设计达成共识。 一旦完成设计，就可以生成最终代码并将其推入生产阶段。 PoC它提供了这一点。 为您的设计和UI建模，部署和测试并逐步更改设计以达到最终状态。

怎么做？

所有应用程序的核心是“业务数据”。 例如，在电子商务应用程序中，“产品”是业务数据，“购物车”是业务数据，在订单管理系统中，“订单”是业务数据。 业务数据具有各种状态。 例如，在电子商务应用程序中，“购物车”可以处于“空”，“已添加项目”或“签出”等状态，在OMS系统中，订单可以处于“已下订单”，“已付款”，“在途”等状态。

这些业务数据根据其状态发生不同的业务交易和事件。 在电子商务系统中，当“购物车”数据为空状态时，不会发生“签出”事件，在OMS系统中，“取消订单”是事件，并且可以在对象的任何状态下发生。

PoC它允许您为每个业务数据建模这些业务数据，业务事件和有限状态机。 与状态机一起，PoC它还允许您指定哪个事件以什么状态发生，以及事件发生时必须发生什么。 一旦建模，就可以生成代码。 这将为业务数据和事件生成POJO。 事件以具有JSON通信格式的REST API公开，可以从您的UI调用。

PoC由内部支持lego块体系结构的服务器支持。 这种体系结构适合多个代码段（例如拼图），以形成更大的逻辑来帮助处理请求。 因此，简单POJO的生成和部署在服务器中实现了很多。 服务器可以使用状态机和LEGO块体系结构在这些POJO周围编织许多复杂的功能。

可以使用使用聚合物和材质设计的内置UI设计器来设计UI页面。 然后，这些UI页面可以调用从以前的业务事件模型生成的REST API。

立即尝试！

翻译自: https://www.javacodegeeks.com/2019/02/requirements-release-r2r.html