至于程序可维护性的一对设法。关于程序可维护性的一些想法。

SAP系统作为店铺之音讯体系,其生命周期通常是绵绵的,比单个程序员的在职时要抬高得几近。早期实施阶段花大力气开之自定义程序,会付出受铺内或外部的运维团队来保安——不管怎么样,一般不是初的开发者了。即便是在运维阶段,程序的创立者和修改者也常常不是一个口。不同的开发者,其知识底子、技术水平、编码风格难免有所不同,最早创建的次,经过多单盖世的开发者的修改,可能会见换得面目全非,失去可维护性。这时的次第可以说已经接近被死亡…因此,作为序的开发者,我们用让祥和之先后对修改有抵抗力,从而会于后之保护下活的更长久有。

SAP系统作为店铺之信息体系,其生命周期通常是旷日持久的,比单个程序员的在职时一旦增长得差不多。早期实施等花那个劲开之自定义程序,会交给公司内部还是外部的运维团队来保护——不管怎么样,一般不是最初的开发者了。即便是当运维阶段,程序的奠基人和修改者也每每不是一个总人口。不同的开发者,其学问底子、技术水平、编码风格难免有所不同,最早创建的次序,经过多少独盖世的开发者的改,可能会见转移得面目全非,失去可维护性。这时的先后可以说曾八九不离十被死亡…因此,作为次的开发者,我们要被好之次第对修改有抵抗力,从而能以后的保安下活的重新久远有。

当然,抵抗修改的意思,并无是凭妨碍后人修改程序。企业之事情是形成的、人们对需要的明是无休止强化的,因而程序的改动也是必要的。抵抗修改的靶子应该是:在合理的需要变动发生常,尽量吃修改变得好,并减弱多少修改带来的毁伤,从而让程序会承受更频繁的修改。

自然,抵抗修改的意思,并无是因妨碍后人修改程序。企业的事情是形成的、人们对需的接头是无休止深化的,因而程序的改动为是必要的。抵抗修改的靶子应该是:在客观之求变动发生时,尽量给修改变得容易,并减弱多少修改带来的摔,从而为程序能够经受双重累的修改。

本人认为问题的关键在于减少耦合度、理清程序职责的分配,清晰的顺序描述为生重大:

自身当问题之关键在于减少耦合度、理清程序职责的分配,清晰的次第描述为蛮重大:

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

耦合度即模块之间的涉嫌强度。高耦合度的次牵一发而动全身,只称吃需求大安宁的主次。对于形成的ABAP程序来说,降低耦合度可以减去程序修改对任何一些的影响,是比重要之。

单独的解耦工作来或被咱们陷入为解耦而解耦的圈套。了解程序的天职分配好为咱们愈理性地行使技术,并且要程序对修改有双重好之适应性。

单的解耦工作起或吃我们陷入为解耦而解耦的圈套。了解程序的任务分配好被我们越理性地利用技术,并且只要程序对修改有再好之适应性。

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

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

下结合现实的ABAP开发技术来谈谈自己本着她的想法,因为就是基于自己之片段历的来形容,可能不是系圆满的介绍。

下结合现实的ABAP开发技术来讨论自己对其的想法,因为只有是依据自己的片更的来形容,可能不是系到的牵线。

 

 

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

正文链接: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属性)

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负引入了枚举对象,它对于实现程序中的多寡的一致性有充分好之扶,相比常量而言强大许多。在同之场子,可以设想是不是好就此枚举来提高可维护性。

硬编码与配置表

当即两头的原理在以对准先后的修改变为“扩展”,在匪干涉或于少干预程序代码的状态,完成功能的反。如果程序的读者看到了先后中的枚举或者常量,那么他即会知道这些事物的修改会导致什么的震慑。一个吓的命名可以助读者知道她的图。

