代码重构笔记I

        代码重构目的是为了把凌乱的代码重新梳理的有条理，在不改变代码的外在行为的前提下，对代码进行修改，以改进程序内部的结构。通过重构找到改变代码的平衡点。这时设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来的。闲话少说我们言归正传。

        重构第一步：任何改动代码都可能对代码带来更多的Bug，需要在做重构的时候必须得建立可靠的测试环境。程序员都希望看见代码短小，逻辑清晰的代码。如果遇见一大段代码使用提炼出方法，把逻辑复杂的一段代码提炼出来。每当我们决定做一项重构，提前预测可能会出现什么错误。重构是的做法是不断重复对，每一次代码的做小幅度修改。可以尽量的减少重构带来的Bug。

        评定好的代码，最低标准是，能够在不给他人解释的情况下，其程序员能轻易的表达出自己的功能。每一次提炼出方法，对方法的取名非常重要，这时的重点在于如何命名方法。一个好的名称一眼就能明白代码所要表述的意思而不需要大量的阅读代码注释。我的做法是易该方法“做什么”命名而不是使用该方法“怎么做”。

       所有的重构行为都是使责任分配更合理，代码的维护更轻松。

2.13

提炼函数：

       需要注释才能让人理解代码的注释，用于处理代码函数过长。为什么我喜欢代码短小的函数呢？因为代码函数粒度越小，代码的重用的可能性很大。再次高层阅读代码非常方便。如果代码的粒度小代码的复写就会更加容易。

       如果需要做好提炼函数的方法，首先需要在函数的命名上下功夫。这时如果还在犹豫怎样命名的话，建议使用函数的意图来命名(函数“要做啥”而不是“怎么做”)。

       如果在提炼方法的时候你对局部变量无从下手，那就把局部变量当做函数参数传递给所提炼出来的方法。那么对于需要传递的函数变量个数比较多的问题，还让你为之而感到困难，可以把他封装成为一个对象，传递一个对象变量到子函数中做相应的处理。

        处理完所有的函数提炼后进行编译，检查是否有提炼中没有考虑到的一些逻辑漏洞和有无错误。

       对于简单的没有局部变量的处理就非常的简单了。不过为了使函数的复用可能性变得大，建议函数单一职责原则，需要满足。