`
terrencexu
  • 浏览: 121530 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

工作两周年纪念日 - 随笔 (2)

阅读更多

        接着昨天的继续聊《工作两周年纪念日 - 随笔 (1)》,在工作的这段时间里,经历过很多事情,零零散散的总结过,但从没想过像现在这样把一些散碎的片段记录下来,偶然间写了一点儿之后,才发觉还是蛮想记录下自己的一点点儿过去的,记得多了,以后回头看看,看看现在有点儿傻的想法,或许可以让自己心情愉悦一些。

 

        谈重构

        刚开始接触重构是在大四实习的时候,那是一段非常美妙,直到现在也总是会渴望回到的时光,那时候自己算是刚离开校门,从来没有接触过重构和设计模式,后来项目进展了大概一个多月之后,老大说我们要花一段时间重构一下我们的代码了,这是“重构”第一次出现在我的耳朵里,再到后来慢慢的又接触设计模式,甚至斥巨资买了一本《Java 设计模式》,抱着狠狠的啃了一段时间,每天都过得极其舒坦,每天都有一种发现新大陆的感觉,呃,有点儿夸张了,哈哈,但是的确是很兴奋的。

        提到重构就会有一个问题需要解决:应该多久重构一次?这个问题在项目组里讨论过很多次,每次大家都能达成共识,但是真正付诸实施的却没有几个人,这不得不说是一种悲哀。我个人提倡的是每两天进行一次个人重构,每周进行一次项目组的重构,小范围短期的重构可以有效的避免坏味,避免事态扩大化,因为我们很习惯的一件事情就是将就将就,这种可怕的将就日积月累,就会导致每次解决一个新需求的时候都需要绕很大的弯去满足之前的设计,整个项目的架构越来越难维护,越来越难扩展,最后导致几个月之后不得不抽出很长一段时间进行重构,如果到这个时候才开始重构的话,你所面临的问题就已经超出了重构的范围,因为你的代码完全腐烂掉了,腐烂到再不搞搞就没法继续进行下去了,但是这时候的重构的风险很大,因为你已经有很多鸡零狗碎的需求加进去了,打了很多个补丁,到处都是疮疤,你不定会遗忘哪一个,而且能把Test Case写到每个小的功能点的还不是很多;另外你真的是无从下手,这时候你很难找到一个好的出发点,不知道从哪个类开始,不知道从哪个方面开始,有时下定决心开始干了一星期之后,你发现真的是太难了,实在是弄不下去了,于是继续和稀泥,继续打补丁,继续为了加入一个小小的功能,花上几天几夜的时间,那真是痛并快乐着,个中滋味,估计只有你自己能体会了。

        那为什么我们不能在项目一开始的时候就注意这个问题呢,这个时候又得有一帮子人站出来说工期紧,没那么多时间。好吧,如果你认为每两天抽出半个小时,每周五抽出1个小时,总共两个小时的时间是浪费的话,我也真得算笔账了,每周耗时2小时/人,每个月耗时8小时/人,就是一个工作日,一年总计耗时12个工作日,你有没有把握在年终的时侯能用12人天的时间把这一年的代码重新捯饬一遍呢,这不仅仅是弄你自己的那部分代码,还包括跟同事集成,包括接口的重新定义,包括各种补丁重新归入正统,包括所有的Test Case能全线飘绿,如果你敢保证12天的时间把这些都做得很好,那真得是很厉害了。

        那我们该什么时候进行重构呢?

        1. 当你在为了扩展一个功能不得不拐弯抹角的去迎合以前的设计的时候发现,即使是很小的功能。

        2. 当你在很多做相似事情的类里面,反复的敲同一段代码的时候。

        3. 当你为了方便的使用一个‘工具类’,而想把它做成其他使用这个类的超级父类的时候。

        4. 当你发现这个类的很多职能貌似不属于这个类的时候。

        5. 当你已经意识到要做国际化而还没有把所有的文字抽取到message.prop中的时候。

        6. 当你发现很多标签上都写着style=""的时候。

        7. 当你你发现HTML文本里有很多CSS/JavaScript的时候。

        8. 当你发现这个方法只是需要传递一个用户名和密码而你却传递了整个用户对象的时候。

        以上只是列举了一些比较通俗而又不太容易让人上心的几个诟病,如果想全面了解重构的知识的话,可以买一本伟大的Martin Fowler写的《重构-改善既有代码的设计》,这里面列举了很多经典的代码坏味,可以有效的改善代码的品质,然后自己慢慢的小范围的在项目里应用,相信会让你体会到他的用心良苦的。

        通过慢慢的改进自己的代码,总结一些经验教训,那么下次再设计同一类型的功能模块,甚至整体架构的时候,都会让你主动的注意和避免一些可预见性的问题,慢慢的你会发现你不用再每两天抽出半个小时的时间重构了,而是每天抽出10分钟就可以搞定,那到这儿为止,如果你每天抽出十分钟时间就可以让自己的代码变得更漂亮的时候,我相信这10分钟已经不是什么累赘了,反而是一种午饭之后,看新闻之前的一种惬意的享受了。总而言之,牛逼的架构师不是一开始就能预见未来的,不经历几多挫折,不经历沉思总结,是不太可能成为伟大的工程师的,当然喽,还是那句老话,如果你是天才,那拦也是拦不住的,呵呵。

 

        《未完待续 ...》

1
1
分享到:
评论
2 楼 yss1209 2010-07-09  
等该你的下一篇文章
1 楼 rogerer 2010-07-09  
Conclusion is very important for everyone.You did it.
UP!

相关推荐

Global site tag (gtag.js) - Google Analytics