《Working Effectively with Legacy Code》阅读分享(一)
端午节开始看这本编程领域经典的书《Working Effectively with Legacy Code》，中文版叫《修改代码的艺术》。英文原版豆瓣评分9分，中文版8.2分。Amazon.com评分9.2分。 从评分上看，这是一本质量非常不错的书。中文版的书名翻译虽然少了点感觉，多了点俗气——现在书名动不动什么什么艺术，什么什么之道，甚至什么什么之禅，真是让人不知道该作何感想。但应该说，这个书名翻译得还是很准确的。因为这本书讲的就是如何修改代码！ 书的开篇讲了修改代码的四种原因： Adding a feature Fixing a bug Improving the design Optimising resource usage 对于前两种原因来说，改代码自然是理直气壮，没什么可以商量的余地。然而，对于后两种原因，通常就不是那么肯定了，甚至还有种policy叫做“If it’s not broke, don’t fix it”。这种policy之所以会出现，自然是有它的原因的。最大的原因，往往不是因为改代码需要时间，而是因为更改是有风险的，这种风险就是，你不知道你的更改是不是对的，更要命的是，你不知道你的更改会影响到其它的什么地方，会后带来什么后果。出于这种恐惧的心理，我们往往倾向于不到非不得已，就不去改代码。而这里所说的非不得已，就是添加feature和fix bugs。 然而遗憾的是，这种policy被一次又一次的证明，是行不通的，因为很快你会发现，你的每个类会写得越来越大，每个方法越来越长，结构越来越复杂，越来越难以理解，每次加一个新feature，fix一个bug都越来越困难。于是到了某个点，所有东西都必须推倒重写。这种事情在历史上发生了一次又一次。那怕不会到那一步，烂代码和烂结构也会严重的拖后正常的工作进程。 这种结局是应该被避免的，也是可以被避免的，怎么避免？那就是不要只顾着add feature和fix…