透过多个盖世的开发者的改。经过多少只盖世之开发者的改动。

耦合度即模块之间的关系强度。高耦合度的次第牵一发而动全身,只称为需要非常平静的顺序。对于形成的ABAP程序来说,降低耦合度可以减掉程序修改对其余一些的震慑,是比较重大之。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的应用得使我们的程序变得老大活,但究竟是先后的可读性通常不绝好,而且针对新手来说吧绝对是可怜为难修改的。因此,我提议尽量将她看成基础意义的落实,和次中的硬编码、配置表相结合,或者是经新建子类的点子来促成效益的壮大,并且附以文档,说明程序的扩展方法。尽可能避免给后人直接改动大气用动态技术的主次。

避免全局变量

全局变量不好,这是颇具开发者的共识。之所以专门还要将出它来作为一个小节,是以自身觉着是问题莫过于普遍都严重。可能坐多数ABAP二次开发程序还是情比较少之表,最常用的ALV报表类(函数)则要求其输入的多少内表必须是全局变量,初入行的开发者通常是自全局变量写起的,而比较简单的程序逻辑也于开发者没有接受全局变量带来的麻烦….这种惯性使得许多开发者在后开相对大型的次序时为会见大量以全局变量。而先后的跟随者通常没有生命力还是力来识别全局变量对程序的熏陶,从而以窜程序时造成了预想之外的结果。此外,不加以释放的全局变量也会带动性能达到的负责。所以自己当开发者应该时时想是否好为此有变量代替全局变量、用价传递代替引用传递,时时在意避免全局变量带来的分神。 

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

脚结合具体的ABAP开发技术来谈谈自己本着它的想法,因为光是基于自己的组成部分历的来写,可能未是网完善的牵线。

自身以为问题之关键在于减少耦合度、理清程序职责的分红,清晰的次描述为蛮要紧:

中间层

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

脚结合实际的ABAP开发技术来谈谈自己对它的想法,因为光是冲自己的有的经历的来写,可能未是网完美的牵线。

SAP系统作为企业之音体系,其生命周期通常是长期的,比单个程序员的在职时一旦加上得多。早期实施等花大劲开之自定义程序,会付出于柜内还是外部的运维团队来保障——不管怎么样,一般不是首的开发者了。即便是于运维阶段,程序的创建人和修改者也时时不是一个人口。不同的开发者,其知识底子、技术水平、编码风格难免有所不同,最早创建的主次,经过多单盖世的开发者的改动,可能会见变换得面目全非,失去可维护性。这时的顺序可以说既接近于死亡…因此,作为序的开发者,我们用被祥和之次序对修改有抵抗力,从而会于后之护卫下活的重复悠久有。

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

描绘起意义的诠释

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

多年来看来的一个典型的不好的注释:

*处理数据
PERFORM frm_process_data.

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

  1. 如果盖文章来比,FROM的名字就凡文章的题目,我们不应在题中描绘清楚标题是标题。显然,FRM的前缀是废的,它被不了咱啊信息。
  2. “处理数据”似乎是指向FORM功能的讲述,这有些情节应当置身FORM的定义处,而不是调用位置。在调用位置的注解,需要写的是:为什么这个FORM需要在这边叫调用?为什么非是调动用别样一个看起相似之FROM?
  3. 在诠释中写“处理多少”这种轻描淡写的辞通常发生不了啊意义,更毫不说FORM名已经是process
    data(处理数据)了。这种又有害无益。

诸如此类的注释了多,大概就是众人数反感注释的来由吧。好之注释需要出现在客观之职位,需要写“为什么”而非是“做了呀”。这还是殊考验写作者对先后的接头的,需要发出“同理心”,预见读者的需才可以。

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

 

如果是函数、或者类的话语,还好写专门的文档:

硬编码与配置表

这两者的法则在用针对先后的修改变为“扩展”,在非过问或于少干预程序代码的情事,完成功能的转移。如果程序的读者看到了序中之枚举或者常量,那么他即使见面知道这些东西的改动会造成哪些的影响。一个好之命名可以帮助读者知道它们的用意。

