至于程序可维护性的局部设法

开源工具

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

譬如说,很六个人在写使用OLE生成Excel的次序时会举办自然的包装来处理麻烦的call
method
of语句。在此基础上,人们会形成各自的卷入格局,阅读互相的OLE程序时,就可能要花点时间来察看对方在卷入习惯上的微小区别。可是,假使能运用XLSX
Workbench
这一了不起的开源工具,我们就足以因而完全相同的法门生成Excel。它应用起来简单、性能突出,并且(在大部分情状下)能够制止写维护起来麻烦的OLE代码。

正文链接: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开发者用它。我见到的多数顺序采纳错误码或者不当标识的主意来处理错误。以自我的经历来看,错误码在单层的调用关系中是相比好用的,不过在多层的、复杂的情形下,很是比错误代码要更易于处理和敬爱。而且万分有着较好的本身描述能力,这在程序的护卫中是很有含义的。而不少错误码是然而的魔法数字,只有开发者本人知道是什么看头,后续维护的人在观望错误代码时,只可以认识到:这里有个错误…并不明了每个错误代码的涵义。

硬编码与配置表

这两头的规律在于将对先后的修改变为“扩展”,在不干预或较少干预程序代码的事态,完效率能的更改。如若程序的读者看到了程序中的枚举或者常量,那么他就会精晓这多少个东西的修改会促成哪些的震慑。一个好的命名可以协理读者领会它们的效益。

ABAP
7.51中引入了枚举对象,它对于落实程序中的数据的一致性有很好的鼎力相助,相比常量而言强大许多。在同样的场子,可以设想是不是可以用枚举来提升可维护性。

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

制止全局变量

全局变量不佳,这是怀有开发者的共识。之所以专门还要拿出它来作为一个小节,是因为自己认为这些题材其实普遍且严重。可能因为大部分ABAP二次开发程序都是内容较少的表格,最常用的ALV报表类(函数)则要求其输入的多少内表必须是全局变量,初入行的开发者日常是从全局变量写起的,而较简单的程序逻辑也让开发者没有接受全局变量带来的麻烦….这种惯性使得广大开发者在其后开发相对大型的顺序时也会大方使用全局变量。而先后的拥护者通常没有生气或能力来识别全局变量对程序的熏陶,从而在改动程序时造成了预想之外的结果。另外,不加释放的全局变量也会带动性能上的负责。所以自己认为开发者应该时时思考是否足以用一些变量代替全局变量、用值传递代替引用传递,时时在意防止全局变量带来的劳动。 

耦合度即模块之间的关联强度。高耦合度的程序牵一发而动全身,只适合于需求相当平静的顺序。对于形成的ABAP程序来说,降低耦合度可以减小程序修改对任何一些的影响,是相比较紧要的。

写有意义的诠释

据说写程序不写注释是一种很不佳的习惯,也有付出规范约束人们:必须要写注释。注释当然是必要的,不过在实践中,大部分人的笺注水平是不太好的,往往对阅读起不到什么样正面效果,于是甚至催生了一种反叛的、矫枉过正的见识:好的先后没有需要注释。

如今观察的一个典型的欠好的注脚:

*处理数据
PERFORM frm_process_data.

这段代码至少犯了3个错误。

  1. 如以作品来对待,FROM的名字即是作品的标题,大家不应该在题目中写明标题是标题。分明,FRM的前缀是行不通的,它给不了我们什么样消息。
  2. “处理多少”似乎是对FORM效率的叙说,这有些情节应该置身FORM的定义处,而不是调用位置。在调用地点的笺注,需要写的是:为何那多少个FORM需要在此间被调用?为啥不是调用别样一个看起来相似的FROM?
  3. 在诠释中写“处理数据”这种肤浅之辞日常暴发持续什么意义,更不用说FORM名已经是process
    data(处理多少)了。这种重新有害无益。

