关于程序可维护性的一些想方设法

开源工具

开发人员在工作中可能会见用有的类库,有时人们见面好写类库。在投入时自己写类库之前,可以先找找是否在现成的优良开源工具。因为个人的物或会见为文档不齐或者人员更改变得无人能理解,也会于新人比较充分的学成本。而好的开源工具的精力更胜似有,也出再度多同行知道该怎么用。

以,很多口以描写用OLE生成Excel的先后时会进展一定之包装来拍卖麻烦的call
method
of语句。在这基础及,人们见面形成各自的包裹方式,阅读彼此的OLE程序时,就可能只要花点时间来观察对方以包装习惯及之细微区别。但是,如果能够采用XLSX
Workbench当即无异于得天独厚的开源工具,大家就好透过了一样的方式生成Excel。它应用起来大概、性能良好,并且(在大部景象下)可以避免写维护起来累的OLE代码。

Visual Studio 2017 于2017年10月13日宣告 15.4
版本。该版包含多项生产力改进,支持 .NET Standard 2.0 ,并且可被
Xamarin Live Play 预览了。具体的发行信息,可以查 Visual Studio 2017
Version 15.4
Released
。本站第一时间跟进了离线安装包的打,并叫今天发表。

止的解耦工作出或被咱们陷入为解耦而解耦的牢笼。了解程序的任务分配好为咱们越理性地行使技术,并且使程序对修改有双重好的适应性。

下载地址

链接:https://www.coderbusy.com/archives/893.html

擅长异常

充分是单大有因此的物,但是我好少看到出ABAP开发者用它。我来看的多数顺序用错误码或者失实标识的措施来处理错误。以自我之阅历来拘禁,错误码在单层的调用关系蒙是较好用之,但是以差不多叠的、复杂的景下,异常比错误代码要还爱处理以及维护。而且充分有着比较好的自我描述能力,这当次的保障着是可怜有意义之。而多错误码是只有的魔法数字,只有开发者本人知道凡是什么意思,后续维护的口在观错误代码时,只能认识及:这里来只错误…并无懂得每个错误代码的涵义。

分卷包校验信息

 

文件:
D:\mu_visual_studio_2017_enterprise_15.4.0_20171016.7z.001
大小: 8522825728 字节
修改时间: 2017年10月18日, 23:39:09
MD5: 61710309D7AE5AD2A5B669537005CFD8
SHA1: 9637B3B0823EC22F790A4C4A1195B4295A18ECD5
CRC32: C2BDC6C9

文件:
D:\mu_visual_studio_2017_enterprise_15.4.0_20171016.7z.002
大小: 8522825728 字节
修改时间: 2017年10月18日, 23:39:09
MD5: 912EF2307B735A13DA6EC7DE2CEAF345
SHA1: F985824B1A40AF8D806EE4A12A2DEE96E7AFD627
CRC32: 30DA148D

文件:
D:\mu_visual_studio_2017_enterprise_15.4.0_20171016.7z.003
大小: 8522825728 字节
改时: 2017年10月18日, 23:39:09
MD5: 06EABCE986DBC1B7895B4CA95D5FE5B5
SHA1: A332683C77B0830210ABD2F099B8741F497E18A1
CRC32: 99A3E7B5

文件:
D:\mu_visual_studio_2017_enterprise_15.4.0_20171016.7z.004
大小: 8251480952 字节
改时: 2017年10月18日, 23:39:09
MD5: D8474DF6896C7120A8AAE94E8F9A9D12
SHA1: EDE6E2855BD9BF238DC4C32DAFC0749573B16D47
CRC32: BFFB472F

理所当然,抵抗修改的意,并无是据妨碍后人修改程序。企业之事务是形成的、人们对需求的了解是频频加深的,因而程序的改为是必要的。抵抗修改的靶子应该是:在合理之需求变动发生时,尽量吃修改变得爱,并减弱多少修改带来的毁坏,从而让程序能够经受更频繁之改动。

分发校验信息

文件: D:\mu_visual_studio_2017_enterprise_15.4.0_20171016.vhd
大小: 36910612480 字节
改时: 2017年10月18日, 21:57:38
MD5: A241422963090D1B4DC7EA7A42F15AC4
SHA1: 69A18D9DBB10832E360D0CDA31CB862B8217388B
CRC32: 9D93A4F9

下结合实际的ABAP开发技术来谈谈自己本着其的想法,因为只有是基于自己的有的历的来形容,可能未是系统全面的牵线。

本离线安装包用官方原版程序配合 layout 指令制作,包含 Visual Studio
2017 Enterprise 15.4
所有组件和所有语言包。因最终包体较充分还文件称于丰富,所以用 vhd
格式分发,尽量减多少最终占用空间。

免全局变量

全局变量不好,这是持有开发者的共识。之所以专门还要用出她来作一个小节,是盖我当这题目实际上普遍还严重。可能因大部分ABAP二次开发程序都是内容比较少之报表,最常用的ALV报表类(函数)则要求该输入的数目内表必须是全局变量,初入行的开发者通常是从全局变量写起底,而比较简单的程序逻辑也给开发者没有经受全局变量带来的麻烦….这种惯性使得许多开发者在其后出相对大型的主次时为会见大方动全局变量。而先后的跟随者通常没有生命力要力来甄别全局变量对程序的震慑,从而以窜程序时造成了预想之外的结果。此外,不加以释放的全局变量也会带性能及的担当。所以我道开发者应该时时想是否好为此有变量代替全局变量、用价传递代替引用传递,时时在意避免全局变量带来的累。 