ABAP
7.51面临引入了枚举对象,它对贯彻程序中之数据的一致性有深好的拉,相比常量而言强大许多。在同样的场合,可以考虑是否可以用枚举来提高可维护性。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的行使可以假设我们的次序变得老心灵手巧,但究竟是程序的可读性通常不绝好,而且对新手来说呢决是怪麻烦修改的。因此,我提议尽量将她当作基础作用的贯彻,和次中之硬编码、配置表相结合,或者是由此新建子类的法门来兑现效益的扩大,并且附以文档,说明程序的扩充方法。尽可能避免被后人直接修改大气使动态技术之先后。

 

开源工具

开发人员在工作中可能会见要有些类库,有时人们见面友善写类库。在投入时间友好写类库之前,可以预先找找是否在现成的优良开源工具。因为个人的东西或会见以文档不完备或者人员变动变得管人会知晓,也会见被新人比较生之读书成本。而好的开源工具的生气更胜似片,也有重多同行知道该怎么用。

以,很多丁当写用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开发者用其。我来看的大部顺序采取错误码或者失实标识的法门来处理错误。以自家之阅历来拘禁,错误码在单层的调用关系中凡是比好用之,但是于差不多重叠的、复杂的景象下,异常比错误代码要重复易于处理及维护。而且特别有着比较好的自身描述能力,这当次的保护着是可怜有意义之。而广大错误码是就的魔法数字,只有开发者本人知道凡是什么意思,后续维护的人口当观错误代码时,只能认识及:这里来只错误…并无知底每个错误代码的涵义。

本来,抵抗修改的意,并无是凭借妨碍后人修改程序。企业之作业是形成的、人们对需求的理解是无休止加剧的,因而程序的修改为是必要的。抵抗修改的目标应该是:在合理之求变动发生常,尽量吃修改变得爱,并减弱多少修改带来的毁损,从而让程序会经受更频繁底修改。

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

开源工具

开发人员在工作中可能会见需要部分类库,有时人们会融洽写类库。在投入时间自己写类库之前,可以优先找找是否留存现成的脍炙人口开源工具。因为个人的东西可能会见盖文档不全或者人员变动变得管人会领悟,也会见吃新人比较生之攻成本。而好之开源工具的肥力更胜似有,也出重多同行知道该怎么用。

论,很多人数当形容以OLE生成Excel的顺序时会进行自然之包裹来处理麻烦的call
method
of语句。在是基础及,人们会形成各自的包方式,阅读彼此的OLE程序时,就可能只要花点时间来考察对方在包装习惯及之一线区别。但是,如果能够采用XLSX
Workbench及时等同理想之开源工具,大家就得经一点一滴平等之点子生成Excel。它使用起来大概、性能出色,并且(在大多数状下)可以避免写维护起来麻烦的OLE代码。

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

SAP系统作为店铺的音信体系,其生命周期通常是长期的,比单个程序员的在职时一旦加上得差不多。早期实施阶段花蛮劲开的自定义程序,会付出给公司内还是外部的运维团队来保障——不管怎么样,一般不是最初的开发者了。即便是于运维阶段,程序的主创者和修改者也时常不是一个人。不同之开发者,其知底子、技术水平、编码风格难免有所不同,最早创建的次序,经过若干单盖世之开发者的改动,可能会见转换得面目全非,失去可维护性。这时的次可以说都八九不离十受死亡…因此,作为次的开发者,我们得让祥和的次第对修改有抵抗力,从而能够当后人的护下活的又久有。

术语表/词汇表

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

高效率的交流该坐定义作为开头,而不因为定义作为了。为了兑现即时同一靶,引入词汇表也许是只好的主意。如果要求描述、开发文档、测试用例等还使用约定好、定义明确的事务词汇,用户、业务顾问、开发期间的沟通就是未见面发生歧义,也堪免某些人于写代码时胡乱命名。这样一来,就可知更好地控制词的意义之一致性与转移。由变化引起的保障困难,便由此减轻。

 