ABAP
7.51遭到引入了枚举对象,它于落实程序中之数码的一致性有死好之助,相比常量而言强大许多。在一如既往之场合,可以设想是不是可以用枚举来提高可维护性。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的用可以使我们的顺序变得十分活,但究竟是先后的可读性通常不绝好,而且对新手来说吧绝是可怜为难修改的。因此,我建议尽量将她看成基础作用的贯彻,和次中之硬编码、配置表相结合,或者是由此新建子类的方法来实现效益的扩充,并且附以文档,说明程序的扩张方法。尽可能避免给后人直接修改大气运用动态技术之次序。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的运可要我们的次第变得老大灵活,但后果是次的可读性通常不极端好,而且本着新手来说吧断是可怜麻烦修改的。因此,我提议尽量将它们作为基础功能的兑现,和程序中的硬编码、配置表相结合,或者是经过新建子类的措施来贯彻效益的壮大,并且附以文档,说明程序的扩充方法。尽可能避免被儿孙直接改动大气应用动态技术的先后。

中间层

于制以及另外系统联网的接口时,由于各级方面的原由,会时遇到对方要改接口的输入输出方式或者格式的状态。这时候,不是直提供被对方包含业务处理逻辑的接口,而是建立一个外层接口,把本来的接口包装起来,专门为此来回答对方的改,是一个好点子。相似的思绪也可就此当另外经常改变的地方。

中间层

每当做与外系统连接的接口时,由于各地方的原因,会不时遇到对方要改接口的输入输出方式要格式的气象。这时候,不是直接提供于对方包含业务处理逻辑的接口,而是建立一个外层接口,把原来的接口包装起来,专门用来回应对方的改动,是一个吓办法。相似的思路也得据此在其余经常改变的地方。

形容起意义的注释

传言写序不写注释是平等种植非常不好之惯,也生付出规范约束人们:必须使描写注释。注释当然是必备之,但是在实践中,大部分人数的注释水平是匪绝好的,往往针对读书起免至啊正面作用,于是甚至催生了一致栽反叛的、矫枉过正之观:好之次第没有需要注释。

近些年看到的一个杰出的不好的笺注:

*处理数据
PERFORM frm_process_data.

立刻段代码至少犯了3只谬误。

  1. 而坐文章来比,FROM的讳就凡是文章的题目,我们无应有以题目中描写清楚标题是标题。显然,FRM的前缀是无效的,它深受莫了我们什么消息。
  2. “处理多少”似乎是针对性FORM功能的叙说,这部分内容应该置身FORM的定义处,而非是调用位置。在调用位置的诠释,需要写的凡:为什么是FORM需要以此被调用?为什么非是调整用另外一个收押起相似之FROM?
  3. 于诠释中描绘“处理数量”这种肤浅的辞通常有不了什么含义,更不用说FORM名已经是process
    data(处理多少)了。这种重新有害无益。

如此的笺注了多,大概就是是众多总人口反感注释的来头吧。好的笺注需要出现于合理的位置,需要写“为什么”而未是“做了呀”。这尚是很考验写作者对程序的知情的,需要来“同理心”,预见读者的求才可以。

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

 图片 1

设是函数、或者类的讲话,还可描绘专门的文档:

图片 2

写来含义之笺注

传闻写序不写注释是同等栽特别不好之习惯,也出出规范约束人们:必须要写注释。注释当然是必不可少之,但是在实践中,大部分丁之笺注水平是不顶好的,往往对读起未交什么正面作用,于是甚至催生了一样种反叛的、矫枉过正的观点:好的次序尚未需要注释。

近年来来看的一个超人的不得了的注解:

*处理数据
PERFORM frm_process_data.

这段代码至少犯了3单错。

  1. 一经以文章来对待,FROM的名即是文章的标题,我们不应以题中描写清楚标题是标题。显然,FRM的前缀是无济于事的,它让莫了俺们啊消息。
  2. “处理数量”似乎是针对性FORM功能的叙述,这一部分情应在FORM的定义处,而不是调用位置。在调用位置的注释,需要写的凡:为什么这FORM需要以此给调用?为什么不是调动用别样一个看起相似的FROM?
  3. 每当诠释中描写“处理数据”这种轻描淡写的辞通常发生不了呀意思,更不要说FORM名已经是process
    data(处理数量)了。这种还有害无益。

