Complexity Review 是一个面向软件设计复杂性的审查工具，其核心理念是：复杂度是任何使系统难以理解或修改的结构，判断每个发现应从读者而非写者的成本出发。它基于 John Ousterhout 的《A Philosophy of Software Design》中的“危险信号”来识别问题。
用途
该工具用于审查代码差异（diff）、拉取请求（PR）、模块或设计文档，帮助识别不必要的复杂度。它关注变更是否增加了理解或修改的难度，而非代码风格。
主要能力
工具定义了复杂的症状（变更放大、认知负荷、未知未知）和成因（依赖、模糊），并列出数十个红色信号，如浅模块、信息泄漏、时间分解、过度暴露、单次使用方法、调用方胶水、传递方法、传递变量、全局状态、相邻层相同抽象、重复、特殊与通用混合、特殊情况、连体方法、配置推卸、暴露内部、实现继承、异常蔓延、注释重复代码、实现污染接口、模糊命名、同名多义、难以描述、非显而易见代码等。每个信号都有具体描述，帮助审查者定位问题。
使用方式
流程包括：确定范围（如 git diff <base>...HEAD 及其涉及的接口，阅读调用方而非仅变更行）；扫描所有红色信号，记录具体位置和成本；对照“过度”标准检查每个发现，丢弃不合格项；按成本从高到低报告。输出格式为每个发现一条记录，包含标志、路径:行号、问题描述、成本（症状通过依赖或模糊导致的具体后果）和最小修复建议。最后给出一行结论。
适用场景
适用于代码审查、设计评审、重构指导等场景，帮助团队持续改进软件设计。
限制
工具明确列出“过度”情况不应标记，如隐藏调用方真正需要的信息、为加深模块而合并无关代码、调度器或多个接口实现（相同签名但各自增加真实功能）、将可读的长方法按块拆分（深度优于长度）、将约定强加于实际不同的事物。这些限制避免误报。