重构

*引用本文请注明来自 blog.csdn.net/wtz1985 
    重构,从字眼看来,是一个比较抽象而且是相当泛的词。对于很多程序员来说,也许对它比较熟悉,看过很多,也听过很多,可是想要给它一个具体的定义,是比较困难的。当然,它的困难不是在于中国的文字难于琢磨,而是在于它的思想。

    重构的主要目的,就是为了使代码更加简洁、让框架更加清晰、运行的速度更加快。也就是说,在编写代码了之后,在不更改外部代码的前提下,通过修改内部结构 的代码来改进代码的整体质量。从语言发展的历史可以看出,从低级语言开发到面向对象的开发,重构在这个成长过程中,扮演着越来越重要的角色。因为重构可以 加强代码的健壮性、可读性,更重要的是保持了模块间、接口间的相对独立性。不会因为修改了某一处代码,因为其之间的紧密依赖令其他代码无法执行,甚至导致 了整个系统零乱不堪。

    所以,怎样能使一个大型的程序健康的发展,从重构的思想看,首先就得看你给它什么样的框架了,你的框架能放多少东西,而且在放的过程中,会不会因为某一模 块或者某一个接口的进入,伤害到其他模块的正常运行,甚至是崩溃。要保持模块间的相互独立性,尽量的降低里相互依赖性。所以,“封装”这个词眼贯穿了整个 程序的始末。

    什么时候重构合适呢?这是一个不好具体定义的时间。简单地去讲,当在你的程序中,你第一次写了这些代码,可是在另外一个函数体中,又再次写了这些代码,也 许你这时候还可以忍受它的重复,可是当它第三次要求你去写的时候,你就得考虑该时候了。减少代码的重复也是重构思想的一个具体体现,这可以减少代码的冗 余,达到代码的简练境界。

    还有,当你在一个实现函数中,如果写了很多行代码,这时候也可以考虑怎样去重构。因为在很长的函数体内,往往会降低代码的可读性,而且代码的层次感也是比 较差的,同时会减弱了代码的相对独立性。如果某一行代码有着较为特别的意义,让它独立成为一个函数也是绝对支持的。虽然函数体多,在看代码的时候,切换上 下文比较累,可是多费点我们的头部运动时间,保持了代码的健壮性也是值得的。

    代码的重构没有时间表的安排的,要随着代码的成长,需要不断的检测,不断的思考它是不是该重构了,可不要等到代码累积到了连你见了都掉头跑的时候,才想起 重构,那真的是有点迟了。其实一份好的代码,就是功能不影响运行的情况下,不断重构,不断改进的,而不是一气苛成。

    有一个好的建议,就是我们在看别人代码的时候,要思考一下,他的代码是不是需要重构呢,重构了之后,会不会提高性能呢?还有把各个接口和模块,用图画出来,考虑它们之间的联系。

    最近在看书的过程中,看到这么一个方面,就是说一个团队在编写一个大型的程序时,从框架看是没什么问题的,可是就是运行时间比较慢,优化了还是提高不了其 速度,后来请了另外一个专业的团队过来,帮忙,后来的团队编写了一个性能测试工具,发现在这个程序中,有大量的重复字符串赋值、分配、释放,导致影响整个 运行速度。知道了这点之后,进行修改,这个程序的速度才大幅度的提高。就这点而言,我们在编写自己的代码时,是不是也该时时考虑呢???

    今天的重构就说到这,有什么不好的请提出来,我还是那句话,目前我是一位刚出炉的“裸体”程序员,请多指教。

你可能感兴趣的:(框架,优化,语言,测试工具)