重构:改善既有代码的设计读后感

一、对书的看法

这其实是本工具书，主要是让重构的节奏形成章法，降低重构的难度。

当你对重构的概念还很迷茫，或者想要重构但不知道如何进行时，可以阅读它。

作者想告诉大家的是：重构远没有想象中的那么复杂。在保证充分验证的情况下，将代码的‘坏味道’与书中的进行映射，然后按照书中的步骤一步步来，就可以了。

二、对重构的一些思考：

按照影响范围的大小，重构可以分为三类：

1. 开发过程中进行的重构，这也是进行重构的最佳时机，我称之为小重构。在这个时期，重构的工作是在测试前进行的，甚至可以排在自己的任务计划里。比如我要开发一个比较复杂的组件，都会预留一些时间进行小重构的。

2. 系统阶段性的重构，‘有组织有预谋’地进行重构。部门的团队管理都是走的敏捷流程，迭代过程中会有调整期。这个时候可以针对对一些较高内聚的功能模块，进行重构。这些功能模块职责单一，影响范围有一定局限性。比如：文件上传和下载。重构的过程，可以按书里面的节奏来。

3. 对旧有系统的改造，这时候要区分重构和重写的概念。它影响了整个系统，我称之为大重构。根据旧有系统的弊端，会确定不同的重构目标。嗯，前端的系统相对比较简单，这一块儿我也在探索中。

我能确定的是：不管在系统里面干什么事情，都要确定影响范围的边界。比如：外部系统依赖，系统与系统之间，模块与模块之间。先确定边界范围，再对照目标，按照第2步的方式一个个的去解决，化繁为简。

三、其他：

重构其实是有弊端的：

1. 价值在当前无法体现。重构的原因可能为了让系统更健壮，也有可能是为了提升效率，这些对当前的系统来说其实是没有增量价值的。

2. 耗费人力和物力，重构有时候跟比重做一个系统还麻烦。

3. 有一定的风险。重构之后的系统可能还没有以前的好用

其实，进行重构最难的一部分，就是如何说服领导进行重构。

最后，多写代码，熟能生巧