如此这般的诠释过多,大概就是成百上千人反感注释的缘故吧。好的笺注需要出现在合理的职位,需要写“为何”而不是“做了怎么”。这仍旧挺考验写作者对程序的精晓的,需要有“同理心”,预见读者的急需才能够。

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

 图片 1

设假设函数、或者类的话,还足以写专门的文档:

图片 2

SAP系统作为店铺的音讯序列,其生命周期平日是绵长的,比单个程序员的在职时间要长得多。早期实施阶段花大气力开发的自定义程序,会交付给集团中间或外部的运维团队来维护——不管怎样,一般不是初期的开发者了。尽管是在运维阶段,程序的创设者与修改者也每每不是一个人。不同的开发者,其文化基础、技术水平、编码风格难免有所不同,最早创立的先后,经过若干个盖世的开发者的改动,可能会变得面目全非,失去可维护性。这时的次序可以说已经八九不离十于死亡…因而,作为程序的开发者,我们需要让祥和的顺序对修改有抵抗力,从而能在后人的保障下活的更久一些。

只是的解耦工作有可能让我们陷入为解耦而解耦的圈套。了然程序的任务分配可以让大家更为理性地利用技术,并且使程序对修改有更好的适应性。

本来,抵抗修改的意思,并不是指妨碍后人修改程序。公司的政工是形成的、人们对需求的领悟是连连强化的,因此程序的修改也是必要的。抵抗修改的对象应该是:在创设的要求变动暴发时,尽量让修改变得容易,并减小修改带来的毁坏,从而让程序能接受更频繁的改动。

术语表/词汇表

随时间和空中变化的,不仅仅是程序语言和人们的编码技术,业务语言和平时的交换语言其实也会改变。尽管在一个特定的本行领域里,总会有些我们都精晓的名词,然则在软件的生育过程中,关键用户、业务顾问、在此从前是用户/开发者/业务顾问的长官等人群,毕竟有着不同的背景和经历,对相同个词的了解也许并不等同(具体的原故或者是错综复杂的,这里不展开探究)。因为人们的交流是建立在这么不同的根底之上,所以有时就会难免发生误解和低效能的交换。大量的交换时间,往往会浪费在澄清一个基础概念上,有时仍旧因为误会造成一定的损失。这种景色在不同的团体/部门中间的互换中尤为常见,也特意有害。

高效能的互换应该以定义作为开端,而非以定义作为完结。为了落实这一目标,引入词汇表也许是个有利于的方法。倘诺需要描述、开发文档、测试用例等都应用约定好、定义明确的政工词汇,用户、业务顾问、开发期间的联系就不会有歧义,也可以避免某些人在写代码时胡乱命名。这样一来,就能更好地控制词的含义的一致性和生成。由变化引起的珍惜困难,便由此减轻。

 

没有哪位单一的方法可以保持程序的可维护性,它需要靠各地点的极力来推进。以上是本人的一对感想。也欢迎我们发布自己对可维护性的理念,或者对本文的情节开展指正。

 

中间层

在炮制与其它系统联网的接口时,由于各方面的原委,会时常遭逢对方愿意改变接口的输入输出情势或者格式的气象。这时候,不是一贯提供给对方包含业务处理逻辑的接口,而是建立一个外层接口,把原来的接口包装起来,专门用来回答对方的改动,是一个好法子。相似的笔触也足以用在其它平日转移的地方。

动态技术

动态技术是双刃剑,菲尔德(Field)(Field)Symbol和RTTS的利用可以使我们的次序变得不得了心灵手巧,但后果是先后的可读性平常不太好,而且对新手来说也断然是很难修改的。由此,我提议尽量把它看作基础效率的落实,和顺序中的硬编码、配置表相结合,或者是通过新建子类的主意来落实效益的恢弘,并且附以文档,表明程序的恢宏方法。尽可能避免让后人直接改动大气行使动态技术的先后。

 

本身觉得问题的关键在于裁减耦合度、理清程序职责的分红,清晰的程序描述也很重大: