party_bid的重构总结

party—bid已经做完了，现在回想起来重构的过程依然觉得特别纠结，因为本身的数据存储结构比较复杂，比较乱,所以重构起来也觉得特别痛苦。
存储结构是这样的：见附件
对其中内容的查找操作是通过id进行的，这个id的换算比较麻烦。

重构的过程是这样的：
（1）首先程序中用了大量的if和for循环的嵌套，为了减小圈复杂度，用underscore替换了一遍
（2）将重复的并多次用到的代码拿出来抽成独立的函数，以供调用（比如得到当前活动的id以及获得当前竞价的id）。
（3）抽出数据模型model，因为代码写的太乱并且职责划分错误很多，导致这个过程很难进行，所以先将职责错误改掉，（比如模态框隐藏与显示，之前是用ng-class关键字，在控制器里直接改模态框的class，重构之后用ngSwitch来控制模态框。）
（4）因为原程序是面向过程的，函数直接写下来行数比较多。参照的模板是面向对象的，因此查了面向对象的优点，并将原程序由面向过程改为了面向对象。
（5）直到上一步完成，才真正开始了重构，将model抽出，controller只负责业务逻辑，不参与功能实现。
（6）代码重构后，短信处理采用的责任链的形式，这样可以保证每个函数最多有一个if，代码看上去比较清晰易懂。

重构的过程虽然痛苦，但是确实学到了许多。也知道了以后的代码应该怎样写。下面是我的体会：
（1） 每当写一个新的应用，一定要先把数据结构组织好，不能照着需求一条一条的做，要把握整体的思路。
（2） 每个函数只做一件事，代码不能太长，一般不超过15行，函数内圈复杂度在容易理解的前提下降至最低，循环等用underscore代替。
（3）对MVC有了深刻的理解，model层实现所有与数据结构有关的增删改查等方法以及完成其他功能的功能函数，controller 不实现任何功能方法，只通过调用功能方法实现逻辑控制
（4）对面向过程有了一定的了解，相对于面向过程而言，面向对象结构清晰，容易维护，容易扩展，有继承、封装、多态的特性。

重构的优势与劣势：重构的代码结构比较清晰，易于维护。劣势是重构过程会出现不可预知的错误，改这些错误需要很多时间。