之前有组织成员进行一轮项目重构，但结果自己不是很满意，总结一下存在的问题。
背景
之前负责的某项目 A，在经历多轮迭代后，项目变得 bug 众多，且难以维护。任务就是带领组员进行一轮重构，解决项目中开发上的痛点、同时修复已有的问题。
实施
由于自己也离开项目 A 有一段时间了，对项目中存在的问题，也不是那么清楚，于是采取的策略分为两步
- 自己迅速查阅整个项目，确定相关的任务列表
- 与组员沟通，从他们身上收集任务
我大概发现的问题有如下几种情形
- 滥用 any，导致重构不敢下手
- 原本通用的设计，后面被加入很多的业务逻辑，变得不再通用
- 组件 props 命名不清晰，责任边界不清晰
- 甚至还存在 copy 组件的情形，然后只是再原有的基础进行修改
- 存在很多的僵尸代码，舍不得删除，结果带来误解
从组员收集上的任务来看
- 更多的是聚焦在自己负责的模块，想进一步完善的
- 还有就是，的确是痛点，但影响范围不大，或者不恶劣，属于不紧急的那种
沟通之后，大致确定下来了一个任务列表，但我同时交代了两件事情（然而并没有什么卵用）
- 可以互相提需求
- 可以互相审阅 pr
结果
结果其实不太尽如人意，最终重构有点像是
- 目录移动大会
- 僵尸代码清理大会
反省的原因有如下几点
- 对于收集上来的任务，需要进一步沟通和筛选
- 值不值得现在做
- 怎么做？明确好怎么具体方案
- 明确好目标
- 任务没有区分优先级和难易程度
- 对任务进行紧急与重要程度的四象限划分，抓住主要矛盾
- 如果任务确实有点难度且重要，该争取工时就尽早争取
总结
技术上
- 成员之间的 Long Life Branch 会导致重构束手束脚，一边重构，一遍迭代，让人奔溃
- 项目中很多地方滥用 any，缺少完善的 typing，导致重构困难且脆弱
任务管理流程上需要进一步完善
- 事前：做什么（排优先级很重要）
- 列出任务清单
- 列出每一个任务对结果的核心期待（进度、质量、效果）
- 对照目标评估任务
- 通过成果收益来看重要程度（和目标的匹配度）
- 通过后果损失来看紧急程度
- 事中：怎么做
- 保证有效执行
- 事后：怎么做更好
- 完善流程机制
于此同时：任务来源自上而下，还是自下而上是一个值得思考的问题