在过去作了很多代码走读，发现了一些代码质量上比较广泛的问题，如下是其中的前五名：数组
臃肿的类: 类之因此会臃肿，是由于开发者缺少对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类每每会变得很臃肿，是因为不一样的且在功能上缺乏关联的方法都放在了相同的类里面。ide
长方法: 方法之因此会变得很长主要是有如下几个缘由：编码
许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺少SRP的概念。spa
多种条件都放在同一个方法内，这在长方法内常常会发生的。这是因为缺少McCabe代码复杂度和SRP的概念的比较。.net
大量的传参: 我常常遇到这几种状况，一些方法跟另外一些方法进行交互，或者调用另外一些方法的时候传入大量的参数。这就会出现若是更改了其中一个参数，就得在多个方法内进行更改。code
常量值无处不在: 常常会发现开发者（尤为是新手）会使用一些具备明确含义的常量值（主要是魔鬼数字），但没有给它们赋予合适的常量变量。这会下降代码的可读性和可理解性。对象
模糊的方法名: 许多时候，如下取的方法名会影响代码的可读性和可理解性：flux
模糊的不具备任何意义的方法名ip
技术性的，却没有说起相关领域的名称开发
6个处理上面代码异味的重构方法（手法）
如下是6个能够用来帮助你解决80%（80-20原则）的代码质量问题的重构方法，并能帮助你成为一个更优秀的开发者。
提取类/抽离方法：正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是由于它包含了被其余类使用本应该是其余类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。
提取方法：像上面提到的“过长的方法”这种代码异味能够经过从旧方法中提取代码到一个或多个新方法中消除。
分离条件：许多时候，一个方法很长是由于包含好几个分支语句（if-else）。这些分支条件能够被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。
引入参数对象/保留全局对象：在我作代码审查时发现另一个很常见的状况 - 好几个参数被传入方法。问题主要与须要从已有方法中增长或者移除一个方法参数有关。在这种场景，建议将相关方法参数组成一个对象（引入参数对象），让方法传递这些对象而不是每一个单独的参数。
用符号常量替换魔法数字：对于有意义的而且处处被使用的字面常量，应该为它们分配一个命名常量。这能大大加强代码可读性和可理解性。
重命名方法： 正如上面提到的，模糊不清的方法名会影响代码的可以使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者经过业务上下文 更好地理解代码。这很须要技巧而且要求开发者与业务专家一块儿协做来理清代码须要知足的业务需求。有趣的是，这种重构方法看起来彷佛很是容易理解，可是经常 被许多开发者忽视，虽然在Eclipse这种IDE的refactor菜单项中常常出现这一项。
原文连接：http://vitalflux.com/top-6-refactoring-patterns-to-help-you-score-80-in-code-quality/
译文连接：http://www.oschina.net/translate/top-6-refactoring-patterns-to-help-you-score-80-in-code-quality