一次重构代码的经历
type
status
date
slug
summary
tags
category
icon
password
Blocking
Blocked by
top
URL
Sub-item
Parent item
背景
- 接手的历史代码由于历史原因，无比杂乱：
- 有ts、js两种代码，大部分ts代码还是各种any，基本没有类型约束。
- 有4个页面不知道出于什么原因（可能是想共用一些组件代码，可为什么不封装为组件呢？），代码全部耦合在一起，仅通过
if-else进行逻辑区分。 - 过多的使用Context变量（可以理解为页面的全局变量），且有各种不同的写法（react、redux-saga、react-component等）
- 使用停止维护的旧组件库。
后续相关需求迭代难度很大，所以期望优化该部分代码，减轻后续开发负担。
目标
Todo：
- 梳理代码逻辑，去掉负责的页面判断逻辑，拆分出各页面的独立代码。
- 将部分共用组件抽取为公共组件使用。
- 将无必要的Context变量转换为组件变量。
- 用新组件库替换旧组件，对应修改参数逻辑。
Not Todo：
- 不修改原有业务逻辑。
- 保留原有的scss样式文件（目前公司用styled-component）
问题
有一个实习生和我一起搞，刚开始分好两个人的页面，就闷头各搞各的，刚开始同事问我要不要封装左侧的tree组件，我顾着改代码没仔细思考就直接说用新组件库的tree搞就行。直到我改到tree时才发现封装的必要性：
- 都需要对子节点进行操作（增删改）。
- 系统的配置页中很常见。
- 样式一致但需要单独写。
于是我只能不好意思的告诉同事我要封装组件，而做时我光顾着按自己的页面写代码，就出现问题：
- 没有写文档
- 缺失部分功能。
只考虑自己的页面，导致同事不得不在我封装的代码中再加新的功能。（还好有ts，或者我的代码逻辑还行，或者同事牛批，改起来并没有遇到什么问题）
- 过度封装，导致组件复用困难
当我满心欢喜的重构完第一个页面。发现封装的组件无法用在第二个页面上，因为这个页面多了一些特别的逻辑：
- 有一个系统节点，不能删除。
- 需要配置默认节点。
- 默认节点不能删除。
而我封装时根本没考虑到这些功能，导致我不得不重新设计props，进行破坏性改动。
总结
刚开始做时，实在无法忍受原本糟粕的逻辑，出于自己的代码洁癖，我最终重新梳理了业务逻辑，代码全部重写，没有保留之前的逻辑。尽管最后重构完后非常有成就感，但是也总结很多问题：
- 刚开始一直纠结是否按照计划重构。
- 没有按照计划完成，花费了比预想中更多的时间。
- 重构的代码有很多bug，导致测试很不开心。
最后一些教训：
- 花费更多的时间制定好计划，而不是在执行中不断改变
- 不要想当然，多自测代码。
- 不要高估自己的能力，不要低估任务的难度。
- 凡事先过脑子后，再回答。
- 本来封装度和通用度是成反比的，如何恰到好处的封装是一门学问。
- 封装组件时一定要写好文档。