重构－－－Who are you?!

        刚刚看了小陆的我对系统重构的理解有些想法，就随便激扬一下文字,谈谈自己对重构的片面理解。               

          

Tip

   不要当你需要新的功能的时候，或者原来的程序出了Bug，你才想起重构。

       什么时候开始重构？这是首先需要考虑的问题。一个功能没有完成就开始重构吗？不是。所有功能都完成开始重构吗？更不是。重构是一项贯穿我们程序开发的工作，当一个功能完成（能够正常工作，通过单元测试）的时候就应该开始重构。既然都通过测试了，还要重构？没事找事啊你？呵呵，就是因为这个“没事找事”，一旦到了项目时间吃紧，或者程序员工作松懈的时候重构就被扔到一边了。（这个本人可是亲身经历过）直接后果就是程序质量越来越差，你越来越不想继续它的开发。

       现在你可能会问“既然测试都通过了，还有什么可重构的呢？” 对啊？ 我们重构什么呢？Bad Smell！《重构》那本书你看过了吗？它写的是什么？那本书的价值何在？介绍重构这门技术？告诉你为什么重构？错！那本书的价值就在于它把应该引起重构的Bad Smell一一列了出来，并给出了该如何重构解决这些Bad Smell的意见，不然那本书看一遍就可以扔了！重构的思想理解起来非常容易，运用好它就要靠经验了。Martin Fowler就把那些经验给了我们。ok，你觉得那个列表太长了？我给你一个Bad Smell－－－重复。什么时候你的代码中没有重复了，基本上你可以不要重构了。如果你的代码具有良好的可读性就更好了。
                                      
               

Tip

       最重要的也最常见的Bad Smell －－－ 重复

       重构不是一个可有可无的东西，一个好的程序员应该时刻把重构的想法放在脑中，只有通过不断的重构你才能开发出一个合格的程序。当然如果你把一个在某些时候，某些人手上能够工作的程序叫做合格的话，你可以关掉你的IE，别听我在这废话了。一个接口的产生，一个模式应用都可能来源于你的重构，什么叫模式在心中？通过重构在你的代码中浮现出来的模式就是最好的体现。

       重构不是小修改。重构过程中每小步都仅仅是一次小的修改，而当你完成一次重构，你会发现你的代码除了功能上还和以前一样，结构完全变了，原来的类没有了，新的接口出来了，多了很多新的类，原来的方法移到了新的类中，好似做了一次整容。不破不立！如果你的每次重构都是小的修修补补，要么就是你的预判能力太强，要么就是不会重构。呵呵，不要笑！笑的人多半是后者。兼容性？ 老兄，你的系统还没开发完呢？你跟我谈兼容性？ 

            

Tip

            不要怕你的重构把你代码变的面目全非，要单元测试干吗的？

      你听说过测试驱动开发（TDD）吗？你知道什么是TDD吗？ TDD中最重要的是什么？ 测试？错！TDD最重要的就是重构。TDD的本质就是不断的重构。测试是用来保证重构的安全性的，是为重构服务的。
      你知道什么是面向对象吗？接口！ 你知道什么是TDD吗？重构！
    
       
觉得太理论了？下面是一些我的亲身体会:
1. 重构已经成为我开发中不可缺少的部分。
2. 在前段时间的一个开发中，前期由于客户没有给太多的时间压力，我重构的频率很高，设计也越来越让我满意。而到了项目后期，每天都规定了必须完成多少多少功能，使得我的重构大打折扣，而且由于长时间的投入于一个项目，也使得我对重构有了厌倦。因为项目做的好坏对我没有非常直接的利益。如果没有太多的压力，并且对我的“完美”表现有更多的鼓励和支持我会做的更好。
3. 由于项目涉及UI（几乎没有哪个项目不涉及UI）， 使得我在重构的过程中一点安全感都没有，这也是严重制约重构的一大因素。 如果有更好的测试小组或者更好的UI自动化测试框架也会让我能更加大胆的重构。


相关文章：

一个画图程序的演变
测试驱动开发 --- Rss Reader Item Marker

一点废话：
说到Refactory .呵呵，最近还冒出来一个Prefactoring，不过这个书名估计是为了迎合市场，没什么新意。不过书写的还不错，想体验一下怎么从头开发一个程序的建议看看。不过我估计它获不了Jolt. Jolt提名里的那本有关SOA的书倒是不错，想了解SOA强烈推荐。