6 个重构方法可帮你提升 80% 的代码质量 已翻译 100%

oschina 投递于 2014/02/02 07:43 (共 2 段, 翻译完成于 02-03)
阅读 14321
收藏 352
18
加载中

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 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(13)

Wjungking
Wjungking

引用来自“蝙蝠”的评论

概括得很好,但缺少实例,给新手是读不懂的。

赞成
ericsoul
ericsoul

引用来自“lazyphp”的评论

作者应该补充一个大前提:在阅读和积累了一定经验后。
没一定阅历,是体会不到以上6点的用处的。

而且有些基本只能发生在代码走查之后的重构。已有产品第一条就很难重构,那是一个大手术。所以基本上,只能在开发时期就需要做,那么实际问题是设计不好,而不应该,先开发个烂的再来重构。
lockrecv
lockrecv
每个方法语句不超过50条,圈复杂度不能超过10,扇入扇出要合理。注意到这些,基本上写的类都比较容易理解了。
优雅先生
优雅先生
@DarkHero @蝙蝠 原文就这样的,实例的话去看《重构,改善代码的艺术》这本书最好。
Neeke
Neeke
概括得很好,但缺少实例,给新手是读不懂的。
Jack_Zhu
Jack_Zhu
有些术语感觉不翻译更好理解,或者翻译之后在旁边注明原文
DarkHero
DarkHero
沒實例都是扯談
中山野鬼
中山野鬼
都是“类”编程滥用惹的货。哈。
haitaosoft
haitaosoft
大类=虽然大,但无法优化
臃肿的类=可以优化
桔子
桔子
去掉臃肿的唯一方法是抛弃类
返回顶部
顶部