|
|
原帖由 xiaoniaofly 于 2007-10-22 13:48 发表 
我说SAP的"窗口"是VBA写的是因为IBM分包客户端程序的编程人员有一个是我师兄，他5年前曾经专门给我讲解过他们编的这一部分，无论是使用还是后台编程, 我可以肯定他们当时用的语言是VBA. 也许别的分包公司用的是你说的ABAP语言，或者ABAP本身就是伪VBA. 这个因为我本身是做软件开发的，我们用的也是所谓自己开发的G++语言， 但实际后台支持的就是一般的MFC. 另外我们学校SAP软件在计算机系早几年是免费使用的，包括一部分源代码只要是计算机系的学生经过申请都能看到, 我看到的后台支持程序大部分都是VB写的，还有一部分低端支持程序是C语言的，那些都是很糟以前的程序。另外就我了解到的SAP很多程序是分包出去编写的， 而且编写人员大部分是刚毕业的学生， 模块话不是很好，至少我感兴趣的时候是比较混乱的，软件整合方面我觉得比我经历过的项目都差不少，我曾参加过政府研发项目和西门子的项目.政府项目我只做了一年没什么发言权，只能说在构造算法上确实是高瞻远瞩，反正是政府花钱，大学作为研发来搞的。西门子项目我做了6年，那个项目整合要比SAP整合好很多，一直都是一批人在搞。整个项目在德国到前年全部换代前一共做了差不多30年，数据读取问题也是每年的大问题，算法经常必须要更新，对软件的后续能力要求也很高。 早期的包很多都要一遍一遍推翻重来。就这样在最后阶段我还查出来因为编程人员偷懒造成的逻辑跳跃失误,至于编程上的小失误更是到处都有（这些都是通过调试的程序，用专门的微软检查核心程序的编译器才能查出来）。就我个人经验,一个软件项目在经历长时间运作以后，由于各个分包公司水准不同，产品良莠不齐，势必造成整合问题， SAP在运行这么多年以后，除非它从根本上重新改变构架，我相信它的整合问题只会是越来越严重。
原来是版主姐姐$送花$ 。如果你不是做SAP开发的，解释太具体也没多大意义，也没必要和你的IBM师兄对质:D 。可以给非SAP行业的朋友简单说几句。
1，SAP内部的Dypro几乎都是ABAP写的，绝对不是VBA写的，你可以和你师兄求证。可能你对你师兄的理解有误。可以肯定的说，就算他用的是VBA，那也是他开发（SAP以外的）外围程序，用VBA访问SAP获取数据，然后自己用窗口显示数据。SAP是允许VB和Java访问它的数据的。就是说他的VBA程序不属于SAP标准程序。
2，SAP的最核心程序是C写的，这是对的，目的是为了保证效率。C语言的效率无疑是比ABAP高的。和“很早以前的程序”没有必然联系。今天证券交易所的程序核心仍然是C，因为效率高。
3，SAP的源代码在系统内都是公开的，每个程序员都可以看。因此你所说的“后台支持程序大部分都是VB写的”绝对不可能，因为你就找不到$汗$
4，正因为SAP源代码都是公开的，“编写人员大部分是刚毕业的学生”是不可能的，SAP真这么做是会让别的程序员嘲笑的，因为谁都看得到。
5，你提到“算法经常必须要更新”，正相反，相比IT技术的日新月异。SAP R/3十几年来只是休休补补，并没有大的算法改动。很多数据库都是从R/2继承下来的。我猜你的意思是把SAP以外的数据读入SAP，这个算法是否要更新取决于要读入的数据的格式。读如不同数据当然需要先定义数据格式。
总结一下，我觉得你搞混了一个概念。你把提供SAP咨询的公司和SAP AG搞混了，也就是把多如牛毛的SAP咨询公司开发的程序看成是SAP的标准程序了。SAP咨询公司（比如你师兄所在的IBM的SAP咨询分部）根据客户要求，写程序扩展SAP功能，但是这些程序不属于SAP标准程序。这个服务也不是SAP AG的分包，而是客户直接委托咨询公司开发的，当然很多咨询公司使用刚毕业的大学生，水准参差不齐。但是这和SAP的标准程序无关。执行这些咨询的程序可能效率很差，因为程序员水平不够，这是完全可能的，我就见过一个程序，做两个百万级别的数据表嵌套循环，需要执行3个小时，实际上完全不必要，不使用循环，10分钟左右就可以完成。SAP的标准程序还是比较健壮的，不过这是个大问题，不再细说。说这么多只是希望其他朋友不要对SAP AG产生误解。SAP要是如你想象那么差，完全不可能占有如此高的市场份额。
有志进入SAP领域的朋友加油！
[ 本帖最后由 adgjl 于 2007-10-23 00:15 编辑 ] |
|
简体中文
繁體中文
English
Deutsch
发表于 2007-10-22 23:03