关于程序可维护性的片想法。关于程序可维护性的片段想方设法。

by admin on 2018年10月5日

硬编码与配置表

当时两者的规律在以针对程序的修改变为“扩展”,在不干涉或比较少干预程序代码的动静,完成功能的变动。如果程序的读者看到了程序中之枚举或者常量,那么他即使会见了解这些事物的改动会招致哪些的震慑。一个好的命名可以扶持读者了解它的意向。

ABAP
7.51丁引入了枚举对象,它对贯彻程序中之数的一致性有坏好的增援,相比常量而言强大许多。在同一之场合,可以设想是不是可以用枚举来提高可维护性。

善用异常

特别是个要命有因此之物,但是自己非常少看到出ABAP开发者用她。我瞅的多数程序下错误码或者不当标识的法子来处理错误。以自己的阅历来拘禁,错误码在单层的调用关系遭遇凡是比较好用之,但是当多重叠的、复杂的状况下,异常比错误代码要再易于处理与掩护。而且很有着较好的我描述能力,这当程序的护被凡是杀有义的。而博错误码是只是的魔法数字,只有开发者本人知道凡是什么意思,后续维护的人以观错误代码时,只能认识及:这里发出只错误…并无了解每个错误代码的涵义。

SAP系统作为企业之音体系,其生命周期通常是马拉松的,比单个程序员的在职时使丰富得差不多。早期实施等花那个劲开之自定义程序,会付出于铺里或外部的运维团队来保障——不管怎么样,一般不是早期的开发者了。即便是在运维阶段,程序的开创者和修改者也时不是一个人。不同的开发者,其文化底子、技术水平、编码风格难免有所不同,最早创建的次第,经过多少只盖世之开发者的修改,可能会见更换得面目全非,失去可维护性。这时的顺序可以说曾接近受死亡…因此,作为序的开发者,我们要给好的主次对修改有抵抗力,从而会以后的掩护下活的重长久有。

硬编码与配置表

这两边的原理在将对程序的修改变为“扩展”,在未干预或比少干预程序代码的情状,完成功能的改变。如果程序的读者看到了序中之枚举或者常量,那么他就是见面明白这些事物的改动会导致什么的震慑。一个吓的命名可以拉读者知道它的意。

ABAP
7.51挨引入了枚举对象,它对贯彻程序中的数额的一致性有格外好之赞助,相比常量而言强大许多。在平的场合,可以考虑是否可用枚举来提高可维护性。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的动可要我们的次变得不得了心灵手巧,但结果是程序的可读性通常不太好,而且对准新手来说也绝是挺为难修改的。因此,我建议尽量将她看成基础意义的兑现,和顺序中的硬编码、配置表相结合,或者是经过新建子类的方来贯彻力量的扩大,并且附以文档,说明程序的壮大方法。尽可能避免被后直接改动大气使动态技术的顺序。

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

避全局变量

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

徒的解耦工作有或给咱陷入为解耦而解耦的骗局。了解程序的任务分配好被我们进一步理性地使技术,并且使程序对修改有再次好的适应性。

形容起意义之笺注

传言写序不写注释是同样栽特别糟糕的惯,也来开发规范约束人们:必须要描绘注释。注释当然是必备之,但是在实践中,大部分人数的注释水平是不绝好的,往往针对读书起未至啊正面作用亚洲必赢手机,于是甚至催生了一样种反叛的、矫枉过正之眼光:好的先后没有需要注释。

不久前见到的一个榜首的糟糕的诠释:

*处理数据
PERFORM frm_process_data.

即段代码至少犯了3独谬误。

  1. 若是为文章来比,FROM的名字便凡是文章的题目,我们不应有在题目中描绘清楚标题是标题。显然,FRM的前缀是没用的,它为莫了俺们啊消息。
  2. “处理多少”似乎是指向FORM功能的叙述,这部分内容应该在FORM的定义处,而未是调用位置。在调用位置的注解,需要写的是:为什么这个FORM需要在此处吃调用?为什么非是调整用另外一个扣起相似的FROM?
  3. 在诠释中描写“处理数据”这种轻描淡写的辞通常有不了哟意思,更毫不说FORM名已经是process
    data(处理数量)了。这种又有害无益。

然的注释了多,大概就是是很多总人口反感注释的原委吧。好的注解需要出现于情理之中之位置,需要写“为什么”而无是“做了啊”。这尚是老考验写作者对程序的掌握的,需要发出“同理心”,预见读者的需要才可以。

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

 亚洲必赢手机 1

使是函数、或者类的讲话,还可以写专门的文档:

亚洲必赢手机 2

 

本,抵抗修改的意,并无是指妨碍后人修改程序。企业之工作是形成的、人们对需的喻是连连加重的,因而程序的修改为是必要的。抵抗修改的对象应该是:在情理之中的需变动发生时,尽量为修改变得易,并减弱多少修改带来的损坏,从而给程序会领双重累底改。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的使好使我们的次变得大活,但结果是次的可读性通常不绝好,而且针对新手来说呢绝对是蛮麻烦修改的。因此,我建议尽量把她看成基础意义的贯彻,和顺序中之硬编码、配置表相结合,或者是经新建子类的艺术来落实效益的扩大,并且附以文档,说明程序的壮大方法。尽可能避免吃后直接改动大气应用动态技术的顺序。

