《重构》读后

caton2 2003-10-09 11:44:45

根据我对自己的要求，每读完一本好书都要写点心得感想之类。为此书的阅读画一个句号。其实一个多月前就看完了，但这一段忙着玩《仙三》及帮老婆大人做事，迟迟未写《重构》的感想。
这本书的封面上写着“与设计模式齐名的大作”，我认为它对的起这个评价。这本书对我的影响恐怕会和《设计模式》一样大。尤其难得的是，书中的英文及其浅显易懂，连我这样的超级大弱人都可以轻松阅读。也充分体现了大师的文字功力。
写一点关于重构的体会吧。
首先，我们必须知道怎样做是不好的代码，怎样做会更好一些。然后才能想办法把不好的变成好的。把不好变成好的过程，就是重构。
代码质量的提高是一个循序渐进的过程，没有最好，只有更好。我们重构前要权衡这次重构获得的利益与付出的代价。（正如我们常做的在灵活性与复杂度之间的权衡）。通常呢，为了实现新功能铺平道路的重构是我们最愿意去做的。
说到代码质量，其实在不同水平上的人对代码质量的要求是不同的。从最开始的只要代码能运行通就可以；到后面的符合编码规范；到后面的清晰易读；再到后面的易改变，可重用；以至于“有那种难以名状的结构美”。每个人在自己程序生涯的不同阶段，能体会到的东西是不同的。我一直把发现自己的不足，重构自己的代码称做“自我修炼”。而如果有一个水平比你高的同事帮你做CodeView，指出你可以改进的地方，你再去做Refactor，自己的修炼速度肯定可以更快。
这里，我要感谢一直在帮我做CodeView的同事。她有一种才能，可以敏锐的发现你设计上的不足。Kent Beck把它叫做“Insight”，就是洞察力。呵呵，不知道，这个东西能否随着工作经验的增长而增长。但愿可以，那我终于有一天也会拥有这种才能。：）
还是从重构开始的地方说起，就是发现哪里的代码是不好的。书中把它称为“Bad Smell”。回想一下，主要有哪些呢。1，Long Method，这个是我们最常做重构的地方。2，几个部分紧密耦合，存在不必要的依赖性。3，修改一项内容必须要协调的改几个不同的地方。4，类的职责不明确，逻辑关系混乱。5，Switch的使用。嗯，应该还有很多，记不清楚了。对了，还有，“重复代码”，记得有人说过重复代码是万恶之源。呵呵，万恶淫为首，重复代码为源。总之，很多人都深受其害亚。不过，我觉得重复代码的问题，应该从开始代码的时候就尽量避免，不要留到重构的时候再去做。就是说，当你准备Copy，paste的时候，先把要复制的代码提取成函数吧。
还有很重要的一点，重构一定要安全。XP一直在强调编码未动，测试先行。重构的时候有完整的单元测试支持，每走一步都会很有信心，很放心。但不幸的是，世界是有残缺美的，我们的自动测试往往并没有那么完备。这个时候，我们一定要对重构的代码有完全的理解与把握，而且重构一定要小心翼翼。尤其在重构其他人代码的时候，千万不要迷迷糊糊的就改。
嗯。时间不早，暂时就是这些。
前一段还翻看了一本讲软件架构师的书，其中有一句话印象很深，“每个人都是自己幸福的架构师”。以此类推，我们是否可以对我们的生活进行重构呢。：）

...全文