SAP系统作为企业的信息系统，其生命周期通常是漫长的，比单个程序员的在职时间要长得多。早期实施阶段花大力气开发的自定义程序，通常会托付给企业内部或外部的运维团队来维护——不管怎么样，一般不是最初的开发者了。即便是在运维阶段，程序的创建者与修改者也常常不是一个人。不同的开发者，其知识基础、技术水平、编码风格难免有所不同，最早创建的程序，经过若干个独一无二的开发者的修改，可能会变得面目全非，失去可维护性，这时的程序可以说接近于死亡...因此，作为程序的开发者，我们需要让自己的程序对修改有抵抗力，从而能在后人的维护下活的更久一些。
当然，抵抗修改的意思，并不是指妨碍后人修改程序。企业的业务是多变的、人们对需求的理解是不断加深的，因而程序的修改也是必要的。抵抗修改的目标应当是：在合理的需求变动发生时，尽量让修改变得容易，并减小修改带来的破坏，从而让程序能承受更多次的修改。
我认为问题的关键在于减少耦合度、理清程序职责的分配，清晰的程序描述也很重要。
耦合度即模块之间的关联强度。高耦合度的程序牵一发而动全身，只适合于需求十分稳定的程序。对于多变的ABAP程序来说，降低耦合度可以减少程序修改对其它部分的影响，是比较重要的。
单纯的解耦工作有可能让我们陷入为解耦而解耦的陷阱。了解程序的职责分配可以让我们更加理性地运用技术，并且使程序对修改有更好的适应性。
程序的描述包含命名、程序结构这种“自我描述”，也包括程序注释、技术文档，以及需求文档。这可能是最容易改善的一个方面。
下面结合具体的ABAP开发技术来谈谈我对它们的想法，因为只是根据自己的一些经验的来写，可能不是系统全面的介绍。
本文链接：
原创内容，转载请注明出处
CDS视图SQL是让很多程序员的头痛的东西。过去，由于内表的存在，大家会用简单的SQL取出较多的数据，然后在内表中处理它们。但在S4之后，SAP鼓励将更多的工作交给数据库服务器来做。可见日后的SQL将变得日益复杂，在复杂的SQL上进行修改可能会耗时较多、测试困难、不小心造成性能问题。视图的引入可以较好的应对这一问题。如果早期的开发者能够利用CDS抽象出稳定的数据模型，把经过若干SQL处理的数据当作已存在的数据来看，那么就能简化ABAP程序中的SQL复杂度，同时也降低后续的开发者和业务顾问的心智负担和沟通成本。
（想一想我们是不是经常说这种冗长的话：XX属性是通过关联A表和B表，使它们的公司、业务编号和移动序号相等，在取消标识不等于'X'等情况下，获取它的某一属性，再到属性对应到的分配表C，获取有效期内的记录。看完并理解这么长一段话之后，也许交流的双方已经忘记了自己在思考的其它东西。如果这种关联逻辑在公司的需求中是稳定的甚至常常出现的，我们完全可以为它造一个“新词”，即CDS视图。基于CDS视图，之后的沟通方式可以变为：到视图ZCDSXX中，根据取消标识不等于'X'，获取我们需要的XX属性）
硬编码与配置表这二者的原理在于将对程序的修改变为“扩展”，在不干涉或较少干涉程序代码的情况，完成功能的变更。
动态技术动态技术是双刃剑，Field Symbol和RTTS的使用可以使我们的程序变得十分灵活，但这样的程序的可读性通常不太好，而且对新手来说也绝对是很难修改的。因此，我建议尽量把它作为基础功能的实现，和配置表结合、或者是通过新建子类的方式来实现功能的扩展。尽可能避免让后人直接维护大量使用动态技术的程序。
中间层在制作与其它系统对接的接口时，由于各方面的原因，会不时遇到对方希望变更接口的输入输出方式或者格式的情况。这时候，不是直接提供给对方包含业务处理逻辑的接口，而是建立一个外层接口，把原有的接口包装起来，专门用来应对对方的修改，是一个好办法。
写有意义的注释据说写程序不写注释是一种很糟糕的习惯，也有开发规范约束人们：必须要写注释。注释当然是必要的，但是在实践中，大部分人的注释水平是不太好的，往往对阅读起不到什么正面作用，于是甚至催生了一种完全相反的、矫枉过正的观点：好的程序从来不需要注释。
最近见到的一个典型的不好的注释：
*处理数据 PERFORM frm_process_data.