大家好！经过近一年和100次提交，我决定发布我的新个人工具：***Pymetrica***。 PyPI 页面：[https://pypi.org/project/pymetrica/](https://pypi.org/project/pymetrica/) Github 仓库：[https://github.com/JuanJFarina/pymetrica](https://github.com/JuanJFarina/pymetrica) * **我的项目有什么作用** Pymetrica 分析 Python 代码库并生成以下报告： **- 基础统计**：文件、文件夹、类、函数、LLOC（logical lines of code）、层次结构等。 **- ALOC**：抽象行数（表示抽象性或间接性）的比率） **- CC**：循环复杂性和其每 LLOC 的密度。 **- HV**：海斯代体积。 **- MC**：可维护性成本（一个简化的MI式指标，结合复杂度和大小）。 **- LI**：分层不稳定性（层次结构之间的耦合）。 **- 架构图**：层次结构和模块之间的依赖关系（数量的导入）。 目前，工具输出终端报告。计划特性包括CI/预提交集成、追加报告格式和通过`pyproject.toml`的配置。 * **目标受众** \- 关注可维护性的开发者。 \- 评估代码库的技术负责人/架构师。 \- 团队对子包或分层进行重构分析的团队。 自从工具是“大小独立”的， 你可以在整个代码库上、在一个分层上或在任何更下级模块上分析。 * **对比** 我已经使用Radon、SonarQube、Veracode和Blackduck等工具多年，但发现它们的相关复杂度指标并没有太大的用处。我爱好对编程设计有很好的人工智能，有时又想要现实主义的避免过早的抽象和优化。 我发现在任何地方使用100%的代码覆盖率（一种典型的CI检查指标） **并且** 有针对几乎所有代码行进行抽象的编码库，是事实上让你将您的代码库大小乘以4。 在我发现抽象很好的一般，我也不想在维持4倍于生产值中的实际代码大小上花费太多时间。 因此，我的第一步就是在Pymetrica中通过一个措施来评估“抽象性”。 这就是ALOC的诞生（抽象行数），它代表抽象性或者间接性，只需要执行某些处于其他地方的代码的行数。这还包括抽象类、接口以及其他任何的类（函数定义、函数调用的等）。 当然，这并不是重回结构化编程，但也不是要在抽象性上花费太多。 然后我继续阅读了其他的软件尺寸，特别是如何处理“复杂性”。 我意识到在大多数尺寸（循环复杂性、Halstead体积、可维护性指标等）中，不在代码库上，而在“模块”或“函数”的范围上。 因此，我决定实现“代码库级别”上这些尺寸上。 这是因为它们从未在任何情况下告诉我SonarQube关于认知复杂性不应该在各个项目上出现的糟糕代码base。 我在Pymetrica上实现的最大目标是它将是一个 **有用指标**，让您看到一个得分并能够立即理解需要做什么： MC太高了？ 是因为大小还是因為高CC和HV导致的MC高？ 您可以轻易得到答案。 并且您可以轻易看到一个子包（分层）是否是导致它的主要原因。 如果您的CC和HV导致了MC（仅在MC中），则您可能该开始创造一些抽象和间接性，去清理一些不好的代码等。 您的LLOC和ALOC会增加，但您的原始MC会迅速递减。 如果您的LLOC大小导致了MC，您可以使用ALOC指标来检查是否有太多抽象，或者此时是拆分编码库或子包，并可能增加开发团队。