开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
6 个重构方法可帮你提升 80% 的代码质量 - 技术翻译 - 开源中国社区

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

oschina 推荐于 4年前 (共 2 段, 翻译完成于 02-03) 评论 13
收藏  
355
推荐标签: 待读

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

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

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

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

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

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

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

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

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

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

轩骐
 翻译得不错哦!

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

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

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

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

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

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

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

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

优雅先生
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(13)
Ctrl/CMD+Enter

两点翻译建议:
1、大类建议改成臃肿的类
2、Refactoring Pattern建议翻译成重构手法或者重构模式

引用来自“美好的2014”的评论

两点翻译建议:
1、大类建议改成臃肿的类
2、Refactoring Pattern建议翻译成重构手法或者重构模式

谢谢建议,我修改下~
作者应该补充一个大前提:在阅读和积累了一定经验后。
没一定阅历,是体会不到以上6点的用处的。
去掉臃肿的唯一方法是抛弃类
大类=虽然大,但无法优化
臃肿的类=可以优化
都是“类”编程滥用惹的货。哈。
沒實例都是扯談
有些术语感觉不翻译更好理解,或者翻译之后在旁边注明原文
概括得很好,但缺少实例,给新手是读不懂的。
@DarkHero @蝙蝠 原文就这样的,实例的话去看《重构,改善代码的艺术》这本书最好。
每个方法语句不超过50条,圈复杂度不能超过10,扇入扇出要合理。注意到这些,基本上写的类都比较容易理解了。

引用来自“lazyphp”的评论

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

而且有些基本只能发生在代码走查之后的重构。已有产品第一条就很难重构,那是一个大手术。所以基本上,只能在开发时期就需要做,那么实际问题是设计不好,而不应该,先开发个烂的再来重构。

引用来自“蝙蝠”的评论

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

赞成
顶部