漫谈重构

这个话题其实蛮大的。不过呢，我也就是随便聊聊，抱着不科学严谨的态度，权当茶后谈资。如有所获，自当欣喜。若有分歧，还望一笑而过。

进入这一行了也有几年了，面试的时候，经常会谈起重构和架构这两个话题。架构呢，我觉得是自上而下进行的，重构则是自下而上进行的。刚开始，大家会根据已有的经验和现有的项目堆砌出一个“架构”出来。随着项目的扩大，和不同人的经手。现有的架构几乎可以称之为挂在奔驰车上的牛车架子，虽然各方面不停的加固拓展以适应现在的环境，但是总不如推到重做来的实在。当然了，公司可以说是不允许这样的事情出现的。那么呢，重构则是可以改善现有状况的一种方式，虽说没有直接推到来的迅速彻底，但最起码还有所用处。

再说重构，我认为的重构不需要专门抽出大量的时间去做，只需要在头脑清醒，偶的闲暇，兴之所至，改个一两行代码就可以了。同时它也是旷日持久的。

随着项目扩大，如果不时时改善现有代码，那么代码就会越来越难以维护，因为各种原因导致的现有代码难以理解是维护的最大问题。而重构的最主要目的就是为了是代码能简洁易懂。不光是自己懂，而是让其它人也懂。这样当出现问题的时候，老板最起码不会打电话把休假的自己叫回公司。

现在的IDE还是很智能的，可以给予我们相应的提示，我们尽量按照提示去做，这样就可以完成相当一部分工作(这一步其实就很多人没有做到，更不要说后面的工作了)。其次我们可以利用各种检查工具来检查代码。再更进一步的话就是对各种类之间的依赖关系，接口直接的依赖关系进行改动了。甚至可以对模块之间的依赖进行变动。当然这需要消耗更多的精力和时间。

常常有人会在写代码的时候会以项目紧为理由来用不是自己能力所能做到的最好实现方式去完成工作(这个其实和公司，和项目有关，总不能让天天加班到半夜的人去想怎么做最好吧...)，但是在项目上线后能还记得回来优化代码的人往往少之又少。

重构是提高个人能力的一种方式，虽然他不能让我们知道更多的API--学习是个人的问题，与公司无关。

总的来说，写出简洁明了的代码，写出大家都能看懂的代码是我们大家应该共同努力的方向。暂时就先这些吧。