书籍简介
这本书并没有从宏观的角度讲解一个软件应该在最初的时候如何去设计，相反，它介绍了在最初的设计已经腐化或者不满足当前的需求的时候如何发现这些腐化的点并逐步改善这些设计。
很重要的一点是：这本书用了一大半的篇幅来讲解重构的技巧，可以先大概粗读一遍并在之后用的时候详细翻阅其中相关的内容。虽然说是技巧，但是这些技巧基本上都不是像读说明书一样，而应该结合相关的设计思想具体分析，因为读过一遍就会发现，很多的技巧相互配合，但是更多的技巧则是相互冲突的（至少在没有深刻理解现有需求和设计的情况下是这样的），如果原封不动得挨个套用一遍则会发现自己好像把刚刚改过的又改回去了。
因此，我认为这本书的正确用法是：精读并理解前半部分理论，粗读后边的重构技巧，并在日后的项目中多抽出空闲实现分析重构技术在项目中应该如何应用
重构与设计
在读这本书之前一直有一件事情让我很苦恼，就是：在最初对软件或者模块做设计的时候，我绞尽脑汁去想后面可能会有什么样的需求变化，我要怎么把这些可能的变化隔离，但是在做了大量假设之后如果这些需求的变化N年之后或者根本不会出现，那就相当于我做的设计反倒让代码变得更难读懂和难以维护（出现了过度设计）。但是无论我怎么想都没法判断过度的“度”到底是什么，究竟考虑多少可能会有的需求才不算多，因为我个人的设计经验还是比较匮乏的，我甚至觉得没人能做到真的把控好度，以至于像预言家一样把出现的需求变动都预测到了，而不会出现的一点儿没有。
但是这本书的思想给了我答案，我并不需要在最初的设计时就考虑到日后的诸多变化，只需要向前看一小步（而不是N年的大变化），并且分析现有的设计在出现变化之后重构是不是比较困难，不困难则符合现有的需求设计即可，不用假设代码中所有的东西都可变；困难则需要多分析一下可能的变化。
但是，在日后的迭代中则需要不断得重构和改进设计，就像终身学习一样，一直改善。这个无疑是最大的阻碍。
重构与性能
这本书中提出的很多重构技巧都是以牺牲性能为代价的，虽然这也是不得已而为之。作者推荐我们在大多数情况下不要考虑小的性能损失，而每过一段时间专门对性能做优化。他不推荐每当写一部分代码或者重构一部分代码时都关注这部分代码的性能，因为这部分代码可能执行次数较少或者根本不是性能瓶颈。
但是，我的经验告诉我，浏览器（尤其IE）在性能上面并没有那么友好，比如内存等问题。因此在重构过程中最好还是结合前端技术具体分析每个重构技术应该怎么应用才不会引起严重的性能问题（尤其内存泄露）
重构技术在项目中的应用
读过这本书之后发现，我们项目中出现的很多糟糕的代码，根本原因其实就是在最初设计之后没有对架构进行演进，没有逐步改善设计，最终形成了补丁式的代码（当然也不排除一开始就没把设计做好）。但是，想要在实际中应用重构技术，并不是一件简单的事情，因为我们的时间太紧了，如果持续得对设计进行改进很有可能导致项目延期。
结合了作者提出的一些进行重构的合适的时机，我自己总结了一下：
- 可以在代码走读之前或之后进行重构，前提是不能在项目末期。
- 可以在走读之后做记录，在新版本开始前或新版本初期进行重构。
- 可以在重写模块或者添加大的功能点时重构。
- 在修改一些小点时发现的需要改善的地方，可以先记录（先欠着），之后在新版本开始前或新版本初期做修改。
。。。
面向对象与前端
由于JAVA本身是基于面向对象思想去设计的语言，比较适合用来给设计思想举例，因此很多软件设计相关的书籍大多以JAVA为example。
但是，由于前端的javascript是一个弱类型脚本语言，且它在面向对象的设计上是一种基于原型的面向对象，这使得在传统面向对象中的继承和多态都在javascript中显得很“与众不同”。
另外，由于前端的组件化思想以及前端特有的html和css的存在，使得站在前端的角度上面去理解这本书中的重构技巧注定会要用不同的方式，要从例子中的JAVA代码中跳出来并发散到前端的设计当中，有些技巧的使用会以不同的方式进行。
例如：
- Extract Class 可以延申至 Extract Component
- Inline Class 可以延申至 Inline Component (名字怪怪的，其实就是把多余的组件定义删除掉然后写进使用它的组件中)
- Hide Delegate 可以延申至组件间的数据流和控制流的设计上（如保证数据流单向，控制流单一等）
这样的例子还有很多，就不一一列举了（其实我也没全看完）
最后
经过一大段的无脑分析，我认为的确有必要（当然也得有时间）在之后补充一些书中重构技术在前端使用的案例，以方便分享和参考，现在有碍于自己好吃懒做和时间问题（其实还是好吃懒做），没有整理，日后须努力！！
网友评论