一个小技巧，让 ABAP OPEN SQL具有自描述效果

ABAP开发人员想必都和图一这种让人摸不着头脑的数据库表字段打过交道。要了解其含义得打开SE11查看字段描述才行。

如果在查看了描述信息后，编写代码时使用AS给这些字段名设置可读性更好的别名，下次自己或他人维护，阅读起来就方便多了。

这个小技巧或者说倡议，出自SAP社区博客:

不用花多大功夫，就能极大提高代码可读性，减轻了将来的维护人员阅读代码的负担。书写可读性良好的代码，也是开发人员职业素养的体现之一。

当然也有一些朋友持反对意见，比如：

个人认为现阶段这样反而不好用。SQL这里是易读了，但是后续处理里面绝大多数时候需要type全局structure创建本地structure变量，赋值的时候，call FM的时候因为字段名不一样都，反而变得不容易处理了。

最近工作重点转移到了SAP Commerce上来，正好有机会把该产品里由Java实现的订单处理框架和我之前长期工作过的，ABAP实现的SAP CRM One Order框架做个比较：基于Spring的Bean替换机制 vs ABAP函数+配置表，两种方式都实现了强大的可扩展性。

SAP Commerce的订单处理框架把订单处理业务按照步骤拆分成一个个细粒度的处理单元，封装到一个个Spring Bean里。模型和其行为之间通过策略模式(Strategy Design Pattern)进行松耦合式的关联。Commerce二次开发人员可以灵活地将定制业务逻辑实现在自开发的Bean里，并将其通过Spring框架注入到Commerce的订单处理框架中，实现订单处理业务的定制效果。

而SAP CRM One Order里一系列维护在配置表里的函数，学习了SAP Commerce之后，我倾向于把它们类比为比SAP Commerce Order Bean更细粒度的处理单元。SAP Commerce里能够注入的Order处理逻辑的粒度是一个端到端的操作，比如SubmitOrderStrategy，CloneAbstractOrderStrategy，CreateOrderFromCartStrategy, SaveAbstractOrderStrategy, 一个Bean就能实现一个端到端的Order操作；而SAP CRM One Order框架配置表里可以灵活配置的ABAP函数，往往需要多个函数组合在一起协同工作才能完成一个上述操作。虽然可配置和替换的粒度不同，但都殊途同归：在不修改SAP标准代码的前提下，给二次开发人员提供一种灵活的增强机制(Extensibility).