系统重构应从哪些维度评估？各评估维度的设置原因是什么？

首先纠正你现有思路里的偏差，保留合理部分，再补充遗漏的评估维度，所有项都附上对应的判断依据：

现有思路的调整说明 #

• 保留「重构是否提升内聚（cohesion）、降低耦合（coupling）」的评估项
  依据：高内聚低耦合是软件工程里衡量代码结构合理性的通用基础标准，达到这个标准的代码模块职责清晰，跨模块依赖少，后续改代码的时候影响范围可控，不会出现“改一个地方炸十个不相关功能”的问题。
• 保留「重构是否提升代码可读性」的评估项
  依据：代码整个生命周期里80%的时间是给后续接手的开发者读的，不是给写第一版的人自己看的，可读性差的代码哪怕结构再“优雅”，后续维护的人看不懂，照样容易改出bug。
• 调整「重构后新增功能是否比重构前更便捷」的表述
  原表述存在概念偏差：重构的核心定义是不改变软件外部可观测行为的前提下调整内部结构，“新增功能”本身不属于重构的范畴，硬把这个放进来等于把重构和功能迭代混为一谈，应该调整为「原有功能的后续迭代、扩展成本是否降低」。
  依据：如果重构之后，给原有模块加个常规需求要改的地方比之前还多、要绕的逻辑比之前还复杂，那这个重构本质上就是做了无用功，甚至是负优化。
• 调整「重构是否实现性能提升」的评估优先级
  性能提升不是重构的必达目标，只能算可选加分项。很多时候为了拆分过长函数、抽离重复逻辑做的重构，会带来纳秒/毫秒级的微小性能损耗，只要损耗在业务可接受的阈值内就完全不影响重构价值。
  依据：绝大多数业务场景下，开发者的人力维护成本远高于服务器的性能成本，重构的核心目标是降低长期维护成本，不是优先做性能优化，没必要把性能提升当成硬指标。

补充的评估要点及依据 #

• 评估重构是否清理了原有的典型代码坏味道
  重点看重复代码、过长函数、过大的类、改一个需求要动N个文件的霰弹式修改、绕七八层对象才能拿到数据的消息链这类常见问题有没有被解决。
  依据：重构的触发起点往往就是识别到了明确的代码坏味道，这是比“高内聚低耦合”更具象、更容易落地校验的评估抓手，不会变成空泛的概念讨论。
• 评估重构后的可测试性变化
  重点看重构之后原有自动化测试用例是否能全部跑通，拆分后的模块是不是更容易写单元测试，有没有出现为了测一个小功能要mock十几层依赖的情况。
  依据：可测试性是代码质量的核心指标，如果重构完原有测试挂了一堆、甚至代码变得根本没法写单测，后续迭代出bug的概率会飙升，完全违背了重构降低长期风险的初衷。
• 评估重构的投入产出比
  核算重构投入的开发时间、重构过程中可能引发线上问题的风险成本，对比后续1-2个版本里能节省的维护时间、迭代提效的收益，看两者是否匹配。
  依据：工程落地不是搞纯技术审美，重构本质是工程决策，如果一个重构要花3个人做一个月，做完之后每年也就省两三天的改代码时间，那这个重构从根上就没有价值。
• 评估重构后的缺陷密度变化
  对比重构前后同模块在测试阶段、线上运行的bug出现概率，看是不是因为逻辑拆分更清晰，减少了容易写错的分支判断、隐藏的逻辑漏洞。
  依据：代码质量的最终衡量标准是运行稳定性，如果重构完之后bug比之前还多，哪怕代码写得再“好看”、结构再“符合规范”，也是失败的重构。
• 评估重构是否符合团队现有开发规范
  重点看命名规则、分层逻辑、通用组件/工具类的复用是不是和团队现有约定一致，有没有出现重构作者自己发明一套写法、绕开团队通用能力的情况。
  依据：代码是团队协作的产物，如果重构完的代码只有作者自己能看懂，其他同事接手要重新学一套自定义规则，反而会提高团队整体的维护成本。

内容的提问来源于stack exchange，提问作者Stexu