有关程序可维护性的一些想方设法亚洲必赢bwin696.com

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(处理多少)了。这种重新有害无益。

这样的诠释过多,大概就是无数人反感注释的原故吗。好的笺注需要出现在客观的地方,需要写“为何”而不是“做了什么”。这仍旧挺考验写作者对程序的接头的,需要有“同理心”,预见读者的需求才得以。

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

 亚洲必赢bwin696.com 1

只若是函数、或者类的话,还可以够写专门的文档:

亚洲必赢bwin696.com 2

擅长相当

老大是个很有用的东西,不过我很少看到有ABAP开发者用它。我见到的绝大多数程序采用错误码或者不当标识的办法来处理错误。以自身的阅历来看,错误码在单层的调用关系中是相比好用的,然而在多层的、复杂的动静下,非常比错误代码要更易于处理和维护。而且丰裕有着较好的本人描述能力,这在程序的珍贵中是很有含义的。而许多错误码是一味的魔法数字,唯有开发者本人知道是怎么着看头,后续维护的人在观察错误代码时,只能认识到:这里有个错误…并不知底每个错误代码的涵义。

制止全局变量

亚洲必赢bwin696.com,全局变量欠好,这是负有开发者的共识。之所以专门还要拿出它来作为一个小节,是因为我觉着这一个题材其实普遍且严重。可能因为大部分ABAP二次开发程序都是内容较少的报表,最常用的ALV报表类(函数)则要求其输入的多寡内表必须是全局变量,初入行的开发者平日是从全局变量写起的,而较简单的程序逻辑也让开发者没有经受全局变量带来的麻烦….这种惯性使得许多开发者在后头开发相对大型的次第时也会大方采用全局变量。而先后的跟随者平常没有生命力或能力来分辨全局变量对先后的影响,从而在改动程序时造成了预想之外的结果。其余,不加释放的全局变量也会带来性能上的担当。所以自己认为开发者应该平时思考是否足以用有些变量代替全局变量、用值传递代替引用传递,时时注意避免全局变量带来的费劲。 

开源工具

开发人士在工作中可能会需要有的类库,有时人们会自己写类库。在投入时间友好写类库从前,能够先物色是否留存现成的漂亮开源工具。因为个人的事物可能会因为文档不齐全或者人士更改变得无人能知道,也会给新人较大的学习成本。而好的开源工具的肥力更强一些,也有更多同行知道该怎么用。

譬如说,很两个人在写使用OLE生成Excel的次序时会举行自然的包装来处理麻烦的call
method
of语句。在此基础上,人们会形成各自的卷入情势,阅读互相的OLE程序时,就可能要花点时间来察看对方在包装习惯上的微薄区别。但是,假如能应用XLSX
Workbench
这一两全其美的开源工具,我们就可以透过完全相同的法门生成Excel。它采取起来大概、性能优异,并且(在多数状态下)能够避免写维护起来麻烦的OLE代码。

术语表/词汇表

随时间和空中变化的,不仅仅是程序语言和众人的编码技术,业务语言和通常的沟通语言其实也会改变。虽然在一个特定的行当领域里,总会有些大家都晓得的名词,可是在软件的生育过程中,关键用户、业务顾问、在此从前是用户/开发者/业务顾问的公司管理者等人群,毕竟有着不同的背景和阅历,对同一个词的明亮也许并不一样(具体的原由想必是繁体的,这里不展开琢磨)。因为人们的互换是树立在如此不同的根基之上,所以有时候就会难免暴发误解和低功能的交流。大量的互换时间,往往会浪费在澄清一个基础概念上,有时甚至因为误会造成一定的损失。这种光景在不同的团社团/部门之间的互换中越来越常见,也特别有害。

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

 

从没哪个单一的方法能够保持程序的可维护性,它需要靠各地方的极力来促进。以上是自个儿的有的感想。也欢迎我们宣布自己对可维护性的见识,或者对本文的情节开展指正。

 

相关文章