« 早晨的空气真清新~~~ | Blog首页 | 我看目前流行的flash电子杂志 »
2006/01/24
“重构” -- 每个程序员和项目经理都应该读的经典
刚刚读完“重构”（Refactor）这本书。 这是一本大师级的编程书籍， 也是一本完全是面向实践（而不是枯燥理论）的书， 参考书中的方法可以立刻开始实践并且收益。 书中一些观点，从我们的现状以及我自己的经验来看，是非常有价值的。
“重构”，简单来说就是改进代码， 让代码更“优美”、更清晰、效率更高，并且不改变程序员来的外在表现。
很多书中的观点表面看很简单，但可能只有尝过软件开发的酸甜苦辣、 和各种各样的人一起配合过项目的程序员才能真正地明白。 但无论有教训还是有经验， 看到这本书后立刻开始，都会受益匪浅。
一些很精彩的观点（非摘录，回忆和自身感受写的，未必和书中完全一致）
＊ 很多项目在初步的设计中结构是优良的，代码品质是优秀的，但所着项目不断进展...需要在变、人员在变... 结构越来越不适合现状，代码质量越来越差... 最后变成一个勉强能完成工作的垃圾堆. 事实，多少漂亮的软件的背后其实就是代码垃圾堆！
代码品质的腐化现象在现实中非常普遍而且情况很严重。 这种情况下，需要的就是重构！ 不断重构，才能让代码不断保持优雅，保持效率，保持可维护性。
我们uuzone app的代码显然需要进一步重构。
＊ 重构导致花费额外的时间，这是必然的，但经历过失败项目惨痛教训的人，维护过被大量copy/paste充斥的垃圾代码的人， 一定会相信重构其实节省了项目的时间！ 我相信这点。
想想我们曾经在项目中被迫抛弃了多少垃圾代码？ 曾经因为个别炮制垃圾代码的家伙又额外花费了多少时间？
那些说“不行，我们项目现在太紧迫了以至于我只能写这些#$%^&代码”的家伙，不是借口，就是应该从项目中淘汰出去的人。
＊ 从编程中跌滚摸爬成长起来的人往往会看重前期的设计，但常常会矫枉过正 －－过分看重前期设计， 把后期的编码看成“蓝领”工作。 但多少早期的设计能考虑１００％完成？ 系统稍微复杂些，恐怕就没人能做到。 所以编码后的重构就是对前期设计的不断调整和优化。
作了项目经理的你，是否认为编码其实很低级？ 认为哪些东西只要设计好了就可以交给印度人去玩了？ 如果是这样，那么要小心，最终得到的可能是一个掩盖在精良设计下，也许还能完成功能的小型垃圾堆。
－－
什么时候需要重构？ 书中给出了Smell of code的很多情形，更重要的是，这本书的最大好处就是作者总结了很多典型的需要重构的情形，以及推荐的重构办法， 读这本书，就如同在读“数据结构”、“设计模式”那样，文字中充满了智慧，充满了实用和经验。
－－
我觉得重构这个词翻译的并不好。 英文名是"Refactor", 而不是“Restrcut”. 其实refactor是一个小规模的动作，至少是每步是一个小规模的动作，因为refactor的目的不是要推翻全部东西，而是把原来的东西优化，在优化的同时，通过一些谨小慎微的方法来减少因此而引进的bug的可能。
很多时候，很多人（包括我自己）经常会在看到一堆垃圾不堪的代码和项目的时候，愤然、或者绝望地希望推翻重来，或者另起炉灶。 读完这本书，加上过去的经验教训，让我有了另外的看法， 一个项目是彻底就是垃圾，还是由于“腐化”的原因导致了一些垃圾的出现？ 其实一个项目只要不是一群傻瓜弄得，而且还能运行， 就不应该全盘否定。 也许垃圾的只是一小部分，当往往被急躁的程序员和项目经理给放大化了。 其实也许做一些refactor, 项目可以变成一个精巧优美的结构！
老冒
发表于
2006-01-24 16:36
阅读(5060)
评论(
1)
引用(
2)
老冒观点
所有人可见
- 收藏文章:
相关内容
回复列表每两分钟自动刷新一次，想立即刷新吗？点击这里
