首先吐槽：
sap的设计简直就是反人类，当然单纯的从系统维护性上来说。
这样的系统如果诞生在当代，那绝对就是最垃圾的系统。
首先，它并非面向对象，所以当我第一次看他的过程调用的时候，那重复代码不忍直视。
再看，命名规范，全都是大写字母，在加一些数字编号，鬼才能看懂。例如这些:
现代软件工程，都流行敏捷开发，如果都是这种东西的话，那基本上敏捷不了了。
有一些比较佩服的地方：
它后台的数据库是一个强大的关系型数据库，各种主键外键强关联，重点是，这些关联的字段都是用同一个名称，就是说两个表通过一个字段关联的话，那这两个表中这个字段名称一定是一致的，虽然这个字段命名基本上没啥含义。我认为它也不会全都满足三大范式，尤其是第三范式，毕竟很多表中的字段都有二三十个甚至更多，不可能完全避免传递依赖。
庞大的表关联，也就造成了极难维护，所以SAP工程师具有明确的分工，因为根本没有人能够搞懂全部模块。比如：
还有很多和敏捷开发相背离的地方，比如，功能扩展有很多的限制，开发前需要有顾问进行需求评估，而敏捷开发追求积极响应变更，响应用户需求。
同时就发现了一个很普遍的现象，似乎，SAP只管钱，就是FI，CO模块通常都会用，但是别的模块都不会用，很大原因在于别的模块需求太复杂了，SAP不能满足，所以发现很多企业除了SAP以外，还会有MES做生产管理，来替代SAP中的MM（物料管理），PP（生产计划），QM（质量管理）等等，还有CRM（客户关系管理）系统，SRM（供应商管理）系统。
之前我就职的公司中甚至会把PP，QM单独拆分出来，流程越复杂，系统越多，就是现状。
还有公司用OA（办公自动化）系统来做售前工作，比如合同审批、立项等，我感觉类似于SAP的SD模块。
然后就会出现一系列系统集成，也是我接触很多的工作，系统之间互相调用，但是我感觉SAP还是核心，合同系统都需要从SAP取数，或者将数据导入SAP，通过SAP的接口来完成。
刚刚提到SAP中的财务模块比较重要，很多人把它当成财务系统，这也就是为什么别的系统依赖它，比较，财务管理时企业的核心，所有的企业业务都需要记账，这是“国家法律”的要求。
之前接触了一下财务会计的知识，核心就是所谓的借贷记账法，通俗来说就是企业的每一笔业务都有一个专有名词，这个不能改变，这是“法律要求”，比如采购过程会设计固定资产增加或者成本增加，销售过程需要记录收入增加同时存货减少（这就是一增一减，一借一贷，就是借贷记账法），等等。 是不是发现了什么？？ 这种整齐的有规矩的，几乎不需要变动的业务规则，和SAP这种强关联的系统形成了很好的照应，所以SAP适合做财务。
是不是很懵逼：
好了，总结一下：
1.SAP系统很复杂，表关联极强，但是扩展性极差，和我们现代软件工程的敏捷思维想背离。
2.SAP很适合做财务系统，（虽然叫做ERP（企业资源计划）），因为财务规则本来就是固化的，财务系统需要的稳定可靠。
3.现代企业业务越来越复杂，衍生出来各种系统，需求还在不断变革，是一个很大的挑战。
再说一句废话，就是我刚开始写代码的时候，就会吐槽，“搞那么多类干嘛，互相依赖，互相嵌入，互相引用，看都看不懂，我写的话，都写一起，多方便，省的找来找去。”甚至恨不得一个类里面几百行的代码就写完一个程序。
后来会发现，如果那样想的话那真的错了。因为如果一个方法里面几百行代码可能就是弱智。
我还见过，5000行+的存储过程，当时我们boss的原话是，超过5000行就影响性能了，所以5000行以后就差不多截了，醉了。
这样5000行的存储过程有上百个（甚至更多），oracle里有包的概念，这些存储过程就分布在不同的包里面，我每次调试简直痛苦，全都是重复代码。修改的时候最常用的就是ctrl+F 搜索，然后复制粘贴。可怕。
最后这个系统黄了，几百万的项目黄了。
还有数据库视图，一大堆表表关联。 这种奇葩的事情都让我遇到了。基本上这种烂摊子都是叫给新员工去维护的。
最后强调一下，个人认为，
1. 敏捷开发很重要，因为他的出现就是为了适应不断变化的需求。
2.不要采购大量的来自不同供应商的系统，因为系统集成很麻烦，越集成越乱。
3.如果有能力有资金，最好自己开发，或者找大厂商采购成熟的系统以及可以提供完善的服务的那种。
后续，我会写一些敏捷开发的文章，敏捷开发的本质就是代码可维护，易读，易修改。
还有就是设计模式，很难想象一个充斥这个重复代码的系统后期如何维护。
顺便再说一下，看书还是很重要的，虽然我之前一直都是只看视频，找培训机构的，但是培训机构的东西只是入门，书中的东西才能更系统性，而不会落掉一些知识点。但是看书的话需要有一定的编程经历，不然看不懂。