在程序开发的过程中，相同的功能往往有不同的实现方式。对于可以实现同样功能的不同代码，复杂度是用于比较其质量优劣的重要指标。
在本文中，代码复杂度是指代码被理解/修改的难易程度。越容易被理解、修改的代码的复杂度越低；反之其复杂度越高。
复杂度低的代码比复杂度高的代码有更多好处，比如，
从代码“查逻辑”变得简单
可以节省修改的时间
降低在未来引入bug的几率
新人会更容易上手现有代码
帮助整个系统更加“长寿”
ABAP开发是在SAP系统中进行的，而SAP是企业的核心信息系统，其中会包含复杂的业务逻辑，通常由ABAP实现，并需要长期的维护。在这样的工作中，ABAP代码的复杂度对系统维护成本甚至项目的成败有着重要的影响。
在下文中，我会介绍几种有助于最小化代码复杂度的通用思路，并尝试把它们和实际的ABAP开发工作结合起来，帮助理解。
作者水平有限，如果读者发现了任何问题，欢迎评论指出。
本文链接：https://www.cnblogs.com/hhelibeb/p/10871392.html
原创内容，转载请注明
1, 模块化设计两年前，我第一次参与的SAP项目刚完成不久。那时我对自己的技术相当自信，在项目中，我不仅完成了多种类型的功能开发，而且也读完了整个项目的新开发代码。即使对于一些没做过的新的功能需求，我也往往能在不依赖乙方同事的情况下独立查找资料完成。自信满满的我决定换份新工作，并得到了一个面试机会。第一轮面试考察的是一些常用功能的实现和对业务流程的了解程度，如自己预想的那样，我顺利通过。在第二轮面试中，对方问到"对模块化的理解和实践"，这是个出我意料的问题，我努力地思考了一番，却不知道该说什么，于是被客客气气请了出去…
经历了这次失败后的我，不断地思考着模块化设计。如果再次回答这个问题，也许我应该这样回答：
定义模块是系统中独立的、可替代的单元。模块化设计，即是把系统分解为模块的集合。模块的形式多种多样，可以是form、method、function Module、class、或report等。在理想的世界中，每个模块都完全独立于其它模块：开发者在任何模块中工作的时候，都不需要知道有关其它模块的知识。在这种理想状态下，系统复杂度取决于系统中复杂度最高的模块。
当然，实践与理想不同，系统模块间总会多少有些依赖。当一个模块变化时，其它模块可能也需要随之而改变。模块化设计的目标就是最小化模块间的依赖。
为了管理依赖，我们可以把模块看成两部分：接口和实现。
接口包含了全部的在调用该模块时需要的信息。接口只描述模块做什么，但不会包含怎么做。
完成接口所做出的承诺的代码被称为实现。
示例以function module为例，在function module编辑器中看到的function module名，和前6个标签，加上function module文档（如果有），都属于它的接口。而source code中的代码，则属于实现。如下图
进行模块化设计，是减小代码复杂度的第一步。因为，开发者在进行模块内部开发时，只需要关注 当前模块的接口+当前模块的实现+其它相关模块的接口。他只需要关注整个软件系统的一小部分，接触的东西变少，会使理解工作内容的速度大大增加，也会使犯错的机会变小。对于试图理解当前系统的部分功能而不做修改的人，这种设计同样会减轻人们的负担，因为人们通常只需要关注模块们的接口，以此了解程序的功能。
2, 减少异常的影响经验较浅的程序员容易犯的一个错误是，只考虑程序中的正常情况，即所谓的happy path，而没有（足够多地）考虑异常情形。不周全的考虑可以让程序员快速完成功能，但是接下来则会导致测试中的频繁翻车，程序员不得不再对程序进行种种的修补，导致代码整体的复杂度迅速升高。此外，即便是在一开始已经考虑到了各种异常情形，为了处理它们，也会给程序增加一定的复杂度。本节内容的主题是，如何合适地尽量减小由异常情形引起的复杂度。下面介绍具体的三种办法，
从概念上消除异常第一种办法是从概念上消除异常。异常是相对正常而言的，功能的定义可以影响到异常的定义。ABAP SQL有插入语句，代码如下，
INSERT ztable FROM TABLE @lt_something.