关于程序可维护性的片设法

SAP系统作为企业之音体系,其生命周期通常是马拉松的,比单个程序员的在职时一旦丰富得几近。早期实施等花大劲开之自定义程序,会付出于柜内或外部的运维团队来保安——不管怎么样,一般不是头的开发者了。即便是以运维阶段,程序的创建者和修改者也不时不是一个口。不同之开发者,其学问基础、技术水平、编码风格难免有所不同,最早创建的程序,经过若干单盖世的开发者的改动,可能会见变换得面目全非,失去可维护性。这时的先后可以说就八九不离十被死亡…因此,作为次的开发者,我们需要让好之次第对修改有抵抗力,从而能够当后人的护下活的再老有。

理所当然,抵抗修改的意思,并无是负妨碍后人修改程序。企业的作业是形成的、人们对需求的接头是络绎不绝加剧的,因而程序的修改也是必要的。抵抗修改的对象应该是:在情理之中之需求变动发生时,尽量让修改变得易,并减弱多少修改带来的毁伤,从而为程序能够经受双重累底改。

自我觉着问题之关键在于减少耦合度、理清程序职责的分红,清晰的次第描述为很重点:

耦合度即模块之间的涉及强度。高耦合度的主次牵一发而动全身,只称吃需要非常平安的次序。对于形成的ABAP程序来说,降低耦合度可以减程序修改对其他一些的熏陶,是比较根本之。

光的解耦工作来或让咱陷入为解耦而解耦的牢笼。了解程序的职责分配好为咱更是理性地采取技术,并且只要程序对修改有双重好之适应性。

先后的描述包含命名、程序结构这种“自我描述”,也囊括程序注释、技术文档,以及需要文档。这恐怕是最最容易改善的一个上面。

下结合现实的ABAP开发技术来谈谈自己本着它的想法,因为只是因自己之片段历的来写,可能无是系圆满的牵线。

 

正文链接:http://www.cnblogs.com/hhelibeb/p/7891401.html

原创内容,转载请注明出处

CDS视图

SQL是为广大程序员发腻烦的事物。过去,由于内表的在,大家照面因此简易的SQL取出较多之数,然后在内表中处理它们,计算主要在应用服务器中开展。但当HANA推出后,SAP提出了code
pushdown模式,鼓励用再多的做事付出数据库服务器来开,也为ABAP的Open
SQL提供了又强大的功能。可见日后的SQL将变得渐渐复杂。在纷繁的SQL上展开改动或会见耗时比多、测试困难,有时也会无小心造成性能问题。ABAP
CDS视图的引入可以比较好的许诺针对这些题目。如果头的开发者能够运用CDS抽象出平安的数据模型,把经几SQL处理的数码作已存在的数码来拘禁,那么尽管能够简化ABAP程序中之SQL复杂度,同时为暴跌后续的开发者和作业顾问的心智负担与维系成本。

(想同一纪念我们是勿是隔三差五说这种冗长的语:XX属性是经过关联A表和B表,使她的局、业务编号和移动序号相等,在撤销标识不齐’X’等状况下,获取她的某某同性质,再到性对许交之分红表C,获取有效期内的记录——看了并掌握这么长一段话之后,也许交流的双方曾经注意着理解XX属性究竟怎样获得,忘记了投机当考虑的另东西。如果这种关联逻辑在信用社的需中凡祥和之还不时出现的,我们完全可以吗其去一个“新歌词”,即CDS视图。基于CDS视图,之后的联系方式可改为:到视图ZCDSXX中,根据取消标识不抵’X’,获取我们用的XX属性)

硬编码与配置表

立马二者的原理在以本着先后的修改变为“扩展”,在不干预或比少干预程序代码的情状,完成功能的改观。如果程序的读者看到了先后中之枚举或者常量,那么他就算会明白这些东西的修改会导致什么的熏陶。一个吓的命名可以拉读者知道它们的作用。

ABAP
7.51挨引入了枚举对象,它对于实现程序中的数额的一致性有好好之援,相比常量而言强大许多。在平的场子,可以考虑是否可就此枚举来提高可维护性。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的利用好使我们的程序变得死去活来灵活,但究竟是次的可读性通常不顶好,而且针对新手来说也绝对是特别不便修改的。因此,我提议尽量把它作为基础意义的兑现,和顺序中的硬编码、配置表相结合,或者是经过新建子类的艺术来落实效益的恢宏,并且附以文档,说明程序的扩大方法。尽可能避免吃后直接改动大气使用动态技术的程序。

中间层

在炮制和任何系统衔接的接口时,由于每地方的因由,会常常遇到对方要改接口的输入输出方式或者格式的情景。这时候,不是一直提供于对方包含业务处理逻辑的接口,而是建立一个外层接口,把原的接口包装起来,专门为此来回复对方的改,是一个吓方法。相似的思路为得以就此当另外经常转移的地方。

形容来含义之诠释

传说写序不写注释是一模一样栽特别糟糕的习惯,也发生开规范约束人们:必须要描绘注释。注释当然是必备之,但是在实践中,大部分总人口之注解水平是不太好之,往往对读起免交什么正面作用,于是甚至催生了一如既往种植反叛的、矫枉过正的理念:好的先后尚未需要注释。