这么的注解了多,大概就是累累丁反感注释的由来吧。好之注解需要出现在情理之中之职务,需要写“为什么”而不是“做了啊”。这还是好考验写作者对先后的明亮的,需要发“同理心”,预见读者的要求才足以。

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

 图片 3

一旦是函数、或者类的口舌,还得形容专门的文档:

图片 4

善用异常

生是单可怜有因此底东西,但是我异常少见到出ABAP开发者用它。我看来的多数序用错误码或者失实标识的法子来处理错误。以己之更来拘禁,错误码在单层的调用关系遭遇是较好用的,但是以差不多层的、复杂的状况下,异常比错误代码要再爱处理和掩护。而且死有着比较好的自家描述能力,这当次的护中是坏有含义的。而过多错误码是一味的魔法数字,只有开发者本人知道凡是什么意思,后续维护的人数在目错误代码时,只能认识及:这里发生只错误…并无明了每个错误代码的涵义。

善用异常

非常是单可怜有因此底东西,但是我死去活来少看出ABAP开发者用它们。我来看的多数次用错误码或者不当标识的方来处理错误。以自我之更来拘禁,错误码在单层的调用关系蒙凡比较好用底,但是以差不多层的、复杂的状态下,异常比错误代码要双重爱处理和保护。而且充分有着较好的自我描述能力,这当程序的保安中凡可怜有含义之。而不少错误码是只的魔法数字,只有开发者本人知道凡是呀意思,后续维护的口在观错误代码时,只能认识及:这里发生只错误…并无亮堂每个错误代码的涵义。

免全局变量

全局变量不好,这是富有开发者的共识。之所以专门还要用出它们来作一个小节,是为自身觉着这个题材实际上普遍还严重。可能坐大部分ABAP二次开发程序还是内容比较少之表格,最常用的ALV报表类(函数)则要求该输入的数额内表必须是全局变量,初入行的开发者通常是自全局变量写于底,而正如简单的程序逻辑也为开发者没有领全局变量带来的麻烦….这种惯性使得众多开发者在之后开相对大型的次序时为会大方采取全局变量。而先后的拥护者通常没有生气要力来分辨全局变量对先后的震慑,从而在改程序时造成了预期之外的结果。此外,不加以释放的全局变量也会见带性能上之负担。所以我当开发者应该经常想是否足以据此有些变量代替全局变量、用价值传递代替引用传递,时时注意避免全局变量带来的难为。 

避免全局变量

全局变量不好,这是装有开发者的共识。之所以专门还要将出她来作一个小节,是以自道这题目实际上普遍还严重。可能因为大部分ABAP二次开发程序还是内容比较少之报表,最常用的ALV报表类(函数)则要求该输入的数目内表必须是全局变量,初入行的开发者通常是于全局变量写于底,而比较简单的程序逻辑也为开发者没有接受全局变量带来的麻烦….这种惯性使得许多开发者在后头开发相对大型的次时为会大方用到全局变量。而先后的跟随者通常没有活力要力来识别全局变量对先后的影响,从而在修改程序时造成了预期之外的结果。此外,不加释放的全局变量也会见带来性能及之承负。所以我觉得开发者应该经常想是否可就此一些变量代替全局变量、用价值传递代替引用传递,时时注意避免全局变量带来的辛苦。 

开源工具

开发人员在工作中可能会见要有些类库,有时人们见面友善写类库。在投入时自己写类库之前,可以预先找是否存在现成的良好开源工具。因为个人的事物或会见坐文档不完备或者人员变更变得无人能够懂,也会为新人比较充分的上成本。而好的开源工具的肥力更强一些,也发出再多同行知道该怎么用。

