加载中

Have done several code reviews in past and found following top 5 code smells common across most of these code having code quality issues:

  1. Large Class: The classes were found larger enough due to lack of developers’ understanding on one of the primary coding principles which is “Single Responsibility Principle” (SRP). These classes use to get larger due to various methods serving unrelated functionality in the same class.

  2. Long Method: The methods have been found longer due to several reasons such as following:

    1. Several block of code serving unrelated/multiple functionality within the same method. This is primarily due to lack of SRP concepts with the developers.

    2. Several conditionals within the same method. This is found very often within the method which are long enough. This may be attributed to the lack of knowledge on McCabe code complexity vis-a-vis SRP concepts.

  3. Several Method Parameters : Then, there are several instances I came across where it was seen that method is passing several parameters to each other to interact/call each other. And, a change to one of the parameters in the parameter list use to change several method signature.

  4. Literal Constants Used Everywhere: Several times, it is seen that developers (primarily newbies) use the literal constants (mostly numbers) with definite meanings using them as it is, without assigning a proper named constant variable to it. This degrades the code read-ability and understand-ability.

  5. Vague Method Names: Many a times, method names have been found to look like following which impacts on code read-ability and understand-ability:

    1. Vague names without any meaning

    2. Technical names without any reference to problem domain related names.

在过去做了不少代码走读,发现了一些代码质量上比较普遍的问题,以下是其中的前五名

  1. 臃肿的类: 类之所以会臃肿,是因为开发者缺乏对最基本的编码原则,即“单一职责原则”(SRP)的理解。这些类往往会变得很臃肿,是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。

  2. 长方法: 方法之所以会变得很长主要是有以下几个原因:

    1. 许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。

    2. 多种条件都放在同一个方法内,这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。

  3. 大量的传参: 我经常遇到这几种情况,一些方法跟另一些方法进行交互,或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数,就得在多个方法内进行更改。

  4. 常量值无处不在: 经常会发现开发者(尤其是新手)会使用一些具有明确含义的常量值(主要是魔鬼数字),但没有给它们赋予合适的常量变量。这会降低代码的可读性和可理解性。

  5. 模糊的方法名: 许多时候,以下取的方法名会影响代码的可读性和可理解性:

    1. 模糊的不具有任何意义的方法名

    2. 技术性的,却没有提及相关领域的名称

Top 6 Refactoring Patterns to Deal with Above Code Smells

Following are top 6 refactoring patterns which could help you resolve 80% (remember 80-20 rule) of code quality issues and become a better developer:

  1. Extract Class/Move Method: As mentioned above, code smell such as large class serving functionality that should be done by two or more classes should be split/extracted into appropriate number of classes. In these new classes, the appropriate fields and methods from the old classes should be moved. Additionally, the classes are also found to be long at times because of presence of methods which serves functionality which are used by other class and tends to be the member method of that class. Such methods should also be moved to such type of appropriate class.

  2. Extract Method: Code smell such as long method as mentioned above could be dealt by extracting code from old method to one or more new methods.

  3. Decompose Conditional: many a times, method found to be long is seen to consist of several conditional statements (if-else). These conditionals should be extracted and moved into separate methods. This does increase the code read-ability & understand-ability to a great extent.

  4. Introduce Parameter Object/Preserve Whole Object: Several parameters passed to methods has been one another common observations I have come across while doing code review. The problem has been primarily related to change in code if there has been a need to add or remove one of the method parameters from the involved methods. In this scenario, it is suggested to group related parameters as object (Introduce Parameter Object) and let methods pass these objects rather than each of the parameters.

  5. Replace Magic Number with Symbolic Constants: For literal constants that have meanings and that are used everywhere, should be assigned a named constant variable. This enhances the code read-ability and understand-ability to a great extent.

  6. Rename Method: As mentioned above under the code smells, the vague method names impacts the usability of the code. These vague names should rather be given meaningful names which may relate to business domain related terminologies and help developer understand the code in the business context. This is quite a skill and requires developers to collaborate with business analysts to properly understand the business requirements that is met with the code. Interestingly, this refactoring pattern looks pretty simple to understand, but however, gets ignored quite often by many developers given the fact that its mention is made in IDEs such as Eclipse under refactor menu link.

6个处理上面代码异味的重构方法(手法)

以下是6个可以用来帮助你解决80%(80-20原则)的代码质量问题的重构方法,并能帮助你成为一个更优秀的开发者。

  1. 提取类/抽离方法:正如上面提到的,像“臃肿的类”(一个类提供了本该有几个类提供的功能)这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外,有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。

  2. 提取方法像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。

  3. 分离条件:许多时候,一个方法很长是因为包含好几个分支语句(if-else)。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。

  4. 引入参数对象/保留全局对象:在我做代码审查时发现另外一个很常见的情况 - 好几个参数被传入方法。问题主要与需要从已有方法中增加或者移除一个方法参数有关。在这种场景,建议将相关方法参数组成一个对象(引入参数对象),让方法传递这些对象而不是每个单独的参数。

  5. 用符号常量替换魔法数字:对于有意义的并且到处被使用的字面常量,应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。

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

返回顶部
顶部