近来看的一个天下无双的坏的诠释:

*处理数据
PERFORM frm_process_data.

立即段代码至少犯了3个错误。

  1. 一经盖文章来对比,FROM的名字就凡是文章的题目,我们无应该以题目中描写清楚标题是标题。显然,FRM的前缀是不行的,它给无了咱们啊信息。
  2. “处理数据”似乎是对FORM功能的描述,这有内容应当置身FORM的定义处,而休是调用位置。在调用位置的诠释,需要写的凡:为什么这个FORM需要以这边叫调用?为什么非是调动用外一个看起相似之FROM?
  3. 于诠释中形容“处理数据”这种肤浅的辞通常发生不了啊意思,更毫不说FORM名已经是process
    data(处理数据)了。这种又有害无益。

这么的注解了多,大概就是无数人口反感注释的由吧。好的诠释需要出现于客观之职,需要写“为什么”而无是“做了呀”。这还是特别考验写作者对先后的知情的,需要发出“同理心”,预见读者的要求才得。

善编辑器为自动生成的注释模板,比如:

 亚洲必赢bwin696.com 1

假定是函数、或者类的语句,还足以写专门的文档:

亚洲必赢bwin696.com 2

善于异常

良是独十分有因此底东西,但是自死少看出ABAP开发者用它。我见到的多数主次用错误码或者不当标识的措施来处理错误。以自身的阅历来拘禁,错误码在单层的调用关系着是比好用底,但是于差不多重叠的、复杂的状况下,异常比错误代码要双重便于处理与维护。而且非常有着比较好的自己描述能力,这当次的保安着是特别有含义之。而不少错误码是只有的魔法数字,只有开发者本人知道凡是啊意思,后续维护的丁于探望错误代码时,只能认识及:这里产生个错误…并无知情每个错误代码的涵义。

免全局变量

全局变量不好,这是颇具开发者的共识。之所以专门还要以出其来作为一个小节,是以自以为这题目莫过于普遍还严重。可能坐大部分ABAP二次开发程序都是内容比较少的表格,最常用之ALV报表类(函数)则要求其输入的数量内表必须是全局变量,初入行的开发者通常是自全局变量写起的,而正如简单的程序逻辑也被开发者没有收受全局变量带来的麻烦….这种惯性使得广大开发者在后头开销相对大型的先后时为会见大方施用全局变量。而先后的跟随者通常没有生命力还是能力来分辨全局变量对先后的影响,从而在改程序时造成了预期之外的结果。此外,不加以释放的全局变量也会见带性能上之负。所以自己觉着开发者应该经常想是否可就此一些变量代替全局变量、用价值传递代替引用传递,时时在意避免全局变量带来的难为。 

开源工具

开发人员在工作中可能会见待一些类库,有时人们会协调写类库。在投入时间自己写类库之前,可以先行找是否是现成的地道开源工具。因为个人的事物可能会见坐文档不齐全或者人员改变变得管人会清楚,也会给新人比较充分的念成本。而好之开源工具的精力更强一些,也闹还多同行知道该怎么用。

遵循,很多人口于描绘用OLE生成Excel的程序时见面展开得之卷入来拍卖麻烦的call
method
of语句。在此基础及,人们会形成各自的包装方式,阅读彼此的OLE程序时,就可能只要花点时间来观察对方在卷入习惯及之轻区别。但是,如果能以XLSX
Workbench即同地道之开源工具,大家就足以经了一样的办法生成Excel。它采用起来大概、性能优异,并且(在多数景下)可以避写维护起来累的OLE代码。

术语表/词汇表

随时间和空间别的,不仅仅是程序语言和人们的编码技术,业务语言与普通的交流语言其实也会转移。虽然于一个特定的本行领域里,总会有些大家都了解的名词,然而以软件之生产过程被,关键用户、业务顾问、从前凡用户/开发者/业务顾问的决策者当人群,毕竟有不同之背景与经历,对相同个词的晓也许并无一致(具体的由来恐怕是纵横交错的,这里不展开讨论)。因为人们的交流是确立在这样不同之根基之上,所以有时候就算会难免产生误解和没有效率的交流。大量的交流时,往往会浪费在澄清一个基础概念上,有时还是因为误会造成相当的损失。这种景象在不同之组织/部门中的交流中逾常见,也专程有害。

大效率的交流应该坐定义作为开头,而不因为定义作为完结。为了兑现即无异目标,引入词汇表也许是个有利于之点子。如果需要描述、开发文档、测试用例等都应用约定好、定义明确的政工词汇,用户、业务顾问、开发中的联系就是未会见有歧义,也堪避某些人于描绘代码时胡乱命名。这样一来,就会还好地控制词的意思之一致性与转移。由变化引起的保障困难,便通过减轻。

 

从没哪位单一的方式能够保持程序的可维护性,它需靠各级地方的极力来促进。以上是自的片感想。也接大家发表自己对可维护性的意见,或者对本文的情节展开指正。

 

相关文章