术语表/词汇表

随时间和空间别之,不仅仅是程序语言和众人的编码技术,业务语言与一般性的交流语言其实呢会转。虽然在一个特定的行领域里,总会有些大家还懂得之名词,然而当软件的养过程遭到,关键用户、业务顾问、从前凡用户/开发者/业务顾问的长官等人群,毕竟有着不同之背景和更,对平个词之理解也许连无相同(具体的由来可能是纵横交错的,这里不展开讨论)。因为人们的交流是起于这么差之根基之上,所以有时就是见面难免产生误解和小效率的交流。大量之交流时,往往会浪费在澄清一个基础概念上,有时还是为误会造成一定之损失。这种气象在不同的集团/部门之间的交流受到越常见,也专程有害。

大效率的交流应该因为定义作为开头,而非为定义作为完结。为了落实这无异于靶,引入词汇表也许是只方便之计。如果急需描述、开发文档、测试用例等都采用约定好、定义明确的工作词汇,用户、业务顾问、开发期间的牵连即未会见生歧义,也足以免某些人于描绘代码时胡乱命名。这样一来,就会重复好地控制词的含义的一致性和转变。由变化引起的护困难,便通过减轻。

 

并未孰单一的艺术能够维持程序的可维护性,它需要借助各个面的用力来推动。以上是我的一些感想。也接大家发表自己对可维护性的见识,或者对本文的情进行指正。

 

硬编码与配置表

随即两者的原理在将对准先后的修改变为“扩展”,在无干涉或于少干预程序代码的状态,完成功能的变更。如果程序的读者看到了先后中之枚举或者常量,那么他虽会清楚这些东西的修改会招致什么的熏陶。一个吓的命名可以协助读者知道它的意向。

ABAP
7.51着引入了枚举对象,它于落实程序中之数据的一致性有好好的协助,相比常量而言强大许多。在同样之场合,可以考虑是不是可以用枚举来提高可维护性。

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

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

耦合度即模块之间的干强度。高耦合度的主次牵一发而动全身,只抱给需要特别平静的次第。对于形成的ABAP程序来说,降低耦合度可以减程序修改对另一些的熏陶,是于主要之。

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

次的讲述包含命名、程序结构这种“自我描述”,也包括程序注释、技术文档,以及需要文档。这恐怕是极其轻改善的一个方面。

动态技术

动态技术是双刃剑,Field
Symbol和RTTS的运可假设我们的次第变得甚心灵手巧,但结局是程序的可读性通常不极端好,而且对新手来说呢决是殊麻烦修改的。因此,我提议尽量将它作为基础功能的兑现,和顺序中的硬编码、配置表相结合,或者是通过新建子类的措施来兑现效益的壮大,并且附以文档,说明程序的扩充方法。尽可能避免为后代直接改动大气使用动态技术的先后。

 

自我认为问题之关键在于减少耦合度、理清程序职责的分红,清晰的顺序描述为特别重大:

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

形容来意义之笺注

据称写序不写注释是平等种植好不好之惯,也起出规范约束人们:必须使描写注释。注释当然是必需之,但是在实践中,大部分人的注解水平是匪极端好的,往往针对读书起无交什么正面作用,于是甚至催生了平等栽反叛的、矫枉过正之意:好的次第没有需要注释。

近期看的一个榜首的坏的诠释:

*处理数据
PERFORM frm_process_data.

当下段代码至少犯了3单错。

  1. 要因为文章来对待,FROM的讳就是是文章的标题,我们无应当当题目中形容清楚标题是标题。显然,FRM的前缀是行不通的,它于无了咱们什么信息。
  2. “处理数量”似乎是对准FORM功能的叙述,这有的情应该在FORM的定义处,而未是调用位置。在调用位置的笺注,需要写的凡:为什么这FORM需要以此地让调用?为什么不是调整用外一个拘禁起相似之FROM?
  3. 当诠释中形容“处理数据”这种肤浅的辞通常有不了哟意思,更不要说FORM名已经是process
    data(处理数量)了。这种还有害无益。

这么的诠释了多,大概就是是广大人数反感注释的由来吧。好的注释需要出现于客观的职,需要写“为什么”而未是“做了什么”。这尚是那个考验写作者对程序的晓的,需要来“同理心”,预见读者的急需才好。

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

 图片 1

若是函数、或者类的言辞,还可形容专门的文档:

图片 2

中间层

每当做和外系统连接的接口时,由于每方面的原由,会时时遇到对方愿意改变接口的输入输出方式或格式的景。这时候,不是直提供给对方包含业务处理逻辑的接口,而是建立一个外层接口,把原来的接口包装起来,专门为此来对对方的改,是一个吓方法。相似之思绪也得以就此在其他经常改变的地方。

发表评论

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

网站地图xml地图