莫哪个单一的章程能保持程序的可维护性,它需依赖各级面的奋力来推动。以上是我之局部感想。也欢迎大家发表自己对可维护性的理念,或者对本文的始末展开指正。

 

中间层

每当打造和其余系统连接的接口时,由于各地方的原委,会不时遇到对方要改接口的输入输出方式还是格式的情形。这时候,不是直接提供被对方包含业务处理逻辑的接口,而是建立一个外层接口,把本来的接口包装起来,专门就此来回应对方的修改,是一个好法子。相似的笔触为得据此当其它经常改变的地方。

硬编码与配置表

立马两者的规律在用针对程序的修改变为“扩展”,在不过问或于少干预程序代码的状,完成功能的反。如果程序的读者看到了先后中的枚举或者常量,那么他尽管会见掌握这些事物的修改会造成怎样的熏陶。一个吓之命名可以助读者了解它的意图。

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

耦合度即模块之间的涉强度。高耦合度的次序牵一发而动全身,只可吃需求大稳定之程序。对于形成的ABAP程序来说,降低耦合度可以抽程序修改对另外一些的熏陶,是比关键之。

先后的描述包含命名、程序结构这种“自我描述”,也囊括程序注释、技术文档,以及需求文档。这说不定是最为容易改善的一个点。

单独的解耦工作来或于咱陷入为解耦而解耦的陷阱。了解程序的天职分配好被咱们越来越理性地使技术,并且要程序对修改有再度好之适应性。

CDS视图

SQL是让不少程序员发厌烦的事物。过去,由于内表的在,大家照面因此简易的SQL取出较多之数,然后于内表中拍卖它们,计算主要以应用服务器中进行。但于HANA推出后,SAP提出了code
pushdown模式,鼓励用还多之办事付出数据库服务器来开,也也ABAP的Open
SQL提供了又强劲的效力。可见日后的SQL将转移得渐渐复杂。在纷繁的SQL上进展修改或者会见耗时比多、测试困难,有时也会见无小心造成性能问题。ABAP
CDS视图澳门皇冠官网app的引入可以比好的承诺本着这些问题。如果早期的开发者能够利用CDS抽象出安宁的数据模型,把经多SQL处理的数额作为已存在的多少来拘禁,那么就算会简化ABAP程序中之SQL复杂度,同时为跌后续之开发者和工作顾问的心智负担和联络成本。

(想同一怀念我们是匪是时说这种冗长的话语:XX属性是透过关联A表和B表,使它们的号、业务编号和活动序号相等,在取消标识不顶’X’等情事下,获取其的某个同性,再至性对诺交的分红表C,获取有效期内之笔录——看罢并明白这么长一段话之后,也许交流的两头已经注意着理解XX属性究竟怎么样获得,忘记了自己于想的别东西。如果这种干逻辑在企业之急需面临凡是平稳的竟然不时出现的,我们全可啊其过去一个“新歌词”,即CDS视图。基于CDS视图,之后的沟通方式可以成为:到视图ZCDSXX中,根据取消标识不齐’X’,获取我们要之XX属性)

擅异常

特别是只很有因此的事物,但是我万分少见到出ABAP开发者用它。我视的大多数序用错误码或者失实标识的不二法门来处理错误。以己的经历来拘禁,错误码在单层的调用关系被是较好用的,但是以多交汇的、复杂的情下,异常比错误代码要再爱处理与掩护。而且非常有着比较好之自家描述能力,这在次的维护着是深有意义的。而广大错误码是只有的魔法数字,只有开发者本人知道是什么意思,后续维护的人数于察看错误代码时,只能认识及:这里发生个错误…并无晓得每个错误代码的涵义。

 

次的描述包含命名、程序结构这种“自我描述”,也囊括程序注释、技术文档,以及要求文档。这或许是最为轻改善的一个面。

仅的解耦工作产生或被咱们陷入为解耦而解耦的陷阱。了解程序的天职分配好为咱们越来越理性地采用技术,并且使程序对修改有再次好的适应性。

描绘起义的注释

据称写程序不写注释是相同种很糟糕之惯,也闹付出规范约束人们:必须使描绘注释。注释当然是少不了之,但是在实践中,大部分口的注释水平是不绝好之,往往针对阅读起免顶啊正面作用,于是甚至催生了一如既往种植反叛的、矫枉过正的视角:好之主次没有需要注释。

近日瞧的一个卓越的不得了的笺注:

*处理数据
PERFORM frm_process_data.

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

  1. 一旦为文章来对比,FROM的名字就凡文章的题,我们无应当以题目中描写清楚标题是标题。显然,FRM的前缀是杯水车薪的,它为莫了我们什么消息。
  2. “处理数据”似乎是本着FORM功能的叙说,这片情节应当放在FORM的定义处,而未是调用位置。在调用位置的诠释,需要写的凡:为什么这个FORM需要以此处吃调用?为什么非是调整用任何一个关押起相似的FROM?
  3. 以诠释中描绘“处理多少”这种肤浅的辞通常有不了什么意义,更毫不说FORM名已经是process
    data(处理数据)了。这种又有害无益。

这么的笺注了多,大概就是是成千上万口反感注释的缘故吧。好的笺注需要出现于情理之中的岗位,需要写“为什么”而休是“做了哟”。这尚是挺考验写作者对程序的知晓的,需要出“同理心”,预见读者的需求才得。

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

 

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

自然,抵抗修改的意,并无是凭妨碍后人修改程序。企业之事情是形成的、人们对需求的敞亮是不断加剧的,因而程序的改为是必要的。抵抗修改的对象应该是:在合理之急需变动发生常,尽量吃修改变得爱,并减弱多少修改带来的磨损,从而让程序会经受更频繁之改。

免全局变量

全局变量不好,这是所有开发者的共识。之所以专门还要用出其来作一个小节,是为自己当这题目实际上普遍都严重。可能以多数ABAP二次开发程序都是情比较少的表格,最常用之ALV报表类(函数)则要求该输入的数码内表必须是全局变量,初入行的开发者通常是从全局变量写起的,而正如简单的程序逻辑也被开发者没有受全局变量带来的麻烦….这种惯性使得众多开发者在以后出相对大型的主次时为会见大量运全局变量。而先后的拥护者通常没有精力要力来辨别全局变量对程序的震慑,从而以改动程序时造成了预想之外的结果。此外,不加以释放的全局变量也会带性能上的承受。所以自己看开发者应该时时想是否可以用部分变量代替全局变量、用价传递代替引用传递,时时在意避免全局变量带来的累。 

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

术语表/词汇表

随时间和空间别的,不仅仅是程序语言和人们的编码技术,业务语言及普通的交流语言其实呢会见转移。虽然当一个一定的本行领域里,总会有些大家都知道之名词,然而以软件之生过程被,关键用户、业务顾问、从前是用户/开发者/业务顾问的企业管理者当人流,毕竟有着不同的背景和阅历,对同一个词的喻也许连无均等(具体的故或许是错综复杂的,这里不展开讨论)。因为人们的交流是起在这样不同的底蕴之上,所以有时候便会难免产生误解和低效率的交流。大量之交流时间,往往会浪费在澄清一个基础概念上,有时还是盖误会造成相当的损失。这种现象在不同之团组织/部门中的交流着越来越常见,也特别有害。

愈效率的交流应该以定义作为初始,而不因为定义作为完结。为了兑现就同样靶,引入词汇表也许是个好之点子。如果要求描述、开发文档、测试用例等都运约定好、定义明确的事情词汇,用户、业务顾问、开发期间的联络就是非会见发歧义,也堪避某些人以形容代码时胡乱命名。这样一来,就能够再次好地控制词的意思的一致性和生成。由变化引起的保护困难,便由此减轻。

 

靡谁单一的法门能保持程序的可维护性,它要负各个面的不竭来推动。以上是本人之有感想。也接大家发表自己对可维护性的看法,或者对本文的情节展开指正。

 

相关文章