Why we need refactoring?

    其实最近两三个月，我感觉有差不多一半的工作时间都放在了Refactoring相关的方面了。然后又看了本新书《修改代码的艺术》。我想我对于重构滴理解应该说是越来越深了。
    其实在前些日子，我曾经有过苦恼(见在JavaEye发的帖子)，发现自己总对一个具体的地方重构，不断的重构，而一直没有达到让自己满意的境界。所以约重构约觉得苦恼，然后最后终于让人有一种喘不过来气的感觉。然后记得和gigix聊过一次天。他给我发了一段他和他同事的聊天记录，我看了之后感觉舒服了许多，然后自己又寻思了寻思，感觉心情一下豁然开朗了。很可惜，前阵子，系统坏掉。貌似把那段对话给弄没了......所以想想，那就写篇blog吧，省得万一将来某天完全忘记之后再次因为这郁闷。我的脑袋确实有时候忘性大的厉害。

    先谈谈下为什么我们需要重构呢？因为据说每个软件的成本，有相当相当大的一部分都出在维护上。无论是现有软件的fix bug，还是添加新的feature，都是需要在原有的code base上进行更改，添加之类的。所以原来的code base写的好坏对于将来的修改成本来说，就是至关重要的了。而基本上，软件没有不修改的，基本上从开发的中后期就要会出现大量的bug需要fix，然后将来的发布，升级，基本上都是和原来的代码质量息息相关的。而refactoring，就是在不更改原来的业务逻辑和code所具备的行为之上，对code内部进行的一系列的调整，使code质量更高，更易懂，更方便将来的修改，继承，复用。等等。

   所以说，这就是重构的目标，那么既然原因和目标都定下来了，实施起来的度也就好把握了。只要估算重构的成本+重构后代码的修改成本是否小于不重构代码的修改成本就好了。如果前者比后者的成本要小，那么说这样的重构就是有意义的，就是成功的，在商业上来说，就是有价值的。否则，在商业上来说就是一种浪费了。

   但其实要想仔细具体的评估两者时间的成本情况，我觉得还是比较难清楚的划分出来的。更重要的就是一些经验了。譬如如果说代码中嵌套了两三层unless，那么我感觉就不如改成if划算。因为if还是更为常见，将来别人读取来，理解也更为迅速。因为绝大多数语言都有if，所以大部分的程序员更容易接受if，而不是unless。然而如果要把这几个unless改为if的话，如果花费半个小时的功夫，应该是值得的。但是如果花费一礼拜的时间来寻思到底是改为if呢，还是保留unless呢，还是这样那样的。那么明显的，我感觉就不值得了。

    其实我觉得我曾经那段时间自我郁闷的问题就处在这里。我没有想明白refactoring所带来的价值，而纯粹的陷入到代码的细节中去想，究竟是A方案，还是B方案。其实有时候两者的差别并不太大，也许A方案只比B方案好一点点。如果这种情况下，我却花费的更多更多的时间来思考究竟是A还是B的时候，如果这个时间花费超过了A比B方案好过的时间成本。那么，应该说，这次重构就失败了。所以很多情况，我觉得重构的时候，一定要想清楚，到底重构是干什么的。最主要的是为了节约将来修改的成本，而不是说让code达到完美无缺的境界。毕竟，完美基本是不可能的，不管任何事物都没有什么完美的。而，把握好那个度才是至关重要的。