首选radon工具分析python代码复杂度，1. 安装工具：使用pip install radon；2. 分析圈复杂度：运行radon cc 文件或目录，关注cc值超过10或分级为c及以上的代码；3. 分析可维护性指数：运行radon mi 文件或目录，mi低于20需关注，低于10优先重构；4. 集成到ci/cd：在github actions等流程中添加radon检查步骤，设置阈值和排除目录，确保代码质量持续受控，从而有效管理技术债并提升代码可维护性。
Python代码复杂度分析，我通常会首选
radon工具。它能快速量化代码的圈复杂度、可维护性指数等关键指标，帮助我们直观地评估代码质量和潜在风险。说实话，这玩意儿用起来真挺顺手的，能让你对代码的“健康状况”一目了然。
解决方案
要用
radon分析Python代码，其实非常直接。我个人觉得它的命令行界面设计得挺直观的，上手几乎没什么难度。
首先，你得把它装上。这很简单，就像装其他Python包一样：
立即学习“Python免费学习笔记（深入）”；
pip install radon
装好之后，你就可以开始分析了。最常用的就是分析圈复杂度（Cyclomatic Complexity，简称CC）和可维护性指数（Maintainability Index，简称MI）。
比如，你想分析一个名为
my_module.py的文件：
分析圈复杂度：
radon cc my_module.py
这会给你一个列表，显示每个函数、方法或类的圈复杂度。圈复杂度越高，代码的逻辑分支就越多，测试起来越麻烦，也越容易出错。我一般会把CC值超过10的函数标记出来，超过20的就得严肃考虑重构了。
分析可维护性指数：
radon mi my_module.py
可维护性指数是一个综合指标，通常在0到100之间。值越高表示代码越容易维护。我通常会把MI值低于20的模块标记出来，这基本上意味着它快变成“遗留代码”了，得优先重构。低于10的，嗯，那可能就是个“烫手山芋”了。
你也可以一次性分析整个项目目录：
radon cc . -a -s -nc # 分析当前目录所有Python文件，显示平均值和总和，不显示颜色 radon mi . -a -s # 分析当前目录所有Python文件，显示平均值和总和
radon还支持很多参数，比如排除特定文件或目录（
--exclude）、设置阈值（
--min）等。我经常用
--min A或
--min B来筛选出那些复杂度较高的代码，这样就不至于被一大堆绿色的“A”级代码刷屏，能更快地聚焦到问题区域。
为什么我们需要关注代码复杂度？
说实话，这个问题我以前也想过，觉得不就是写代码嘛，能跑就行。但后来吃过几次亏，才真正意识到代码复杂度不是个小问题。你想啊，当一个函数有几十个
if-else分支，或者一个类里塞满了各种逻辑，调试起来简直是噩梦。我以前就遇到过一个bug，最后发现是某个深层分支里的一个条件判断写错了，光是理清那个函数的逻辑路径就花了大半天。
关注代码复杂度，实际上是在做风险管理。高复杂度的代码意味着：
- 更高的错误率： 逻辑分支越多，漏掉某个测试用例的可能性就越大，潜在的bug也就越多。
- 更难理解和维护： 新来的同事，甚至过了一段时间的你自己，再看这段代码时，会感到非常吃力。这直接影响了团队的开发效率和项目的迭代速度。
- 测试成本飙升： 要完整覆盖所有逻辑路径，需要的测试用例数量会呈指数级增长。这在敏捷开发里简直是灾难。
- 重构阻力大： 复杂度高的代码往往像一团乱麻，牵一发而动全身，让人望而却步，最终导致技术债越积越多。
所以，我把代码复杂度分析看作是代码质量的“体检报告”。定期检查，能让你及时发现并处理那些潜在的“病灶”，避免它们演变成大问题。
如何解读radon的分析报告？
radon不仅仅是告诉你一个数字，它还会把这些数字分级，这对我理解报告非常有帮助。
-
圈复杂度 (CC) 的分级：
- A (1-5): 优秀的，低风险。
- B (6-10): 良好的，中等风险。
- C (11-20): 一般的，高风险，需要关注。
- D (21-30): 差的，非常高风险，强烈建议重构。
- E (31-40): 糟糕的，难以维护。
- F (41+): 极差的，几乎无法维护。
我通常会把C级及以上的代码作为重点关注对象。当然，有些算法或者状态机，天生圈复杂度就会高一点，这得结合具体业务场景来判断，不能一概而论。但大部分业务逻辑，如果CC值到了D甚至E，那绝对是个警示。
-
可维护性指数 (MI) 的分级：
- MI > 20: 绿色，易于维护。
- 10
- MI
MI值是我个人最看重的指标之一。一个低MI的模块，意味着它可能充斥着冗余代码、命名不规范、缺乏注释等问题，这些都会让维护者头疼。我发现把MI值低于10的模块标记出来，这基本上意味着它快变成“遗留代码”了，得优先重构。
除了这两个核心指标，
radon还能分析其他一些指标，比如：
- LOC (Lines of Code): 代码行数。
- LLOC (Logical Lines of Code): 逻辑代码行数，不包括空行和注释。
- SLOC (Source Lines of Code): 源文件代码行数。
- Halstead Metrics: 包括程序长度、词汇量、难度、工作量等，这些指标能从信息论的角度评估代码的复杂性。虽然不如CC和MI直观，但在某些深层次分析时也很有用。
解读报告时，我不会只看单个数字，而是会结合上下文。比如，一个很小的辅助函数，CC是5，那很棒。但一个核心业务逻辑函数，CC是25，那问题就大了。同时，我也会关注整体项目的平均值和趋势，如果平均复杂度在不断上升，那说明团队在代码质量管理上可能出了问题。
如何将radon集成到持续集成/持续交付（CI/CD）流程中？
将
radon集成到CI/CD流程中，是我认为发挥其最大价值的方式。这就像给你的代码库设置了一个自动的“质量门禁”。每次代码提交或合并请求时，CI/CD流水线都会自动运行
radon检查，如果代码复杂度超过了预设的阈值，就直接阻止合并，或者至少发出警告。
我发现把
radon集成到CI/CD里后，团队对代码质量的重视程度明显提高了，因为每次提交都会有反馈，没人想成为那个“破坏构建”的人。
以GitHub Actions为例，你可以在
.github/workflows目录下创建一个YAML文件（比如
code_quality.yml）：
name: Code Quality Check
on:
push:
branches:
- main
- develop
pull_request:
branches:
- main
- develop
jobs:
analyze_complexity:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.x'
- name: Install radon
run: |
pip install radon
- name: Run Radon Cyclomatic Complexity check
run: |
# radon cc . --min C --exclude "venv/*,tests/*"
# 这里我设置了一个比较严格的阈值，任何C级及以上的复杂度都会导致CI失败
radon cc . --min C --exclude "venv/*,tests/*" --max-cc 10 || { echo "Radon CC check failed: Complexity too high!"; exit 1; }
continue-on-error: false # 如果失败，则中断流程
- name: Run Radon Maintainability Index check
run: |
# radon mi . --min B --exclude "venv/*,tests/*"
# 任何B级及以下（MI低于20）的可维护性都会导致CI失败
radon mi . --min B --exclude "venv/*,tests/*" --min-mi 20 || { echo "Radon MI check failed: Maintainability too low!"; exit 1; }
continue-on-error: false在这个例子里，我设置了两个
radon检查步骤：一个针对圈复杂度，一个针对可维护性指数。
--min C表示只要有C级及以上（复杂度高）的代码就报错，
--min B表示只要有B级及以下（可维护性低）的代码就报错。
--exclude参数可以排除一些不需要检查的目录，比如虚拟环境（
venv）和测试文件（
tests）。
当然，一开始集成的时候可能会有好多警告甚至失败，因为现有的代码可能已经积累了一些复杂度。但别灰心，这是改进的机会。你可以先设置一个比较宽松的阈值，比如只检查F级的代码，然后逐步收紧，或者只针对新提交的代码进行检查。关键在于，这是一个持续改进的过程，而不是一次性的完美。
