第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管理来区分。当然，如果您是新手的话，我会建议您先去“摘取那些低垂的果实”，即一些仅付出少量的努力就会效果明显的任务。持续更新您的计划随着对于代码的“深耕”，您可能会发现在前期重构计划里不准确的地方，那么请不要犹豫，尽快修正以免覆水难收。重构代码库的好处往往是无形且难以衡量的。哪怕最终不得不终止重构计划，您的这份详细的计划也能为下一次重构的“重启”提供宝贵的资源和“追踪”的线索。
