工作日志十二 重构认识之一

    最近，在项目组里进行了大量的重构，也相互讲解了重构的部分技巧，对于项目处在拐

点，重构还是非常必要的。再好的理论和技巧，如果不能与实际的工作结合起来，就是没有意

义的重构。
    
    对于项目遇到的问题，有点浅陋的认识。现在项目已经升级新的大版本，正处在项目的

拐点处，以后代码还会随着需求的增加而增加，整个项目的代码维护起来有点吃力。吃力的原

因在哪里呢？

       第一，项目是由多个开发人员开发的，每个人代码编写的质量不同。现在，每个子系

统都是由一个开发人员负责维护。

       第二，需求并不是一成不变的，只要有新增的需求，代码就会往上累加。

       第三，代码的结构层次不太清晰，程序逻辑有点混乱。

       第四，代码中存在一些多余或者重复的代码，导致代码量太大。

       第五，代码的注释，体现不出程序的逻辑性。

       第六，代码的性能，还有优化的空间。

      项目出现这个情况，是该重构的时候。如果不重构，整个项目代码会非常的硬肿。

      在不改变现有软件功能的前提下，把代码重新组织结构。

      我们考虑从三个方面，去进行重构：

            （1）页面代码的重构

            （2）后台代码的重构

            （3）SQL语句的重构和优化

      在重构的过程中，利用了马丁福勒的部分技巧进行了重构，部分功能模块的代码量缩小

了一半。除了代码量缩小外，程序的结构层次更清晰，可读性也提高了不少。
     
      代码的重构，是一个注重细节的过程。把每个小功能模块，都仔细的优化到位，总体的

功能模块质量显而易见会有大的提高。代码质量提高了，后面的开发人员进行代码的扩展时，

理解整个业务都会比较快，开发的效率也会有大的提高。
    
     在重构时，我们往往把旧代码备份一下，避免新旧代码混杂在一起。为什么这样呢？记

得在一次项目重构中，由于旧的代码没有及时清除，导致代码没有及时更新同步，从而带来一

些额外的问题。
    
     对于一个开放人员来说，把重构做精做细，会加深对整个业务的理解和编码水平的提高。

     什么是好的编码？我的理解是编写的代码逻辑清晰，注释能体现出逻辑性，别的开放人

员接手代码，能很快的理解和容易的维护代码。编码的水平高低，不是体现在技术是多么高

深，而是在细节方面，做得到位就OK。

      做一个优秀的程序员，也不是很难，只要利用现有技术，把软件做精做细，就达到要求了。