作者孙亮
前言
首先说一句，在HANA上开发程序也需要效率优化。至于原因，下一篇再谈。
程序设计来源于业务需求，程序优化不但离不开业务，而且业务优化绝对是第一步！
带来多少效率上的提升——这也因情况而异，我只是说明程序效率优化应该遵循的步骤)
我的ABAP程序效率优化系列，共分三部分：
业务层面的优化(全文字，但都是干货)
代码(内容比较多，可能需要多篇)
标准程序优化后的代码分享
背景
企业实施SAP系统初期，业务数据量小，系统功能启用的相对较少，ABAP程序的运行速度还都是闪电般的快。
逐渐深化，启用的功能越来越多，业务数据量越来越大，用户对系统的理解也日益深刻，对系统的开发需求也变的更多……这时候，如果ABAP程序结构设计的不好，程序执行效率就非常堪忧了。
策略
首先我们回顾一下在项目中程序开发的工作步骤，大概都是这样的——
需求产生
业务顾问分析需求
用户确认需求
业务顾问根据需求进行功能设计
开发顾问进行功能开发和基本测试
业务顾问测试
用户测试
需求完成
（红色部分是本篇要重点说明的步骤）
对于SAP的标准功能开发，甚至是其他软件的功能开发，大致上也是遵循这个工作流程的。
所有的功能都是以业务需求为基础的(即便业务需求是潜在需求，功能设计也是以假想需求为基础)。所以功能都是离不开需求的，在进行程序效率优化时，我们首先要进行的就是业务层面的优化。
几个例子谈谈原因：
例1：
已经有一个开发好的报表，是查询销售订单、生产订单及其相关的成本、收入等信息，之前的查询条件包括销售组织、工厂、物料、销售订单、生产订单等字段。
增加一个WBS字段的查询条件和展示字段。然后业务顾问把需求直接转移到开发顾问(像传话筒一样)，开发顾问在代码中SQL语句的查询条件中加一行简单的条件。
之后，用户根据WBS查询时，一条数据都要执行好半天。
原因分析：
灾难式的结果。
换了一种模式去查询，用户是希望通过限定WBS取满足条件的数据。而这需要开发顾问根据不同的查询条件输入情况来进行代码优化，可是开发顾问对各模块业务上的逻辑可能并不足够熟悉(足够熟悉是业务顾问的职责)……
应对策略：
业务顾问：决不能当需求的传话筒，对用户提出的需求，首先要做好这一步——“业务顾问分析需求”。比如对于同一个报表需求，可能要根据不同的查询条件，进行有差别的查询设计，而不是纯粹的把查询条件罗列出来那么简单。
开发顾问：面对业务顾问提出的类似更改需求，不妨多问几个问题，深入的了解变更原因，根据用户的真实需求去做适合的更改。
采购订单时，系统中有ME2L、ME2M、ME2N、ME2J等多种方式，就是为了满足不同的查询条件，以更高的效率让用户得到更符合需求的查询结果)
例2：
项目、项目总成本、项目总收入、项目下的产订单、产品、生产成本、项目下的销售订单、客户、销售订单收入。用户要求在一个报表中展示，并且能汇总统计所有项目的成本和收入。
业务顾问拿到这个需求后，如果一点也不分析，直接转给开发，并且要求做到一个普通的ALV中，这实在是难为开发顾问了。即便是做出来，也肯定是没办法让用户愉快的使用的。而且如果在这个基础上再频繁变更需求，最后的结果肯定是谁也看不懂的代码，以及越来越差的性能体验！
(注意黑色字体：用户提出的是在一个报表中，业务顾问粗略的设计完，传递给开发顾问的时候，要求的是明确的报表类型：ALV，普通的ALV。)
原因分析：
这个报表中，前面三个字段是项目维度，中间三个字段是生产订单维度，后面三个订单是销售订单维度。
不在一个维度上的数据，能放在一个普通的ALV里吗？很明显不能，这种报表，业务顾问只要稍微分析一下，尝试用Excel做个样表，就能发现问题了。
应对策略：
业务顾问：决不能当需求的传话筒（重复上面的策略）。面对用户的报表需求，一定要自己尝试做个样表，验证一下用户需求和自己的逻辑。上面举的这个例子，维度区别很明显。还有很多维度比较隐晦的例子，但是经过设计样表的过程之后，就能暴露出来了。
开发顾问：普通的ALV确实不能实现这样的需求，但是ALV TREE还是勉强可以的。但也仅限于勉强。因为在该例子中，销售订单和生产订单同属于项目维度的子维度，可以在ALV树中作为项目节点的子节点。一般情况下，生产订单维度可以作为销售订单维度的子维度。这样可以做一个项目->销售订单->生产订单维度的树状报表。
但是还有两个问题：
1、这样的报表是用户想要的吗？
2、如果生产订单不关联销售订单呢？
所以，问题又回归到业务顾问和用户的需求分析上。
例3：
产品毛利率。为了计算毛利率，需要知道产品的销售收入、原材料的发货成本。
销售收入，在销售模块底表中可以轻松获取。
原材料，业务顾问给出的方案是，根据产品递归反推BOM(BOM有多层)，直至找到原材料的物料号为止。
历尽千辛万苦完成程序开发后，却一个多小时执行不出结果，因为反推BOM频繁取数据库、以及大量的递归循环的计算过程实在是太耗时了。
电缆产品的原材料只有“铜”和“铝”两个物料号，且只能为其中一个。然后我建议在物料主数据上找一个闲置的字段填原材料，但业务顾问解释，因为种种原因不允许更改物料的标准界面或使用物料的其他字段。
之后，我提出了我的解决方案：
自定义表，维护产品的原材料属性
存量的销售订单，梳理其销售的产品，确定其原材料属性，作为期初数据维护到自定义表中
增量的销售订单上的产品数据，检测其是否维护了原材料属性。若有没维护的则提示维护，若都维护了则记录下增量日期。
而回过头来看，如果我们针对频繁取数据库和递归耗时的ABAP代码进行优化，在这样一个业务层面有设计缺陷的功能上进行单纯的代码优化，又能得到什么结果？
原因分析：
方案做的太、太、太死板。开始的方案设计做不好，再多的优化都是徒劳。基础不对，努力白费！
应对策略：
系统是死的，人是活的，方案更应该是活的。
更不是系统标准功能掌握的滚瓜烂熟，就可以给客户出一个好方案。
”，还是需要用心去做。如果性能比较差，就分析性能差在哪里，想办法用“简单粗暴、直奔主题”的方式解决性能瓶颈。
总结
我们项目中遇到的程序性能问题，在业务层面的表现，大致有以下几种：
1、报表查询维度多，不同的查询维度是完全不同的查询路径
如果大量的查询逻辑和处理代码都是不同的，就应该设计成不同的查询报表。否则将带来极大的运维成本
2、报表展示维度杂乱，用户希望在一个普通ALV中展示，导致运算处理逻辑混乱、低效
需求不规范，一般情况下一张普通的报表就应该只有一个维度，不同维度的应该用多个报表或者树状报表展示
3、业务逻辑复杂，取数过程繁琐，造成大量的性能问题
可以根据具体需求，通过增强、自定义表等方式，在不同的业务数据间建立桥梁，简化业务逻辑，简化取数过程。
其实以上三种都有一个共同的处理思路——即，大道至简！
需求转化为功能设计。这是一项由业务顾问主导，开发顾问积极参与并提出建议的工作。它需要业务顾问多掌握一些程序设计的理念，也需要团队所有人都对用户需求更多一些业务理解，然后对该拆分的需求进行拆分，对该合并的需求进行合并，对用户不合理的需求进行引导和优化。
总之，只有整个团队的紧密配合和互相支持，才能在满足用户需求的基础上做出好的功能设计，这是做出好的开发功能的第一步，也是最重要的一步！
之所以说这一步最重要，还是那句话：基础不对，努力白费！
