可维护性指数怎么看
可维护性指数（Maintainability Index）把若干代码量指标合成为一个零到一百分的分数，常见输入包括 Halstead 体积、圈复杂度与逻辑行数，部分工具还加入注释比例。它属于粗略导航类指标：适合观察同一模块在多个版本之间的趋势，以及在海量代码中把注意力引向异常点。用它做跨语言比较或个人评价都不合适，因为权重与实现细节各不相同。
输入与用法
| 主要输入 | Halstead 体积、圈复杂度、行数或逻辑行数 |
|---|---|
| 取值范围 | 通常零到一百分，常被简化为红黄绿分档 |
| 正确用法 | 版本趋势观察，以及对低分模块下钻 |
| 错误用法 | 跨语言比较数值，或据此评价个人 |
典型使用场景
- 模块质量趋势：每个发布周期记录核心模块指数，观察是否持续下滑
- 初步筛选：在一批模块中找出分数异常偏低的对象，再人工核查原因
- 重构前后对比：确认结构调整后指数回升，作为偿还验收的辅助证据
- 新人上手难度评估：低分模块通常需要更多时间理解，可安排结对讲解
- 交付评审：把指数变化作为评审提问的线索，而不是判定结论
使用建议
使用建议
# 建议做法
- 每个版本记录核心模块的指数，观察趋势
- 指数下降时下钻到具体函数，看是新增分支还是复杂度聚集
# 避免做法
- 跨语言或跨工具比较数值（权重与口径不同）
- 给模块排名并据此问责开发者分档与处理方向
| 分档 | 通常表现 | 处理方向 |
|---|---|---|
| 高分 | 结构简单、分支少 | 保持，不必额外投入 |
| 中分 | 复杂度可控但存在长函数 | 局部提炼，优先高频改动部分 |
| 低分 | 函数长、分支多、嵌套深 | 人工核查后按热点排序处理 |
| 分数骤降 | 某次提交引入大量分支 | 定位该次改动，评估是否可拆分 |
| 分数偏高但缺陷多 | 指标未覆盖的问题 | 结合缺陷与变更数据交叉判断 |
指数下降不等于质量事故：新增功能本身会带来复杂度。判断时应看变更构成，区分是必要的业务复杂度增长，还是结构劣化导致的堆积。
不同工具对 Halstead 量与行数的计算细节存在差异，同一份代码在不同工具里的分数可能明显不同，因此该指标只在同一工具的同一配置下做纵向比较。
落地检查清单
- 同一工具与配置下做纵向比较
- 指数变化与变更内容对应说明
- 低分模块人工核查后再决定是否重构
- 不把指数用于个人评价或跨团队排名