围绕重构来阐述如何修改遗留代码的不错的书
这本书看的时间非常长, 断断续续有3个星期了吧, 不错的书, 至少对我来说是这样, 因为我现在就碰到了书中列出的种种问题:对已有的没有完善的单元测试的核心系统进行重构.为了保证少出乱子, 不出乱子, 我必须小心的对超大类, 巨型方法采用各种重构手段进行修改, 没有单元测试作保证的系统进行重构是非常危险的事儿, 那怎么办呢, 这本书让我知道了不少好的方法.
与<重构到模式>一样, 这也是一本围绕重构来阐述如何修改代码, 只不过它面对的场景是遗留系统.对遗留系统进行重构首先要做的就是要让我们的修改能够被单元测试用具夹住, 就像对一栋居民楼进行改造一样, 必须先安装脚手架, 拉上防护网, 做好安全措施, 然后再开工. 从而减少因为修改带来的风险.
如何在修改代码前搞定对应的单元测试呢?这是一个非常有技巧的活儿, 因为遗留系统可能因为设计不佳而无法或者很难非常容易的为其修改部分添加单元测试. 之所以造成这样的局面一个重要的方面是无法对要测试的部分进行解除依赖. 因此解除相关依赖也就成了修改代码首先面对的一个难题, 本书在解除依赖方面总结了非常多的方法(或模式), 这些方法总有一款会适合你. 本人觉得这应该算是这本书的所要告诉我们的主要内容吧.
本书的例子大部分都是以java为主, 少量的穿插了c++的实例, 而且有些手法跟语言的关系比较大, 可能适用c++的做法, 对java并不适用.
另外本书给我的另一个启发就是, 我们在写代码的时候, 应该尽量做好单元测试, 单元测试可能在最初实现的时候, 作用相对来说比较小, 但是在后期维护修改重构以及添加新功能的时候, 其威力将逐渐显现出来. 此外一些系统之所以不好修改, 后期维护困难, 与我们编码时候没有遵循一定的规则有关, 比如依赖管理, 代码复杂度控制, 这些规则其实都非常简单, 人人都会知道, 但是在具体场景能不能想到, 并加以灵活运用却是另外一回事儿, 我觉得这个必须经过大量的编码实践才能找到这种感觉, 就像学习英语, 只有多读, 多听, 多说, 才能具有一定的语感, 从而最终掌握.
与<重构到模式>一样, 这也是一本围绕重构来阐述如何修改代码, 只不过它面对的场景是遗留系统.对遗留系统进行重构首先要做的就是要让我们的修改能够被单元测试用具夹住, 就像对一栋居民楼进行改造一样, 必须先安装脚手架, 拉上防护网, 做好安全措施, 然后再开工. 从而减少因为修改带来的风险.
如何在修改代码前搞定对应的单元测试呢?这是一个非常有技巧的活儿, 因为遗留系统可能因为设计不佳而无法或者很难非常容易的为其修改部分添加单元测试. 之所以造成这样的局面一个重要的方面是无法对要测试的部分进行解除依赖. 因此解除相关依赖也就成了修改代码首先面对的一个难题, 本书在解除依赖方面总结了非常多的方法(或模式), 这些方法总有一款会适合你. 本人觉得这应该算是这本书的所要告诉我们的主要内容吧.
本书的例子大部分都是以java为主, 少量的穿插了c++的实例, 而且有些手法跟语言的关系比较大, 可能适用c++的做法, 对java并不适用.
另外本书给我的另一个启发就是, 我们在写代码的时候, 应该尽量做好单元测试, 单元测试可能在最初实现的时候, 作用相对来说比较小, 但是在后期维护修改重构以及添加新功能的时候, 其威力将逐渐显现出来. 此外一些系统之所以不好修改, 后期维护困难, 与我们编码时候没有遵循一定的规则有关, 比如依赖管理, 代码复杂度控制, 这些规则其实都非常简单, 人人都会知道, 但是在具体场景能不能想到, 并加以灵活运用却是另外一回事儿, 我觉得这个必须经过大量的编码实践才能找到这种感觉, 就像学习英语, 只有多读, 多听, 多说, 才能具有一定的语感, 从而最终掌握.
有关键情节透露