本,很多总人口当写用OLE生成Excel的次序时会见展开得的包来拍卖麻烦的call
method
of语句。在这个基础及,人们见面形成各自的卷入方式,阅读彼此的OLE程序时,就可能使花点时间来考察对方以包习惯及的薄区别。但是,如果会使XLSX
Workbench随即同一漂亮的开源工具,大家就是得透过了等同的方式生成Excel。它采取起来简单、性能好,并且(在大部分情形下)可以免写维护起来累的OLE代码。

开源工具

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

遵循,很多总人口当写用OLE生成Excel的主次时会见展开得的包来拍卖麻烦的call
method
of语句。在是基础及,人们会形成各自的包方式,阅读彼此的OLE程序时,就可能使花点时间来考察对方以包习惯及的微薄区别。但是,如果会应用XLSX
Workbench即时同一不错的开源工具,大家就是足以经过了等同之办法生成Excel。它采取起来简单、性能优异,并且(在大部分情形下)可以免写维护起来累的OLE代码。

术语表/词汇表

随时间和空中变化的,不仅仅是程序语言和众人的编码技术,业务语言和常见的交流语言其实为会改变。虽然于一个特定的行领域里,总会有些大家还理解的名词,然而在软件之生育过程中,关键用户、业务顾问、从前凡是用户/开发者/业务顾问的经营管理者等人群,毕竟有不同之背景以及经历,对同个词之明也许并无平等(具体的原委或者是繁体的,这里不展开讨论)。因为人们的交流是起家于这么差之根底之上,所以有时即使见面难免产生误解和亚效率的交流。大量底交流时,往往会浪费在澄清一个基础概念上,有时还是因为误会造成相当之损失。这种状况在不同的团组织/部门内的交流被越发常见,也专程有害。

赛效率的交流该因定义作为开头,而无缘定义作为了。为了促成即时同一靶,引入词汇表也许是只便民的法子。如果急需描述、开发文档、测试用例等还使用约定好、定义明确的工作词汇,用户、业务顾问、开发中的牵连就是不见面有歧义,也可免某些人当写代码时胡乱命名。这样一来,就可知再好地控制词的义之一致性与转变。由变化引起的护困难,便通过减轻。

 

未曾哪位单一的点子能维持程序的可维护性,它需依靠各级面的奋力来推动。以上是我的部分感想。也接大家发表自己对可维护性的理念,或者对本文的内容进行指正。

 

术语表/词汇表

随时间和空间别之,不仅仅是程序语言和众人的编码技术,业务语言和普通的交流语言其实为会变动。虽然当一个一定的行当领域里,总会有些大家还晓得之名词,然而在软件的生育过程中,关键用户、业务顾问、从前凡是用户/开发者/业务顾问的企业管理者当人群,毕竟有着不同的背景和经验,对同样个词之懂得也许连无均等(具体的因恐怕是错综复杂的,这里不展开讨论)。因为人们的交流是起家于如此不同的底蕴之上,所以有时候纵然会见难免产生误解和低效率的交流。大量的交流时间,往往会浪费在澄清一个基础概念上,有时甚至以误会造成相当的损失。这种现象在不同的团体/部门间的交流着更常见,也特地有害。

愈效率的交流该以定义作为开,而休以定义作为了。为了兑现即同对象,引入词汇表也许是个便宜的法。如果需要描述、开发文档、测试用例等还下约定好、定义明确的事体词汇,用户、业务顾问、开发中的联系即无见面发生歧义,也得避免某些人在描写代码时胡乱命名。这样一来,就能重新好地控制词的意思之一致性与生成。由变化引起的掩护困难,便由此减轻。

 

从未有过谁单一的计能保障程序的可维护性,它用负各级地方的鼎力来促进。以上是自的片感想。也接大家发表自己对可维护性的见,或者对本文的情开展指正。

 

相关文章

admin

网站地图xml地图