重构大组件的历程
在快速迭代下，如果没有来得及重构，一个组件会快速膨胀，慢慢的成为了一个历史悠久的组件，在没有完全了解业务的情况下，没有人敢动它，于是它成了以三千行闻名的组件=.=，这次优化把它排进去了，这个星期就先开始切分一下代码，正好也熟悉一下业务。
过程中最需要的是耐心，一定要稳住！
第一步：分离DOM
一个组件大的原因是承载的东西太多了，首先是先将render函数中返回的DOM做一下切分。这样做的好处是，根据业务切分成多个小组件后，是有利于公共组件的构建，如果有部分样式改变也可以迅速的定位到问题。
const Article = () => {
return (
<div className="article">
<div className="article-header">
<Title />
</div>
<div className="article-footer">
<Title2 />
<Question />
<Answer />
</div>
<div className="article-footer">
{/* 按钮组 */}
</div>
</div>
)
}
上面看起来清爽多了，另外，在切分组件的时候，需要给组件传递很多数据和函数，可能会比原来的dom行数还好多，不要怕，继续做。后面会有办法解决。
第二步：数据降级
这个和状态提升是一个相反的状态。什么时候需要状态提升呢？两个组件共享状态的时候，这个时候需要状态提升，将共享状态放在父组件中。状态降级是一个相反的过程。数据不仅仅限于状态还有一些挂载在组件上的数据。
在分离完dom后，去看一下哪些数据仅仅在一个子组件中使用，没有跨组件使用的情况，这个时候就可以将这个数据转移到子组件中，当然数据相关的操作函数也需要转移。在父子组件通信的过程中，可能也需要一个callback去操作子组件中的状态。
执行完这个过程，你会发现第一步中的props会减少，如果还是很多的情况下，就需要为方法写一个适配器去减少props的传递。例如add和delete可以合成一个change方法，add和delete就可以转移到子组件中。
第三步：整理代码
由于每个人的需求开发对于其他人是相对封闭的，谁也不知道他改了什么？于是这个时候，会出现一些冗余代码，这个时候需要你有足够的耐心去浏览所有的函数。
首先找到组件所有的引用点，汇总所有的props，找到废弃的props，如果可以找到之前的负责人，可以问一下props废弃的原因，这样可能会发现更多的冗余代码。当然，你不确定的函数，一定不要动。
另外，每个人的代码质量是不一样的，在过代码的时候可以发现很多可以优化的地方，例如一个操作数组中每一个数据使用map，这个就一定要改掉。
最后的话
对于这个组件，之所以是选择重构而不是重写的原因是，这个组件已经跨越了两年之久，开发人员和产品的人员变动，导致没有一个人了解组件涉及到的业务。我在过代码的时候，也发现了一些产品经理都不知道的逻辑。问之前的开发者，他说他也不是很清楚里面所有的业务，这也是组件增量的原因，不敢动！
另外，重写也是需要进行多个子组件的开发，这样下来，重写比重构的好处是多了代码质量的提高。但在快速迭代的压力下，没有足够的时间去进行。于是还是选择了重构，这样拆分下来，剩下的更多的是业务逻辑的梳理，里面的操作函数实在是太多了，代码也有些晦涩，在慢慢熟悉业务之后，会和产品一起梳理全部的逻辑，那个时候再进行操作函数的优化。
目前是这样的一个打算。