有关程序可维护性的一对想方设法

SAP系统作为集团的音信序列,其生命周期常常是绵长的,比单个程序员的在职时间要长得多。早期实施阶段花大力气开发的自定义程序,会交付给集团内部或外部的运维团队来珍爱——不管什么样,一般不是先前时期的开发者了。即使是在运维阶段,程序的主创者与修改者也不时不是一个人。不同的开发者,其学问底子、技术水平、编码风格难免有所不同,最早创造的程序,经过多少个盖世的开发者的改动,可能会变得面目全非,失去可维护性。这时的先后可以说已经八九不离十于死亡…因而,作为程序的开发者,我们需要让投机的次序对修改有抵抗力,从而能在后人的护卫下活的更久一些。

本来,抵抗修改的情趣,并不是指妨碍后人修改程序。集团的政工是形成的、人们对需求的驾驭是绵绵深化的,因此程序的改动也是必要的。抵抗修改的对象应该是:在不出所料的急需变动发生时,尽量让修改变得容易,并减小修改带来的磨损,从而让程序能接受更频繁的改动。

自我以为问题的关键在于缩小耦合度、理清程序职责的分红,清晰的主次描述也很重大:

耦合度即模块之间的涉嫌强度。高耦合度的先后牵一发而动全身,只适合于需求特别平静的主次。对于形成的ABAP程序来说,降低耦合度可以减小程序修改对其他一些的熏陶,是相比首要的。

无非的解耦工作有可能让我们陷入为解耦而解耦的圈套。理解程序的天职分配可以让大家尤其理性地利用技术,并且使程序对修改有更好的适应性。

次第的讲述包含命名、程序结构这种“自我描述”,也包括程序注释、技术文档,以及要求文档。这可能是最容易改革的一个方面。

上边结合现实的ABAP开发技术来谈谈自己对它们的想法,因为只是基于自己的一些经验的来写,可能不是系统完善的介绍。

 

C++,本文链接: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(处理多少)了。这种重新有害无益。

这般的笺注过多,大概就是广大人反感注释的由来呢。好的声明需要出现在成立的岗位,需要写“为啥”而不是“做了什么样”。这仍然挺考验写作者对程序的了解的,需要有“同理心”,预见读者的需求才足以。

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

 C++ 1

倘若是函数、或者类的话,仍可以写专门的文档:

C++ 2

善于异常

不行是个很有用的事物,然则本人很少看到有ABAP开发者用它。我见到的多数顺序接纳错误码或者不当标识的措施来处理错误。以本人的阅历来看,错误码在单层的调用关系中是比较好用的,不过在多层的、复杂的情况下,非常比错误代码要更便于处理和掩护。而且特别有着较好的自家描述能力,那在先后的保安中是很有含义的。而过多错误码是仅仅的魔法数字,唯有开发者本人知道是怎样意思,后续维护的人在见到错误代码时,只可以认识到:那里有个错误…并不驾驭每个错误代码的涵义。

避免全局变量

全局变量糟糕,这是具备开发者的共识。之所以专门还要拿出它来作为一个小节,是因为我认为这个题材其实普遍且严重。可能因为大部分ABAP二次开发程序都是内容较少的表格,最常用的ALV报表类(函数)则要求其输入的数码内表必须是全局变量,初入行的开发者平常是从全局变量写起的,而较简单的程序逻辑也让开发者没有收受全局变量带来的麻烦….这种惯性使得众多开发者在其后支出相对大型的顺序时也会大方应用全局变量。而先后的跟随者平日没有生命力或能力来甄别全局变量对先后的震慑,从而在修改程序时造成了预想之外的结果。此外,不加释放的全局变量也会带来性能上的承受。所以自己认为开发者应该时时思考是否足以用部分变量代替全局变量、用值传递代替引用传递,时时在意避免全局变量带来的难为。 

开源工具

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

例如,很三个人在写使用OLE生成Excel的次第时会举办一定的包装来处理麻烦的call
method
of语句。在此基础上,人们会形成各自的包裹情势,阅读互相的OLE程序时,就可能要花点时间来察看对方在包装习惯上的细微区别。不过,假使能利用XLSX
Workbench
这一完美的开源工具,我们就足以因此完全相同的措施生成Excel。它采纳起来简单、性能优异,并且(在大部分意况下)可以制止写维护起来麻烦的OLE代码。

术语表/词汇表

随时间和空间变化的,不仅仅是程序语言和众人的编码技术,业务语言和普通的互换语言其实也会转移。即使在一个特定的本行领域里,总会有些我们都晓得的名词,可是在软件的生产过程中,关键用户、业务顾问、在此以前是用户/开发者/业务顾问的首席执行官等人流,毕竟有着不同的背景和阅历,对相同个词的理解也许并不相同(具体的因由想必是繁体的,这里不展开探讨)。因为人们的交换是确立在这样不同的功底之上,所以有时候就会难免发生误解和低功效的交换。大量的互换时间,往往会浪费在澄清一个基础概念上,有时甚至因为误会造成一定的损失。那种情景在不同的集团/部门之间的互换中更加常见,也专门有害。

高效能的交换应该以定义作为初阶,而非以定义作为完结。为了促成这一对象,引入词汇表也许是个有利的格局。即使需要描述、开发文档、测试用例等都施用约定好、定义明确的工作词汇,用户、业务顾问、开发期间的关联就不会有歧义,也得以避免某些人在写代码时胡乱命名。这样一来,就能更好地控制词的含义的一致性和扭转。由变化引起的保安困难,便通过减轻。

 

一向不哪个单一的模式可以保障程序的可维护性,它需要靠各地方的大力来推进。以上是自己的部分感想。也欢迎我们发布自己对可维护性的见解,或者对本文的情节开展指正。