我们这些从事SAP游戏几年的人会记得面向对象ABAP被认为是异国情调的那些日子。十、十五年前，大多数ABAP开发人员都是在ABAP（通常是COBOL）中专门使用过程编程的，在SAP世界中，只有少数年轻的开发人员是在Java和其他面向对象编程语言中长大的，对他们来说，编程中的面向对象的概念是很自然的。

经理和团队领导通常比他们团队成员的平均水平要有至少五年的经验，因此，在管理者中，以前接触过面向对象编程的人的比例甚至比一般开发人员的比例还要小。结果如何？当面对"我们是否应该采用面向对象的开发"的问题时，在大多数团队中，大约70%的团队成员反对它，大多数管理者也跟随大多数人，决定反对面向对象的开发。其中一个主要驱动因素是客户项目的开发不是在一个孤岛上进行的。

很少有从头开始的开发，大多数ABAP开发都是为了扩展SAP标准模块中的业务流程。标准模块中发生了什么？开发的新模块遵循现代的、面向对象的范例，购物返利平台，因为这些模块往往是由来自Java等背景的新雇开发人员构建的。随着多年来业务功能的增强，旧的模块慢慢地、逐步地现代化，新的开发在经典模块中形成了越来越大的面向对象的孤岛。底层的NetWeaver平台发展很快，淘返利，因为SAP最精通技术的开发人员都在使用它，所以它使用了最现代的编程技术；这会导致软件堆栈中更高级别的业务应用程序在使用技术堆栈提供的功能时发生变化。一些较旧的模块经历了更剧烈的更新，导致了破坏性的变化，在程序ABAP上只剩下很少的孤岛。

因此，缓慢但稳定的ABAP对象接管了大部分SAP开发。诚然，即使在S/4hana世界中，物联网协议，对于严格过程化的开发人员来说，物联网门锁，仍然有一些利基和舒适区，但是随着方法调用和对象实例化在与SAP标准代码库交互时变得越来越不可避免，这些利基和舒适区变得越来越小。ABAP对象现在已经完全成为主流。

开发团队刚开始对ABAP对象感到满意，下一个范例编程范例即将到来：CDS视图。（别误会，它们并没有取代ABAP对象，但它们是SAP业务应用程序核心的一项新技术，无论是否面向对象。）

在SAP最近的发展中，尤其是在s/4 HANA领域，CDS视图非常重要。带注释的CDS视图是构建任何新内容的核心技术：

OData服务（取代Gateway Builder）Fiori应用程序（将Fiori屏幕设计从Web IDE移动到UI注释）业务对象和持久性（来自CDS视图的BOPF对象）分析（分析引擎的数据提供程序和查询）企业搜索（也从CDS视图生成并集成到Fiori搜索中）通过SADL和BOPF在CDS视图上的Web Dynpro/FPM应用程序授权（通过DCL）

矛盾的是，CDS视图甚至对通过兼容性视图构建重构应用程序与旧程序的兼容性至关重要，兼容性视图取代了一些用来保存冗余数据的透明表。

我经常指导那些希望学习新技术的开发团队。那些已经进行了采用新技术的决策过程并且管理层已经批准了聘请外部教练的费用的团队对采用新技术非常热情和开放。

当然，许多团队还没有达到这一点：他们还不知道SAP的编程模式在s/4 HANA上发生了多大的变化，并期望他们能够很好地与ECC 6.0的技能和知识相处。团队经理还没有意识到他们需要在团队中培养新的技能，因为一切看起来都和以前一样。

当定制者和开发人员通过事务SE16查看他们认为是透明的表时，他们会感到非常舒服（尽管当他们通过ABAP插入一个记录时，他们确实会感到恼火，并且它不会出现在SE16或他们随后的OpenSQL SELECT尝试中，因为两者都被重定向到CDS兼容性视图，而不是访问插入了记录的数据库表）。许多团队都在否认。

当面对许多新技术的挑战时，闭上眼睛否认处理技术的相关性或紧迫性是很有诱惑力的。

当有新技术，但你不想处理它时，这些是一些简单的方法来转移它（并证明你的否认）：

"我们不需要这个，我们可以用我们知道的技术来实现我们的需求。""我们的开发人员不知道这一点，没有人能给他们提供指导；我们不应该强迫他们使用他们不知道或不需要的技术。""我们不能维护它：即使一些开发人员能够并且想要使用它，我们也不应该让他们使用，因为维护团队将无法理解代码并修复任何错误。"

这样的态度会让他们从何而来？十年、十五年前落后的队伍是从哪里来的？

他们创造了比其他团队更难维护的遗留代码10年。在过去的几年中，他们发现越来越难以将扩展与SAP标准代码连接起来。多年来，他们一直无法使用SAP标准框架，而这些标准框架如今都需要很好的面向对象知识（至少效率不高）。不完全理解的工具带来了不必要的复杂性；我发现仍在与面向对象作斗争的开发人员创建了最混乱、最难以理解的代码。