注:本人身为SAP咨询顾问,故以下以SAP开发语言ABAP作为例子,其他语言雷同。
在SAP领域,做开发的人很多,会ABAP的也不少,但真心懂ABAP,懂开发的人却不多。很多人从事开发行业,只是单纯为了开发而开发,为了写代码而写代码。只要能够实现功能,哪怕里面埋了很多雷挖了很多坑也无关紧要,甚至BUG百出。SAP系统最注重的是代码的质量以及运行高效率和简洁,否则一旦程序有问题,影响的并不是程序本身,而会影响到实际企业生产,甚至一定程度上影响到决策层的判断。跟SAP其他模块一样,ABAP没个大几年的累积经验是无法成为大神级别的,除非是天生天赋异禀。因此会点ABAP语法和开发并没有什么了不起,跟其他诸如.net、Java和PHP等语言一样,培训一段时间就能够上手了,但真的要做到把控需求,功能可扩展延展性就难了。也印证了一句话:会ABAP的不稀奇,懂ABAP才难求;会业务模块的不稀奇,即会业务又懂开发才万金难求!
以下列举几项,简要说说会开发和懂开发的区别:
一、更新错误问题
会开发的人:循环一百次,每次暂停一秒后再Insert表,直到成功为止,如果100次了还失败,那就忽略!所以一旦出现这样的情况,程序就会卡死;
懂开发的人:Try一下,捕获消息号和文本抛出,然后RollBack。但如果是无关紧要的表(如日志表),直接就忽略掉;
如下图神奇的代码:
二、多重逻辑判断问题
会开发的人:IF能写多少就写多少,哪怕功能里面都是重复的逻辑;
懂开发的人:采用ABAP的动态语法,将重复的功能整合在一起,区别就在动态语法判断上;
如下图代码:
三、SAP增强的写法
需要说明的是SAP增强是对系统标准功能和逻辑的一种延伸和更改,需要非常的慎重,同时最好有参数表来做开关控制,输出的消息也得有长文本做描述;
会开发的人:找到一个增强就兴奋不已,然后直接写代码,不考虑任何扩展和开关控制,也是直接Message出来消息,很难追踪;
懂开发的人:不仅做了参数控制,同时还会做事务代码或程序名的判断,至于Message则在SE91里面做消息号新建引用,方便维护和追踪!
如下图神奇的代码:(代码里还有很明显的错误,如果是修改采购订单,则会一直报错误,提示费用申请单已经存在)
四、前后逻辑不一致的问题
会开发的人:想到哪里就写到哪里,不用判断上下文的逻辑衔接;
懂开发的人:逻辑严谨性很强,做到前后数据和逻辑一致;
如下图神奇的代码:
以上程序运行的结果就变成了(金额和单价扩大一万倍):
五、SAP接口模式之争
会开发的人:认为Webservice是万能统一的,所以不管第三方系统是什么平台和语言,一律用Webservice来做接口,更要命的是所有接口都共用一个出口地址。并且认为RFC不安全不稳定;
针对接口的开发,不管是输入还是输出,一律用行类型来做多笔记录的传输。无视SAP系统警告说会降低接口的性能;
懂开发的人:除非第三方平台是上古时代开发的或者语言非常老旧,否则尽量能用RFC就用RFC,并且善用Table页签和“例外”的功能;
如下图神奇的代码:
又比如输出结构:
针对这种处理方式,SAP系统会毫不留情得给出这样的警告:
六、统一数据源问题
会开发的人:针对用户的需求,来一个写一个功能,哪怕报表逻辑都是类似的,于是写得多了难免会发现同样的数值往往在不同的地方不一致;
懂开发的人:针对用户的需求,凡是功能类似的都做成一个可重复使用的接口或函数,所有需要用到的地方都调用它取值,统一数据源;
这里没图!
七、注释问题
相信每个开发人员都会遇到看前人的代码,然后又没有任何注释的那种绝望感!
会开发的人:根本不知道啥叫注释,也重来不会注释;
懂开发的人:在非常重要的地方会加入业务需求的说明,以及每一行重要代码的设置说明;
如下图神奇的代码(谁能知道这个是什么鬼?)
八、导入模板是啥样的?
这个或许可以说是用户体验问题,但在IT眼里看来,这分明就是懂不懂开发的问题!
会开发的人:做好批导程序,就扔在那爱谁谁,一段时间之后连自己都不知道导入模板应该是啥样的,是TXT文本导入还是Excel导入,只能继续看程序;
懂开发的人:在批导的画面做一个按钮可以下载模板;
如下图(相信所有人看到下图都会一脸懵逼):
以上大概列举了我在做项目过程中所遇到的主要的问题,还有很多很多开发相关的事故,都是那些只会写代码而不懂系统逻辑的新手写的。比如基本的数据存在性校验、比如数据读取错误、基本的除数不能为0的判断、针对 FOR ALL ENTRIES IN 不做存在性检查、使用 BINARY SEARCH不做排序等,从来不懂什么叫测试。遇到这样的事故,有时候会哭笑不得,要给IT增加不少的负担。也只能感叹一句,会开发简单,懂开发难,懂业务又懂开发,简直万金难求!