Here is a good start:
http://misko.hevery.com/code-reviewers-guide/The first thing I would do is look at usage of global state. Are there data objects used from the global scope? Are dependencies imported and then used directly from the global scope rather than being passed to a constructor? Are there any mutable singletons?
The second thing I would do is look at constructors. Are constructors calling a lot of functions (implication of global state usage), are they doing much besides taking arguments and storing them as object state? Do objects require an initialization method be called?
The third thing I would do is look for "law of Demeter" violations (https://en.wikipedia.org/wiki/Law_of_Demeter):
Explicit violation:
doesSomething.callSomethingElse().thatCallsSomethingElse().thatCallsEvenAnotherThing()
Not any less of a violation but looks better:
a = doesSomething.CallSomethingElse()
b = a.thatCallsSomethingElse()
c = b.thatCallsEvenAnotherThing()
Next I would make percentiles of lines of code per scope. How many lines of code does the average function have? How many lines of code does the average class have? As well as look at un scoped functions (implies global state usage) and the outliers for lines per scope (what does the class with the most lines of code in scope look like, what does the longest funciton look like)?
I would probably keep raw counts of the number of functions, classes, imports, if's, and loops themselves.
Obviously anywhere you see lines of code, it might make more sense to look at number of ifs and loops since that is probably a more accurate measure of complexity.
I would definitely (and actually probably first) look at the database tables/how they are represented in the code.
More qualitatively, I would look at what kind of logging and time series data are exported.
I would look at how exceptions are handled in the main loop.
I would look at separation of business logic from server logic.
I would look for strong layers (business logic probably shouldn't be intermingled with presentation logic).
I would probably grep a sample of TODOs and grep a sample of comments.
I would look at test coverage and test implementation (unit and integration).
I would look at test run time.
I would look at build time.
I would try to look at a dependency graph.
I might look at git blame to see how many people edit how many different files.
I would look for bazel/build logic.
I would look at the build script itself to see how assets are generated and stored.