Refactoring之——代码的坏味道（一）过长方法

1 代码的坏味道

重构一书中提到了22种代码的坏味道，大致可以分为几类。

识别代码的坏味道，有助于发现代码的潜在问题，从而可以有的放矢的修改现有代码，使之不断完善。

1.1 Bloaters（臭鲱，暂译臭代码）

这种类型的味道意味着：代码、函数和类的问题没有立马凸显，但是随着代码不断改变，问题就会越来越明显。

包含五种：

1.1.1 Long Method（过长方法）

特征：

一个方法含有太多行代码。一般来说，任何方法超过10行时，你就可以考虑是不是过长了。函数中的代码行数原则上不要你超过100行。

　　　　　　　　　　　　

问题的原因：

通常情况下，创建一个新方法的难度要大于添加功能到一个已存在的方法。大部分人都觉得：“我就添加这么两行代码，为此新建一个方法实在是小题大做了。”于是，张三加两行，李四加两行，王五加两行。。。方法日益庞大，最终烂的像一锅浆糊，再也没人能完全看懂了。于是大家就更不敢轻易动这个方法了，只能恶性循环的往其中添加代码。所以，如果你看到一个超过200行的方法，通常都是多个程序员东拼西凑出来的。

解决方法：

一个很好的技巧是：寻找注释。添加注释，一般有这么几个原因：代码逻辑较为晦涩或复杂；这段代码功能相对独立；特殊处理。 如果代码前方有一行注释，就是在提醒你：可以将这段代码替换成一个函数，而且可以在注释的基础上给这个函数命名。如果方法有一个描述恰当的名字，就不需要去看内部代码究竟是如何实现的。就算只有一行代码，如果它需要以注释来说明，那也值得将它提炼到独立函数中。

　　　　　　　　　　　　

• 为了给一个方法瘦身，可以使用 提炼方法(Extract Method)。
• 如果局部变量和参数干扰提炼方法，可以使用 以查询取代临时变量(Replace Temp with Query)，引入参数对象(Introduce Parameter Object) 或 保持对象完整(Preserve Whole Object) 。
• 如果前面两条没有帮助，可以通过 以函数对象取代函数(Replace Method with Method Object)尝试移动整个方法到一个独立的对象中。
• 条件表达式和循环常常也是提炼的信号。对于条件表达式，可以使用 分解条件表达式(Decompose Conditional) 。至于循环，应该使用 提炼方法(Extract Method) 将循环和其内的代码提炼到独立函数中。

收获：

• 在所有类型的面向对象代码中，方法比较短小精悍的类往往生命周期较长。一个方法越长，就越不容易理解和维护。
• 此外，过长方法中往往含有难以发现的重复代码。

　　　　　　　　　　　　

性能：

是否像许多人说的那样，增加方法的数量会影响性能？在几乎绝大多数情况下，这种影响是可以忽略不计，所以不用担心。 此外，现在有了清晰和易读的代码，在需要的时候，你将更容易找到真正有效的方法来重组代码和提高性能。