重构代码——从一个例子开始

一个例子

这个例子不好的地方

1、输出格式唯一，如果修改需要单独修改输出格式
其实这个问题不是问题，在需求没有更改的情况下。但是需求是一步一步提升的，如果每次提升需求都要重写某部分代码，那耗费的精力就比较大了。
2、理解很困难= =
问题在哪里呢？因为例子没有说具体的计费方式，在代码中写死了计费&折扣方式，如果以后需要修改折扣方式，比较难统一。比如对悲剧的计费要修改，积分也要修改，那代码中就需要修改两处地方；比如要添加正剧这个类别，需要将计费、积分等重新捋一遍。
3、没有拆分，所以不清晰，其实就是避免大段代码实现一个完整的功能，最好拆分成小块函数调用。

引出测试的重要性

重构过程中，不可避免引入一些问题，导致有些功能缺失了或者有些问题没有覆盖到。
两点：1、重构前需要列好测试集，2、每次重构后要跑一遍测试，无论多小的改动，方便查错。
吧啦吧啦，不知道在说啥，后边有一整章传授测试大法。

如何分解这个例子

1、拆分出主要功能

计算费用与折扣
计算积分
这里涉及到输入和输出的问题，在这部分代码中，哪些是不会变的（作为输入），哪些是会变化的（要作为输出）。
变量改名：在将局部代码重构为函数的时候，部分变量应该脱离原代码块的含义，改一个比较抽象的词，比如这个代码中，作者把价格改成了：result。(O_o)??……
2、去除拆分出来的函数里的const变量，用更小的函数代替。目的：减少传参（少创建具有局部作用域的临时变量）
其实做的很多替换都是在去除临时变量。

软件的性能通常只与代码的一小部分有关，改变其他部分往往对总体性能贡献甚微。

解读：大胆地使用循环吧！对性能相关的代码具有敏感性（要知道哪些会影响性能）。
解读：计算性能降低也没关系，结构优于性能，性能是可以调优的。

拆分循环：
移动语句：
提炼函数：
内联变量：
以上均见后。

2、拆出过渡部分

什么是过渡部分呢？对这个例子来说，过渡就是计算的结果。把价格和类型输入后，获取到总价和积分，然后用不同的方式展示出来。这个计算的结果就是中间承接两个过程的部分，获取他的过程和展示的过程需要分离开：计算获取结果，把结果作为展示的输入。
书中用一个结构来保存计算的输入&输出，然后将这个结构传递给展示过程。
这样，展示就可以不受计算过程拘束，只享受结果。

3、利用多态实现同一件事不同分类的计算

当前的计算是在switch结构中实现分类，随着类型越来越多，switch会变得越来越臃肿。将计算抽象为一个类，其中不同类型的计算作为子类继承可以解决这个问题。

根据结语，三部分正好是我理解的上述三分部：

3个较为重要的节点：1、讲原函数分解为一组嵌套的函数；2、应用拆分阶段分离计算逻辑与输出格式化逻辑；3、为计算器引入多态性来处理计算逻辑。

好代码：容易理解，方便修改。