关于程序可维护性的有的想法

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(处理数据)了。这种又有害无益。

然的诠释了多,大概就是是诸多丁反感注释的原委吧。好之笺注需要出现在合理的职务,需要写“为什么”而不是“做了哟”。这还是格外考验写作者对先后的知道的,需要出“同理心”,预见读者的急需才得以。

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

 房地产公司 1

假使是函数、或者类的话语,还好描绘专门的文档:

房地产公司 2

擅异常

酷是单可怜有因此底东西,但是本人死少看有ABAP开发者用其。我见状的绝大多数顺序采取错误码或者失实标识的方式来处理错误。以自家之经历来拘禁,错误码在单层的调用关系被凡较好用底,但是以差不多重合的、复杂的景下,异常比错误代码要重复易处理以及护卫。而且好有着比较好之自描述能力,这当程序的维护中凡特别有含义之。而多错误码是单独的魔法数字,只有开发者本人知道是啊意思,后续维护的口在探望错误代码时,只能认识及:这里有个错误…并无掌握每个错误代码的涵义。

免全局变量

全局变量不好,这是具备开发者的共识。之所以专门还要将出它来作为一个小节,是盖自身道这题目实际上普遍还严重。可能因大部分ABAP二次开发程序都是内容比较少的表,最常用之ALV报表类(函数)则要求其输入的多寡内表必须是全局变量,初入行的开发者通常是由全局变量写起的,而比简单的程序逻辑也深受开发者没有经受全局变量带来的麻烦….这种惯性使得众多开发者在其后出相对大型的先后时为会见大量运用全局变量。而先后的支持者通常没有活力要能力来识别全局变量对程序的震慑,从而以窜程序时造成了预想之外的结果。此外,不加释放的全局变量也会见带来性能及的背。所以我觉着开发者应该时时想是否可以用部分变量代替全局变量、用价传递代替引用传递,时时在意避免全局变量带来的劳动。 

开源工具

开发人员在工作中可能会见需要部分类库,有时人们见面融洽写类库。在投入时自己写类库之前,可以先行找找是否是现成的精粹开源工具。因为个人的事物可能会见坐文档不齐全或者人员改变变得管人会知晓,也会见让新人比较充分的念成本。而好之开源工具的精力更强一些,也生再多同行知道该怎么用。

按部就班,很多人口于描绘以OLE生成Excel的次第时会开展定的卷入来处理麻烦的call
method
of语句。在此基础及,人们见面形成各自的包裹方式,阅读彼此的OLE程序时,就可能使花点时间来考察对方以包装习惯及的细微区别。但是,如果能够动用XLSX
Workbench眼看无异于良之开源工具,大家就是可以通过了同之法子生成Excel。它以起来简单、性能优良,并且(在大多数情下)可以避免写维护起来麻烦的OLE代码。

术语表/词汇表

随时间和空中变化的,不仅仅是程序语言和人们的编码技术,业务语言及平常的交流语言其实也会改变。虽然以一个一定的行领域里,总会有些大家都亮之名词,然而以软件的产过程被,关键用户、业务顾问、从前凡用户房地产公司/开发者/业务顾问的企业管理者当人群,毕竟有着不同之背景与经验,对同样个词的喻也许并无一致(具体的案由或许是繁体的,这里不展开讨论)。因为人们的交流是立以如此不同的根底之上,所以有时候纵然见面难免产生误解和没有效率的交流。大量之交流时,往往会浪费在澄清一个基础概念上,有时还因误会造成一定之损失。这种现象在不同的集体/部门内的交流被愈发常见,也专程有害。

高效率的交流该坐定义作为开,而不因为定义作为完结。为了兑现就无异于靶,引入词汇表也许是独有利的艺术。如果要求描述、开发文档、测试用例等还使约定好、定义明确的政工词汇,用户、业务顾问、开发中的关联即无见面时有发生歧义,也可免某些人以形容代码时胡乱命名。这样一来,就能够还好地控制词的义之一致性与转移。由变化引起的保障困难,便由此减轻。

 

从未孰单一的道能够保持程序的可维护性,它用依靠各级地方的卖力来促进。以上是自之组成部分感想。也接大家发表自己对可维护性的理念,或者对本文的始末展开指正。

 

相关文章