如何修改你的程序?《重构:改善既有代码的设计》
[复制链接]
重构:改善既有代码的设计
这是一本有关软件开发方面的不朽经典,值得认真阅读并收藏!
这本书书凝聚了软件开发社区专家多年摸索而获得的宝贵经验,拥有不因时光流逝而磨灭的价值。今天,无论是重构本身,业界对重构的理解,还是开发工具对重构的支持力度,都与本书最初出版时不可同日而语,但书中所蕴涵的意味和精华,依然值得反复咀嚼,而且往往能够常读常新。
第一次听到“重构”这个词,是在2001年10月。在当时,它的思想足以令我感到震撼。软件自有其美感所在。软件工程希望建立完美的需求与设计,按照既有的规范编写标准划一的代码,这是结构的美;快速迭代和RAD颠覆“全知全能”的神话,用近乎刀劈斧砍(crack)的方式解决问题,在混沌的循环往复中实现需求,这是解构的美;而Kent Beck与Martin Fowler两人站在一起,以XP那敏捷而又严谨的方法论演绎了重构的美——我不知道是谁最初把refactoring一词翻译为“重构”,或许无心插柳,却成了点睛之笔。
我一直是设计模式的爱好者。曾经在我的思想中,软件开发应该有一个“理想国”——当然,在这个理想国维持着完美秩序的,不是哲学家,而是模式。设计模式给我们的,不仅仅是一些具体问题的解决方案,更有追求完美“理型”的渴望。但是,Joshua Kerievsky在那篇著名的《模式与XP》(收录于《极限编程研究》一书)中明白地指出:在设计前期使用模式常常导致过度工程(over-engineering)。这是一个残酷的现实,单凭对完美的追求无法写出实用的代码,而“实用”是软件压倒一切的要素。从一篇《停止过度工程》开始,Kerievsky撰写了“Refactoring to Patterns”系列文章。这位犹太人用他民族性的睿智头脑,敏锐地发现了软件的后结构主义道路。而让设计模式在飞速变化的网络时代重新闪现光辉的,又是重构的力量。
在一篇流传甚广的帖子里,有人把《重构》与《设计模式》并列为“Java行业的圣经”。在我看来这种并列其实并不准确。实际上,尽管我如此喜爱这本《重构》,但自从完成翻译之后,就再也没有读过它。不,不是因为我已经对它烂熟于心,而是因为重构已经变成了我的另一种生活方式,变成了我每天的“面包与黄油”,变成了我们整个团队的空气与水,以至于无需再到书中寻找任何“神谕”。而《设计模式》,我倒是放在手边时常翻阅,因为总是记得不那么真切。
|