有关程序可维护性的局部想方设法,关于程序可维护性的片段设法

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中引入了枚举对象,它对于落实程序中的数据的一致性有很好的提携,相比较常量而言强大许多。在平等的场馆,可以设想是否足以用枚举来提高可维护性。

动态技术

动态技术是双刃剑,FieldSymbol和RTTS的应用可以使大家的次第变得可怜灵活,但结局是程序的可读性平日不太好,而且对新手来说也相对是很难修改的。由此,我指出尽量把它看做基础效能的贯彻,和次序中的硬编码、配置表相结合,或者是由此新建子类的主意来落实效益的扩大,并且附以文档,表明程序的恢弘方法。尽可能制止让后代间接修改大气施用动态技术的主次。

动态技术

动态技术是双刃剑,菲尔德(Field)(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代码。

术语表/词汇表

随时间和空间变化的,不仅仅是程序语言和众人的编码技术,业务语言和平时的交换语言其实也会转移。尽管在一个特定的行业领域里,总会有些我们都知晓的名词,然则在软件的生育过程中,关键用户、业务顾问、在此往日是用户/开发者/业务顾问的领导者等人群,毕竟有着不同的背景和阅历,对同一个词的精通也许并不一样(具体的来头想必是复杂的,这里不展开钻探)。因为人们的交换是树立在如此不同的根底之上,所以有时候就会难免爆发误解和低效能的沟通。大量的交换时间,往往会浪费在澄清一个基础概念上,有时仍旧因为误会造成分外的损失。这种场馆在不同的团体/部门中间的互换中更是常见,也特别有害。

高功能的互换应该以定义作为开头,而非以定义作为完结。为了实现这一目的,引入词汇表也许是个方便的主意。假诺需要描述、开发文档、测试用例等都使用约定好、定义明确的事体词汇,用户、业务顾问、开发期间的联络就不会有歧义,也可以避免某些人在写代码时胡乱命名。这样一来,就能更好地控制词的意思的一致性和生成。由变化引起的维护困难,便通过减轻。

 

从不哪个单一的主意可以维持程序的可维护性,它需要靠各地点的不竭来推动。以上是自己的部分感想。也欢迎我们发表自己对可维护性的见识,或者对本文的始末展开指正。

 

术语表/词汇表

随时间和空间变化的,不仅仅是程序语言和众人的编码技术,业务语言和平常的交换语言其实也会变动。即使在一个特定的本行领域里,总会有些我们都知晓的名词,然则在软件的生育过程中,关键用户、业务顾问、往日是用户/开发者/业务顾问的总监等人流,毕竟有着不同的背景和经历,对同样个词的知情也许并不一致(具体的原由想必是繁体的,这里不展开商量)。因为人们的互换是确立在那样不同的功底之上,所以有时就会难免爆发误解和低效用的互换。大量的交换时间,往往会浪费在澄清一个基础概念上,有时依然因为误会造成万分的损失。这种景观在不同的协会/部门期间的交换中越发常见,也特别有害。

高功用的互换应该以定义作为开首,而非以定义作为完结。为了兑现这一目的,引入词汇表也许是个便宜的方法。假设急需描述、开发文档、测试用例等都采取约定好、定义明确的政工词汇,用户、业务顾问、开发期间的关联就不会有歧义,也足以避免某些人在写代码时胡乱命名。这样一来,就能更好地控制词的意思的一致性和转变。由变化引起的护卫困难,便通过减轻。

 

从没哪个单一的方法可以维持程序的可维护性,它需要靠各方面的努力来促进。以上是自身的局部感想。也欢迎大家公布自己对可维护性的理念,或者对本文的始末展开指正。

 

相关文章