I found interesting approach on the subject being developed by Structure 101 team. They introduced Excessive Structural Complexity, XS in short.

They pointed that an architecture may be seen in two dimensions: Tangle which is structural complexity on design level and Fat which is "too much code in one place". More precisely:

Tangle
it's set of items being in a cyclic dependency; tangle is counted on packages level; for each set of tangled items a Minimum Feedback Set (MFS) is calculated which is a minimum set of dependencies that would need to be removed in order make the graph clean
Fat
for methods it's Cyclomatic Complexity, but for clases and packages it's a number of dependencies between them
XS is an excessive ie. unnecessary complexity, so some thresholds must be given. Indeed, you are able to define thresholds for Tangle, and also for Fat on each method, class, leaf package, package (design) levels. You may also trust the defaults. Those come from Structure 101 team experience.

After normalization, XS gives one single number expressing an excessive complexity of a piece of code. Depends on code level, a XS might be Fat mean, Tangle mean or sum of these two.

It is very interesting because it gives fancy measure for each architectural level. It works well on: methods, classes, packages, layers and more abstract components levels.

Intersecting XS and number of commits to a repo, we might more accurately say what is worth to be refactored and what is not. (Idea of this intersection comes from Michael Feathers, but, as far I remember he use the Cyclomatic Complexity instead of XS)

For more information read the whitepaper or try out the tool.

.