Just like we can measure complexity of code and algorithm, are there any metrics for measuring architecture/design/solution space complexity.
|
|
Take a look at the Dependency Structure Matrix. There are a few good metrics that can come from this. |
|||
|
|
|
Here is an intuitive solution: the complexity of a program is the size of the shortest well-written (i.e. readable) code that implements it. This is not full quantitative, but this is something that I believe a good programmer may judge by experience. Rejecting non-readable code means that you get a measure of the conceptual complexity, which would disappear if hyper-optimized, obfuscated code was taken into account. Thus, some tasks just require a certain number of concepts. I almost always embody these concept in a certain number of classes, class methods, and functions. The minimum number of such classes, methods and functions in a well-written, understandable program says something about the complexity of a program. |
|||||||||||
|
|
Actually, we can't measure complexity of code and algorithm. Every single such metric proposed has been shown, when applied to real programs written by real programmers, to be strongly correlated to SLOC - and SLOC is a lot easier to measure: just count carriage returns. (Yes, I know SLOC can be gamed. The games, and the game-player's job, generally don't survive past the first code review. Or at least they shouldn't.) |
|||
|
|