在这篇文章中，我将探讨一些程序员是如何强烈认同一种特定的语言的，考虑"程序员"、"程序员"和"开发人员"的含义，随着SAP企业编程环境的变化，这对我们意味着什么

上周，我在往返SAP CodeJam Guetersloh的途中观看了Kevlin Henney的几场演讲。他提出的（许多有趣的）事情之一是，一些程序员强烈认同一种特定的语言。这立刻让我想起了我们的SAP开发者生态圈中的情况，似乎有一些程序员强烈认同ABAP语言。人们甚至可以说，这种强烈的认同是一种排他性的认同。""我是一个ABAP程序员"这句话我听过很多次了，它的意思是"……我不会考虑接受任何其他语言，请给我一个ABAP编程任务来完成"

单语言程序员

对这种类型的单语言程序员的认识不是新的，也不是特别的到SAP或企业界。"我是一个程序员"在很多情况下都会听到。"我是一个ABAP程序员"在我们现在的共同旅程中绝对是相关的，因为我们脚下的世界在变化，并移向云端。

当然，专业化有其优势。任何领域的专家都受到追捧，他们对这一课题的深入了解和密切联系都是非常宝贵的。但是这种专业知识不应该以任何代价出现，这里的代价是对所能达到的目标的限制。

这甚至不是一个人应该对自己的学科领域充满激情的想法——在这种情况下，ABAP-也不是关于一个人是否应该"把工作带回家"，花一些宝贵的空闲时间阅读ABAP语言的主题。（在日常工作之外找到你感兴趣的东西会让工作看起来不那么像工作，但这是一个离题的话题，我们应该改天再谈）。

程序员、程序员、开发人员

这种单一语言程序员的概念从何而来？我认为这与早期的体系结构和软件实践有很大关系。

首先，早期的体系结构和计算基础设施更简单，整个解决方案都是使用单一语言在特定的操作系统上构建的。因此，回顾我们自己的世界，这主要是ABAP，以事务为导向，基于dynpro的设施，从集成机制、后端业务逻辑和前端流的所有内容都是用ABAP编写的，并在一个整体上开发和执行。

SAP R/2 dynpro，来自SAP设计协会的图片

我们在Java世界中看到了一些类似的东西，再回溯到COBOL。故事每次都是一样的。当我们回到那个时代时，让我们考虑一下当今的软件实践。构建解决方案的瀑布式方法在业界占据主导地位。ABAP程序员的角色非常明确，您可以指出流程中ABAP开发开始的部分。把规范变成事务的模块池，变成功能模块和功能组（功能池，啊，美好的回忆），变成报告。

在WRICEF这个词，代表"工作流、报告、接口、转换、增强、表单"的时代，几乎被当作一种货币使用（在某些领域，它仍然是今天，令人沮丧的是），ABAP程序员的角色是将规范转化为可执行代码的人。

这种角色观意味着编程行为被认为是非增值的，也许今天"编码者"这个词就表达了这个意思。在所有的艰苦和创造性的工作完成之后，与用户交谈并设计一套规范，接下来的步骤只是将这种创造性转化为将在屏幕上执行和显示想法的东西。正确的？不完全是。这种想法既错误又有害。但是让我们把这个话题留给另一篇文章吧

如果"程序员"是我们所认为的精通并专注于某一特定语言的人的术语，而"编码者"是这个概念的错误极端，或许我们可以把"开发者"看作是另一个极端，与"编码者"所代表的一切形成对比。

开发是一项创造性的任务，创作者、艺术家在画布上使用的不仅仅是一管红色颜料。也许除了像马克·罗斯科这样的人

无标题1959（来自希格拉姆壁画），马克·罗斯科（来自泰特现代美术馆）

像那些艺术家一样，开发人员的工具集不局限于一种颜色或一支画笔。此外，我们发现自己看到的画布已经发生了巨大的变化，使用单一维度来表达想法、实现设计、产生解决方案的想法无法计算，我思考过今天的风景：云优先，购物领券，由许多移动的部分组成。在当今多平台、多系统、多层次的世界中，开发人员必须不断发展壮大，才能继续为业务问题提供创造性、有效的解决方案。看看许多人每天使用的语言和工具箱就知道了。让我们选择一个我们大多数人至少应该熟悉的场景——在Fiori世界中开发应用程序：ABAP、核心数据服务（CDS）定义和元数据扩展、UI5、XML、JavaScript、级联样式表（CSS）、HTTP。在新的业务应用程序编程模型文档中也有类似的模式，入门教程针对的是当今的开发人员，它在最初的几分钟内引导读者通过一种类似于River数据服务（RDS）、OData协议等的数据定义语言，甚至连眨眼间。