请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

   思科 CCO 登录 推荐
 找回密码
 立即注册

搜索
热搜: 邮件服务器
查看: 372|回复: 0

【原创翻译】有效的代码重构(2)

[复制链接]
发表于 2019-6-10 14:24:06 | 显示全部楼层 |阅读模式
第2部分:制定计划






如果没有计划,您就是在计划失败。--本杰明富兰克林如是说。



一旦开始决定重构某个应用程序,您的第一本能应该是:深挖代码并清理不适合的代码。然而事实证明:如果没有一个事先的计划,您将难逃“劫难”。

在按照时间和预算的范围制定出行动计划之前,您先别急着修改代码。代码重构的目的是为了让整个团队受益于代码价值的最大化。如果代码中的某些部分虽然显得特别混乱,但是能够提供正常服务的话,那么就没有必要迅速对它们进行重构。我们稍后会讨论区分优先级的问题,而当前您至少应该先对代码的潜在价值有所预判。
以下列出了能够保证您的重构项目正确开始的若干步骤。即使您的重构项目相对较小,我仍然建议您参考并使用下列技术。
选择一种项目管理工具
无论代码重构的范围是大还是小,您都需要用一种工具来跟踪项目进度。我是Trello的忠实粉丝,并认为其“看板(Kanban)”风格界面非常适合于项目管理。当然,您完全可以挑选自己喜欢的工具,而且最好具有对任务进行排序、分组、添加注释、以及说明的功能。同时,如果它能够添加附件或创建标签的话,那就更是锦上添花了。
以我的项目为例,我创建了一个Trello看板,并通过如下列表名称来跟踪各项任务:
·        积压工作
·        下一步
·        进行中
·        拉取请求(PullRequest)
·        关闭
我还创建了一个标签专门用来表示某个任务是否涉及到React组件、Redux元素(如actions、reducers、selectors)、以及应用配置等方面。如果您和我一样属于“视觉系”的,则可以通过给标签添加颜色,来迅速了解其表征的特性,而不需仔细阅读其标题或相关说明。例如,我创建了一个将webpack从1.0 升级到3.0的任务,并为Configuration标签设定了特殊颜色,以便我能在面板上快速地识别出来。
查找逻辑上下文
如果代码量非常大的话,您可以试着将应用程序解构为多个模块或上下文的关系。此处“上下文”表示为:隶属于某个特定业务实体或是应用程序配置的代码段。如果您所面对的代码库颇为混乱的话,该过程将具有挑战性。不过,即使只是粗略地研究与划分,也会有助于您更进一步熟悉代码库,甚至让您受益匪浅。
在多数情况下,您可以根据应用的服务流程来推断出上下文关系。例如,一个为牙科诊所安排日程表的应用,就可以被分为如下的上下文关系:
·        病人
·        约诊
·        用户导航
·        牙科记录
·        用户管理
在实践中,我们经常会碰到的棘手部分是:如何正确把控粒度。对于我所开发过的应用而言,我一般会根据API的调用和现有Redux的reducer来确定上下文关系。我通常会定义出:用户类上下文、超级用户类上下文(用于各种管理操作)、应用类上下文(用于UI的状态)、以及其他类型。
注意:不要过于苛求完美的上下文关系,这一步的目的只是为了简化任务创建的过程。
创建任务
您必须创建出具有明确范围的任务。在此,您可以根据“拉取请求”的方式来考虑范围。虽然谁都不想一次性提交具有5,000行代码之多的变更,但是在5,000行代码中只提交2处修改显然也是远远不够的。
以我曾经参与过的一个重构项目为例,其目标是从Foundation框架(请参考https://foundation.zurb.com/)转换到语义UI的React,并且实现CSS模块。我最初创建了单一的任务来表示这一转化,但是我立即意识到了它所牵扯到的巨大工作量。
在该应用中,有着近100个React组件需要被更新,而我并不想在Trello中创建100个任务来代表每一个单独的组件。在此情况下,我定义了一些简单的上下文关系:
·        首先,我在每个上下文中创建了不同的任务,来重构与Redux相连接的各个容器组件。
·        接下来,我查看了共享的/components目录,并按照表单控件、图表等类别对它们进行分组。
·        最后,我创建了单独的任务来重构每一组共享的组件。

当然,您也需要考虑到自己的变更对于应用的影响。如果可能需要恢复到旧的版本,您一定不想在大段的变更代码中费力地深挖出造成某个bug的原因。曾经有一次,我为了某个bug而不得不撤销了自己的绝大部分的更改。在此之后我转为试着用小块的程序代码去进行重构。
为任务排序
如果您愿意的话,可以考虑为任务制定排序或优先级的一些标准。当然,如果您已经为每一项任务创建了明确的范围,那么完成它们的顺序也就一目了然了。我倾向于将具有相似特定功能的任务进行分组处理,例如根据Redux的元素或API管理来区分。当然,如果您是新手的话,我会建议您先去“摘取那些低垂的果实”,即一些仅付出少量的努力就会效果明显的任务。
持续更新您的计划
随着对于代码的“深耕”,您可能会发现在前期重构计划里不准确的地方,那么请不要犹豫,尽快修正以免覆水难收。重构代码库的好处往往是无形且难以衡量的。哪怕最终不得不终止重构计划,您的这份详细的计划也能为下一次重构的“重启”提供宝贵的资源和“追踪”的线索。


  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver | 思科社区  

GMT+8, 2019-10-17 04:17 , Processed in 0.093922 second(s), 34 queries .

京ICP备09041801号-187

版权所有 :copyright:1992-2019 思科系统  重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表