Modularity Health Evaluator

When to Use

You need to assess the structural health of code modules — classes, packages, components, or services — using quantitative modularity metrics. Typical triggers:

• The user has a class with too many methods or responsibilities and wants to evaluate it
• The user has a utility package that everything depends on and wants to understand the risk
• The user is planning to extract microservices and needs to evaluate which modules are cleanly bounded
• The user mentions coupling, cohesion, or dependency problems
• The user sees cascading breakage when changing one module and wants to diagnose why
• The user wants to evaluate whether a codebase is ready for architectural migration

Before starting, verify:

• Is there a specific module, class, or package to evaluate? (At minimum, a description of the component and its dependencies)
• Does the user have access to dependency analysis tooling, or will this be a manual/descriptive assessment?

Context & Input Gathering