耦合度即模块之间的关联强度。高耦合度的次序牵一发而动全身,只适合为需求异常平安无事之程序。对于形成的ABAP程序来说,降低耦合度可以减程序修改对其他一些的影响,是比较重要之。

SAP系统作为店铺之信息体系,其生命周期通常是漫漫的,比单个程序员的在职时若是添加得几近。早期实施等花那个力气开之自定义程序,会付出受合作社内或外部的运维团队来维护——不管怎么样,一般不是最初的开发者了。即便是于运维阶段,程序的创建人和修改者也时时不是一个人口。不同的开发者,其知识基础、技术水平、编码风格难免有所不同,最早创建的主次,经过多个盖世的开发者的修改,可能会见变换得面目全非,失去可维护性。这时的程序可以说曾八九不离十被死亡…因此,作为序的开发者,我们需要为投机的次对修改有抵抗力,从而能够当后人的维护下活的复老有。

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

自家觉得问题之关键在于减少耦合度、理清程序职责的分配,清晰的次描述为甚重要:

偏偏的解耦工作起或让我们陷入为解耦而解耦的骗局。了解程序的天职分配好为咱们更为理性地运用技术,并且要程序对修改有重好之适应性。

下结合实际的ABAP开发技术来讨论自己本着它们的想法,因为只是基于自己的有些历的来写,可能未是网完善的介绍。

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

中间层

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

术语表/词汇表

随时间和空中变化的,不仅仅是程序语言和人们的编码技术,业务语言和一般性的交流语言其实为会转。虽然在一个特定的行业领域里,总会有些大家还明白的名词,然而以软件之生过程遭到,关键用户、业务顾问、从前凡是用户/开发者/业务顾问的主任当人群,毕竟有不同之背景以及经验,对同个词的喻也许连无雷同(具体的来由想必是繁体的,这里不展开讨论)。因为人们的交流是立以如此不同的基本功之上,所以有时候纵然见面难免产生误解和低效率的交流。大量之交流时,往往会浪费在澄清一个基础概念上,有时还因误会造成一定的损失。这种情景在不同之社/部门内的交流受到更为常见,也专程有害。

赛效率的交流应该因为定义作为初始,而非因定义作为完结。为了贯彻即时同目标,引入词汇表也许是只便宜的方式。如果急需描述、开发文档、测试用例等都采用约定好、定义明确的事情词汇,用户、业务顾问、开发中的联络就是无见面发生歧义,也得以避某些人在描写代码时胡乱命名。这样一来,就能更好地控制词的意思的一致性和扭转。由变化引起的保安困难,便通过减轻。

 

并未哪位单一的艺术能保持程序的可维护性,它需要依赖各个面的全力来促进。以上是自身的有些感想。也接大家发表自己对可维护性的见,或者对本文的情节进行指正。

 

术语表/词汇表

随时间和空间别之,不仅仅是程序语言和众人的编码技术,业务语言与通常的交流语言其实也会见转。虽然于一个一定的行领域里,总会有些大家都理解之名词,然而以软件的产过程中,关键用户、业务顾问、从前是用户/开发者/业务顾问的领导人员等人流,毕竟有不同的背景和阅历,对同一个词之知晓也许连无平等(具体的因或者是复杂的,这里不展开讨论)。因为人们的交流是确立在这么不同的底子之上,所以有时候便会难免产生误解和没有效率的交流。大量的交流时,往往会浪费在澄清一个基础概念上,有时甚至以误会造成一定的损失。这种状况在不同之集体/部门之间的交流中越常见,也特地有害。

愈效率的交流应该为定义作为开,而未缘定义作为完结。为了实现这等同对象,引入词汇表也许是单便民的办法。如果急需描述、开发文档、测试用例等还用约定好、定义明确的事情词汇,用户、业务顾问、开发期间的沟通就非会见出歧义,也得避某些人当写代码时胡乱命名。这样一来,就可知重好地控制词的意义的一致性和扭转。由变化引起的保安困难,便通过减轻。

 

从没孰单一的方式能保持程序的可维护性,它要依靠各级地方的拼命来推进。以上是自个儿的一对感想。也接大家发表自己对可维护性的理念,或者对本文的始末展开指正。

 

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属性)

当然,抵抗修改的意思,并无是据妨碍后人修改程序。企业之业务是形成的、人们对急需的理解是频频强化的,因而程序的改也是必要的。抵抗修改的对象应该是:在合理之需求变动发生常,尽量吃修改变得爱,并减弱多少修改带来的破坏,从而被程序能够接受双重累底改。

 

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

擅长异常

