需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。这种重构方法看起来似乎非常容易理解，重命名方法：正如上面提到模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称。但是经常 被许多开发者忽视，虽然在Eclips这种IDErefactor菜单项中经常出现这一项。

发现了一些代码质量上比较普遍的问题，过去做了不少代码走读。因为开发者缺乏对最基本的编码原则，臃肿的类:类之所以会臃肿。即“单一职责原则”SRP理解。这些类往往会变得很臃肿，由于不同的且在功能上缺少关联的方法都放在相同的类里面。

长方法:方法之所以会变得很长主要是有几个原因：许多没有关联性的功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP概念。这在长方法内经常会发生的这是由于缺乏McCabe代码复杂度和SRP概念的比拟。多种条件都放在同一个方法内。

一些方法跟另一些方法进行交互，大量的传参:经常遇到这几种情况。或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。常量值无处不在:经常会发现开发者（尤其是新手）会使用一些具有明确含义的常量值（主要是魔鬼数字）但没有给它赋予合适的常量变量。这会降低代码的可读性和可理解性。

以下取的方法名会影响代码的可读性和可理解性：模糊的方法名:许多时候。模糊的不具有任何意义的方法名技术性的却没有提及相关领域的名称6个处置上面代码异味的重构方法（手法）

并能帮助你成为一个更优秀的开发者。以下是6个可以用来帮助你解决80%80-20原则）代码质量问题的重构方法。有时候一些类过于臃肿是因为它包括了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。提取类/抽离方法：正如上面提到像“臃肿的类”一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外提取方法：像上面提到过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。

一个方法很长是因为包括好几个分支语句（if-els这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。分离条件：许多时候建议将相关方法参数组成一个对象（引入参数对象）让方法传送这些对象而不是每个单独的参数。引入参数对象/保管全局对象：做代码审查时发现另外一个很常见的情况 -好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。这种场景。应该为它分配一个命名常量。这能大大增强代码可读性和可理解性。用符号常量替换魔法数字：对于有意义的并且到处被使用的字面常量。