当前位置: 首页 > 互联网, 观点 > 正文

代码重构的烦恼与乐趣

最近有一个系统需要所有的业务功能及代码,包括数据库结构都需要重新整合一下。当然,我可以将原有的系统逻辑不变的转到新的系统中。不过对于我而言,这种方式的系统整合,其一,对我的熟悉业务逻辑没有任何的帮助;其二,系统中原有不恰当的,或冗余的处理方式得不到纠正。我本人更加倾向于逐个业务功能的迁移与整合。也就是说,碰到哪一个业务功能,就将此业务功能对应数据库脚本,代码修改更新到新的整合系统中去。而且在这之中,对于那些不规范的命名方式,不合理的代码格式进行纠正替换;而那些最终未迁移的脚本很可能就是那些现在不使用的代码,而将其抛弃,保证整合后新系统的更易于理解与维护,系统更加健壮,至少命名变得更加规范。

纠正别人的错误往往会有满足感,但不断重复的纠正会让你越来越反感。在纠正的过程中我碰到以下值得去调整的问题:

1.重复代码,相同功能方法,在不同的业务场景重复定义

这类重复代码,是我非常讨厌的错误。比如,有两个页面功能有取到省份列表的,在两个页面单独写了两套相同的取省份的方法。一般来说,公共的方法我们只需保留一套就行,这样修改起来也非常的省心,而不用担心万一逻辑有变,遗漏了哪个页面的方法没有修改。这类问题也很容易重构,将这些代码放到一个通用类文件中,需要用到的页面调用该类的相关方法就可以。在.NET中,写成通用的静态方法是一个不错的解决方案,容易理解和调用。

2.命名不规范,名称表达的意思不准确

名称虽不影响代码的运行,但绝对影响代码的美观,会影响开发者的心情。一些拙劣的命名会让人感觉恶心。项目组最好有明确的命名规范,规定英文命名的就不要中英合璧,命名风格也要统一,罗列起来也非常的美观,当然好的名称要能体现功能的大致意义,让我看了就知道对应的方法是做些什么,更便于记忆。我在重构的过程中碰到这样一个名称很让人忍俊不禁:P_RPT_ReportAssetRFIDInstallSummaryrReport。这里有三个可以纠正的:1)末尾多一个’r’,2)有三个带Report的相关字母组合,3)由此带来的超长命名。好的代码名称,会让维护者更易于系统的维护。

3.代码格式不规范

代码格式其实只需要简单的学习就能掌握,但实践是一个不断坚持与改进的过程。简单的说就是要保证一定的代码格式,现在也有一些常用的代码格式化的工具,使用起来也非常的简单方便。代码格式其实也体现了程序员的编码风格,好的编码风格有统一的对齐与缩进,有丰富的逻辑注释。特别是在存储过程这种处理复杂业务逻辑的Sql语句中,格式对齐及简单的注释对代码的阅读是非常有帮助的。而且代码格式的规范是非常容易推进的,代码审查和代码格式调整并不需要花很多的时间,但对后来的代码阅读却有极大的帮助。

可能十个人会有十种代码风格,而功能名称的命名也可能会有不同。只要我们遵循代码易维护,易阅读的宗旨出发,肯定能将代码写的更好。良好的编程习惯也是一种编程能力,更是一种团队合作的能力。只有为大家所认可的代码才是更好的代码,而这种努力并非一朝一夕,更需要长久的经验总结与相互学习。看了这本书《重构:改善既有代码的设计》,相信会对你有很大的指引与帮助。

本文固定链接: http://www.byhard.com/?p=1159 | 海纳百川

该日志由 byhard 于2014年06月11日发表在 互联网, 观点 分类下,
原创文章转载请注明: 代码重构的烦恼与乐趣 | 海纳百川
关键字: ,

报歉!评论已关闭.