这个博客与技术性更强的博客有点不同，因为它本质上描述了一个"如果"的场景，我认为这个场景永远不会实现。不管怎样，怎么查看大数据，我相信这个想法足够有趣，可以"写下来"讨论。

它是按照围绕单元测试的所有博客文章的顺序出现的，包括我自己的，在这里我们讨论了作为单元测试要求的模块化设计，以及一般的好代码。我们还得出结论，大多数人不这么做，很难强迫改变。强制是关键的想法，如果您作为SAP经理真的想强制您的团队这么做呢？

我疯狂的投球？让您的一些开发人员使用没有SAP\u APPL或任何其他功能模块的开发人员版本。如果你感兴趣的话，请继续阅读。

本周我分析了一些关于EWM和Fiori（用于仓库操作）的发展，遇到了三种情况：

当业务流程相同时，大数据开发，无法利用为WM（而不是EWM）设计的仓库操作的Fiori套件；Seing直接调用EWM功能模块的网关服务；无法访问Fiori实例，因为它未连接到公司VPN。我不得不在本地"停靠"的ABAP AS和云平台webide上创建测试。（非常感谢Nabi Zamani）

我查看了现有的代码，总体来说它是好代码（特别是在Fiori方面），但是没有关注可重用性，因为Fiori/网关完全是硬连接到EWM的。如果我曾经想用这个与正常的WM我将不得不重写一切，

我知道网关给你一些模型生成工具，你可以使用ABAP字典结构和功能模块创建实体和实体集。不要。如果你想有一点点机会进行模块化设计，就不要使用它们。

你的数据模型将与特定的模块相关联，包括数据元素；该模型是围绕特定模块的工作方式而设计的，而不是针对业务需求。它扼杀了模块化设计，因为您的存储库层（API调用）应该绑定到前端。

称我为老式，但我喜欢编写自己的OData服务代码，而且它有助于向odatav4的转换（相信我，当SAPUI5完全兼容时，您会希望转换到v4）。

那么，如果您的开发人员版本没有SAP\u APPL或EWM，会发生什么呢？您不能使用功能模块或数据元素（Win！）。我使用了"字符串"和诸如集合和哈希映射之类的通用对象，因此没有任何东西与特定的功能模块（如EWM）相关联。

在我的机器上没有EWM的第二个影响是我无法创建存储库层。没有要调用的数据库，没有EWM BAPI。那么这迫使我做什么呢？使用一个接口来抽象我所有的API/DB调用，并创建一个mock类，这样我就可以运行代码了。

这个mock类当然需要创建测试数据，我可以重用这些数据进行单元测试。通过强制自己为所有DB/API代码创建一个独立的类，我使代码可测试。

在这个模型中，您可以将存储库层视为一个插件。当我在接口级别抽象业务逻辑时，我可以为EWM编写一个存储库类，为WM编写另一个存储库类（这个插件只能在使用EWM/WM的实例中开发）。

将它与ABAPGit绑定，在ABAPGit中，您有一个通用应用程序的存储库，其他的用于插件，并且您有一个高度可扩展的开发环境。

在Fiori（前端）前端这意味着您可以轻松地将您的业务模型与EWM分离开来，从而加快您的流程。你甚至可以让一个Fiori/Gateway的家伙来做你的业务逻辑，让更传统的ababer来创建插件。即使你想使用后端服务器，云主机服务器，个人免费云服务器，你也有mock提供的测试数据。

Fiori/Gateway团队可以更快地与使用SAP Web IDE mocking服务器的业务用户进行交互，从而快速迭代，而无需经常需要EWM（insert other module）顾问。

在云平台方面，我认为这是关键吗？我对此持怀疑态度。一方面，它确实加快了进程，如果您使用的是云平台门户，那么与Fiori Launchpad的集成非常好。如果您不使用门户，sapwebide将加快这个过程，因为网关自动模拟和元数据同步（这对于快速迭代很重要）。

当然这也有缺点（这就是为什么没有人真正这么做）。我能想到几个：

保持开发人员机器的更新；开发人员ABAP上仍然没有HANA；有一个足够大的团队将你的开发者分成两组；有一个值得模块化的预算。改变开发者的心态。你可以通过代码指导和代码检查来完成所有这些，并且不需要额外的工作就可以强制执行这些操作。

最后一个是最重要的。大多数公司都有荒谬的编码准则，比如当类是多余的时，强制您使用ZCL\来命名类，但是对于实际的编码实践却没有相应的准则。只有模块化代码比经历所有这些麻烦要简单得多。

最后一句话，我的开发负责人可能会读到，什么是云，EWM"plugin"仍然需要"someone"来编写。真正的模块化设计。