最近,在项目组里进行了大量的重构,也相互讲解了重构的部分技巧,对于项目处在拐
点,重构还是非常必要的。再好的理论和技巧,如果不能与实际的工作结合起来,就是没有意
义的重构。
对于项目遇到的问题,有点浅陋的认识。现在项目已经升级新的大版本,正处在项目的 拐点处,以后代码还会随着需求的增加而增加,整个项目的代码维护起来有点吃力。吃力的原 因在哪里呢?
第一,项目是由多个开发人员开发的,每个人代码编写的质量不同。现在,每个子系 统都是由一个开发人员负责维护。
第二,需求并不是一成不变的,只要有新增的需求,代码就会往上累加。
第三,代码的结构层次不太清晰,程序逻辑有点混乱。
第四,代码中存在一些多余或者重复的代码,导致代码量太大。
第五,代码的注释,体现不出程序的逻辑性。
第六,代码的性能,还存在优化的空间。
项目出现这个情况,是该重构的时候。如果不重构,整个项目代码会变得非常的硬肿。
在不改变现有软件功能的前提下,把代码重新组织结构。
我们考虑从三个方面,去进行重构:
(1)页面代码的重构
(2)后台代码的重构
(3)SQL语句的重构和优化
在重构的过程中,利用了马丁福勒的部分技巧进行了重构,部分功能模块的代码量缩小 了一半。除了代码量缩小外,程序的结构层次更清晰,可读性也提高了不少。
代码的重构,是一个注重细节的过程。把每个小功能模块,都仔细的优化到位,总体的 功能模块质量,显而易见会有大的提高。代码质量提高了,后面的开发人员进行代码的扩展时, 理解整个业务都会比较快,开发的效率也会有大的提高。
在重构时,我们往往把旧代码备份一下,避免新旧代码混杂在一起。为什么这样呢?记 得在一次项目重构中,由于旧的代码没有及时清除,导致代码没有及时更新同步,从而带来一 些额外的问题。
对于一个开放人员来说,把重构做精做细,会加深对整个业务的理解和编码水平的提高。
。
对于项目遇到的问题,有点浅陋的认识。现在项目已经升级新的大版本,正处在项目的 拐点处,以后代码还会随着需求的增加而增加,整个项目的代码维护起来有点吃力。吃力的原 因在哪里呢?
第一,项目是由多个开发人员开发的,每个人代码编写的质量不同。现在,每个子系 统都是由一个开发人员负责维护。
第二,需求并不是一成不变的,只要有新增的需求,代码就会往上累加。
第三,代码的结构层次不太清晰,程序逻辑有点混乱。
第四,代码中存在一些多余或者重复的代码,导致代码量太大。
第五,代码的注释,体现不出程序的逻辑性。
第六,代码的性能,还存在优化的空间。
项目出现这个情况,是该重构的时候。如果不重构,整个项目代码会变得非常的硬肿。
在不改变现有软件功能的前提下,把代码重新组织结构。
我们考虑从三个方面,去进行重构:
(1)页面代码的重构
(2)后台代码的重构
(3)SQL语句的重构和优化
在重构的过程中,利用了马丁福勒的部分技巧进行了重构,部分功能模块的代码量缩小 了一半。除了代码量缩小外,程序的结构层次更清晰,可读性也提高了不少。
代码的重构,是一个注重细节的过程。把每个小功能模块,都仔细的优化到位,总体的 功能模块质量,显而易见会有大的提高。代码质量提高了,后面的开发人员进行代码的扩展时, 理解整个业务都会比较快,开发的效率也会有大的提高。
在重构时,我们往往把旧代码备份一下,避免新旧代码混杂在一起。为什么这样呢?记 得在一次项目重构中,由于旧的代码没有及时清除,导致代码没有及时更新同步,从而带来一 些额外的问题。
对于一个开放人员来说,把重构做精做细,会加深对整个业务的理解和编码水平的提高。
什么是好的编码呢?
我的理解是编写的代码逻辑清晰,注释能体现出逻辑性,其他的开发人员接手代码,能很快的理解和容易的维护代码。
编码的水平高低,不是体现在技术是多么高 深,而是在细节方面,做得到位就OK啦。
做一个优秀的程序员,也不是很难,只要利用现有技术,把软件做精做细,就达到要求了