生是只特别有因此之物,但是我异常少看到有ABAP开发者用它们。我来看的大部先后行使错误码或者失实标识的法门来处理错误。以自家的经验来拘禁,错误码在单层的调用关系中凡于好用底,但是在多交汇的、复杂的场面下,异常比错误代码要又爱处理同维护。而且死有着比较好的自己描述能力,这当次的维护中是殊有含义的。而许多错误码是单的魔法数字,只有开发者本人知道凡是呀意思,后续维护的丁当收看错误代码时,只能认识及:这里产生个错误…并无明白每个错误代码的涵义。

耦合度即模块之间的涉嫌强度。高耦合度的顺序牵一发而动全身,只抱吃需求异常平静之先后。对于形成的ABAP程序来说,降低耦合度可以减小程序修改对另一些的熏陶,是比较关键之。

开源工具

开发人员在工作中可能会见待一些类库,有时人们会协调写类库。在投入时间友好写类库之前,可以先行找是否有现成的理想开源工具。因为个人的东西可能会见以文档不齐或者人员改变变得无人能知晓,也会于新人比较充分的念成本。而好之开源工具的活力更强一些,也出再多同行知道该怎么用。

按照,很多人当形容以OLE生成Excel的顺序时会见进行一定之包裹来拍卖麻烦的call
method
of语句。在这个基础及,人们见面形成各自的包裹方式,阅读彼此的OLE程序时,就可能只要花点时间来考察对方以卷入习惯及的轻区别。但是,如果能采用XLSX
Workbench即时同佳的开源工具,大家就得经一点一滴同之法生成Excel。它使用起来简单、性能出色,并且(在大部分动静下)可以避写维护起来累的OLE代码。

形容来意义的注释

传闻写程序不写注释是同等栽颇不好之惯,也发出规范约束人们:必须使描绘注释。注释当然是少不了的,但是在实践中,大部分人之诠释水平是勿绝好的,往往针对读起免交啊正面作用,于是甚至催生了相同种植反叛的、矫枉过正之见识:好的程序没有需要注释。

最近盼的一个天下无双的糟糕的诠释:

*处理数据
PERFORM frm_process_data.

顿时段代码至少犯了3独错。

  1. 苟以文章来对比,FROM的名就凡文章的题,我们无应该以题中描写清楚标题是标题。显然,FRM的前缀是低效的,它深受莫了俺们什么消息。
  2. “处理多少”似乎是对FORM功能的叙说,这有内容应当置身FORM的定义处,而无是调用位置。在调用位置的注释,需要写的是:为什么是FORM需要在此地让调用?为什么不是调整用别样一个禁闭起相似的FROM?
  3. 每当诠释中形容“处理多少”这种轻描淡写的辞通常发生不了啊意义,更不用说FORM名已经是process
    data(处理数据)了。这种重新有害无益。

如此这般的笺注了多,大概就是是许多总人口反感注释的原因吧。好之笺注需要出现在合理之职务,需要写“为什么”而不是“做了呀”。这尚是老大考验写作者对程序的解的,需要出“同理心”,预见读者的要求才足以。

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

 亚洲必赢手机 3

倘是函数、或者类的语句,还好写专门的文档:

亚洲必赢手机 4

下结合实际的ABAP开发技术来讨论自己对其的想法,因为只有是因自己之一对涉的来描写,可能不是系到的牵线。

先后的叙述包含命名、程序结构这种“自我描述”,也囊括程序注释、技术文档,以及需要文档。这或是极轻改善的一个方。

程序的叙说包含命名、程序结构这种“自我描述”,也席卷程序注释、技术文档,以及要求文档。这或者是极度容易改善的一个上面。

开源工具

开发人员在工作中可能会见用有的类库,有时人们会好写类库。在投入时间友好写类库之前,可以预先物色是否存在现成的绝妙开源工具。因为个人的东西可能会见盖文档不齐全或者人员改变变得管人能理解,也会见给新人比较充分的就学成本。而好之开源工具的生机更胜片,也闹更多同行知道该怎么用。

论,很多口当写用OLE生成Excel的顺序时会展开得之卷入来拍卖麻烦的call
method
of语句。在这基础及,人们会形成各自的包装方式,阅读彼此的OLE程序时,就可能要花点时间来观察对方以卷入习惯及之分寸区别。但是,如果能使XLSX
Workbench当即等同精美之开源工具,大家就可以通过一点一滴平等之措施生成Excel。它采用起来简单、性能优良,并且(在大部分情形下)可以避写维护起来麻烦的OLE代码。

自己认为问题的关键在于减少耦合度、理清程序职责的分配,清晰的程序描述为够呛关键:

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二次开发程序都是内容比较少的表,最常用之ALV报表类(函数)则要求其输入的数额内表必须是全局变量,初入行的开发者通常是于全局变量写于的,而比简单的程序逻辑也吃开发者没有经受全局变量带来的麻烦….这种惯性使得森开发者在今后付出相对大型的顺序时为会见大量运用全局变量。而先后的支持者通常没有精力还是能力来识别全局变量对先后的震慑,从而以改动程序时造成了预想之外的结果。此外,不加释放的全局变量也会见带动性能达到的承受。所以我当开发者应该时时想是否好为此有变量代替全局变量、用价传递代替引用传递,时时在意避免全局变量带来的分神。 

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图