为什么要写重构计划
背景
由于近期需要给公司重构投放系统，需要起草一个重构方案为重构计划定目标、时间、完成节奏。
书写情况
在书写重构计划时候，使用大模型相关的工具可以拿到一个较好的大纲的。比如我拿到一个这样的大纲。
当然，我们要根据公司与系统的不同情况去做适当的变更，比如我现在的系统主要的问题，在于需求迭代效率，未来产品功能点的支持上。且不是一个对外的产品，是一个内部使用的系统。普遍来说，这种系统的重构压力不在于对外的使用上，而在于其他因素（如，我的系统主要是数据的灰度与回滚上，要保证重构过程中数据的准确性）
所以，在细节上，我要把我数据的切换与灰度。而且由于人员少的原因，我们的重构的原因还有在于提高整体需求迭代的研发效率（这个情况肯定在大公司，是不会出现的，毕竟基建完全），从编码、测试、发布都需要做相关的事项。
大纲
一、重构目标与范围确定
- 明确重构的主要目标
-
- 提升系统性能，包括响应时间、吞吐量等。
-
- 增强系统稳定性和可靠性，减少故障发生频率。
-
- 改善系统可维护性，使代码更易于理解和修改。
-
- 提高系统可扩展性，方便未来功能的添加和扩展。
- 确定重构的范围
-
- 特定的模块或组件。
-
- 整个系统的架构层面。
-
- 数据库结构调整等。
二、现有系统评估
- 性能评估
-
- 进行性能测试，分析系统的响应时间、资源利用率等指标。
-
- 识别性能瓶颈所在的模块或代码段。
- 代码质量评估
-
- 检查代码的规范性，包括命名规范、注释等。
-
- 分析代码的复杂度，如循环复杂度、代码行数等。
-
- 查找潜在的代码坏味道，如重复代码、过长的方法等。
- 架构评估
-
- 审查系统架构是否合理，是否符合当前的业务需求和技术发展趋势。
-
- 评估系统的可扩展性、可维护性和可测试性。
- 数据库评估
-
- 分析数据库结构是否合理，是否存在冗余数据或性能问题。
-
- 检查数据库索引的使用情况，是否需要优化。
三、重构计划制定
- 优先级排序
-
- 根据评估结果，确定重构任务的优先级。
-
- 优先处理对系统影响较大的问题，如性能瓶颈、严重的代码质量问题等。
- 时间安排
-
- 为每个重构任务分配合理的时间，制定详细的时间表。
-
- 考虑到可能出现的意外情况，预留一定的缓冲时间。
- 资源需求
-
- 确定重构所需的人力资源，包括开发人员、测试人员等。
-
- 评估是否需要额外的硬件资源或软件工具。
四、重构实施
- 代码重构
-
- 清理代码坏味道，如提取重复代码、简化复杂方法等。
-
- 优化算法和数据结构，提高性能。
-
- 改进代码的可读性和可维护性，添加必要的注释和文档。
- 架构调整
-
- 对系统架构进行优化，如采用更合适的分层架构、设计模式等。
-
- 提高系统的可扩展性，方便未来功能的添加。
- 数据库重构
-
- 优化数据库结构，去除冗余数据，提高查询性能。
-
- 调整数据库索引，确保查询效率。
- 测试与验证
-
- 在重构过程中，持续进行单元测试、集成测试和系统测试。
-
- 确保重构后的系统功能正常，性能得到提升。
五、重构后的评估与优化
- 性能评估
-
- 再次进行性能测试，对比重构前后的系统性能指标。
-
- 分析是否达到了预期的性能提升目标。
- 代码质量评估
-
- 检查重构后的代码是否符合规范，质量是否得到提高。
-
- 用户反馈收集
-
- 收集用户对重构后系统的反馈，了解用户体验是否有所改善。
- 持续优化
-
- 根据评估结果和用户反馈，进行进一步的优化和改进
实践
分步骤计划
在工作中，我们需要制定对应的事项，以及里程碑，去安排相应的计划。所以我安排了三个大的节点
- 列出系统现有的问题，以及重构后的风险、收益
- 与产品对齐系统的需求计划
- 与Boss确定下重构范围以及收益
- 最终制定可追踪、可使用的量化的计划
注意点
- 需要很了解系统
- 了解系统的收益在哪里。
具体实践
在初步定下先行技术重构的计划后，我的重构方案基本上到了可以实施的里程碑了，所以，做下总结。
在11月1号确定以关键模块做技术重构为定论，总共历时了3周的时间，每一周一个会议的节奏，讨论与细究这个重构方案。
每一周都有一个主要的议题，以及一个重要的节点，去推进下一个节点。- 第一次会议：主要讨论现有系统问题，以及产品的未来演进方向，并提出相应的技术解决方案，去适配未来产品的演进，做出部分的取舍。会议结论，对齐产品的主要演进方向，以及技术的整体方案。
- 第二次会议：产品第一大板块的产品细节，以及整体产品UI的灰度演进。整体技术方案上，每个模块的具体执行维度的拓扑序，以及按照产品第一模块的时间预期。会议结论，并行技术重构与产品第一大模块重构的时间预期对齐，并提出先串行关键模块技术重构的时间是多久的问题；还有，提出要求资源的述求。
- 第三个会议：讨论先串行关键模块技术重构的与并行技术重构的优缺点，并讨论串行关键模块技术重构的难点、耗时、灰度方案、回滚方案以及人员安排。会议结论，确定先串行关键模块技术重构，以及确定执行细节（关键模块的需求支持、灰度方案、回滚方案）与实施方式。
使用工具上与花费的时间
- 第一次会议：由于会议的要点在于整体，与问题的罗列。所以，主要是通过前后的架构图、现有关键流程的时序图去体现改进前后主要模块的变更。花费时间的点在于对系统细节的把握，罗列现有的问题（如果，之前有问题的收集文档、以及相应的SOP的话，会好很多），业界上已经有标杆方案，需要的是折中（适合公司的方案），这在后期细节上去细究便可。
- 第二次会议：由于会议的要点在于评估工期，而评估工期需要技术点的拓扑，以及产品功能点的契合。所以，我主要使用表格去罗列问题，大的维度上解决什么问题，在以这个维度上去更细分的拆分问题以及相应的前置依赖任务（在一个完整的小的任务项），对应的工期（人天）。再又以产品的维度做相关任务的匹配，这块使用了甘特图去表示相应的依赖任务，以及完成相应产品模块的时间。我这里主要花费在甘特图的使用上，由于我要体现任务间的依赖关系与工具，还要体现技术与产品目标之前的依赖关系，很难以简单的甘特图画出来。（正在精进这一块）
- 第三次会议：会议的重点在于技术的细节安排上，以及对灰度与回滚方案的讨论，所以，使用工具上主要在各个模块的关系图上，以及相应主要工具的灰度与回滚时的使用。这里主要的时间花费，还是在想清楚灰度与回滚方案的措施，以及较好的灰度节点在哪。
