How do you rate the design, how do you rate the complexity?

Question

We all know that it's simple, right?

I saw that complexity is measured as the number of interactions between systems, and I think this is a very good place to start. However, besides sensations in the intestine, what other (preferably more objective) methods can be used to determine the level of complexity of a particular design or piece of software?

What are your favorite rules or heuristics?

Answer 1

Here are mine:

1) How hard is it to explain to someone who understands the problem but did not think of a solution? If I explain the problem to someone in the room (who probably already understands the problem, if they are in the room), and can explain this solution, then it is not too difficult. If it takes more than an hour, there is a chance that the solution will be redesigned.

2) How deep inside the nested functions do you need to go? If I have an object that needs a property held by an object held by another object, then there is a good chance that what I'm trying to do is too far from the object itself. These situations become problematic when trying to make objects thread safe, because there will be many objects of different depths from your current lock position.

3) Are you trying to solve problems that have already been resolved before? Not every problem is new (and some argue that this is actually not the case). Is there an existing model or group of templates that you can use? If you can’t, why not? It’s all good to make your own new decisions, and I’m all for it, but sometimes people have already answered this problem. I will not rewrite STL (although I tried at some point) because the solution already exists and it is good.

Answer 2

When I attended a seminar on integrated systems modeling at the New England Institute for Complex Systems ( http://necsi.org/ ), one of the measures that they used was the number of system states.

For example, if you have two nodes that interact, A and B, and each of them can be 0 or 1, your possible states are:

AB 0 0 1 0 0 1 1 1 

Thus, a system of only 1 interaction between binary components can actually lead to 4 different states. The fact is that the complexity of the system does not necessarily increase linearly as the number of interactions increases.

Answer 3

Difficulty can be appreciated through communication and as cohesive - all of your objects. If something has too much grip or is not cohesive enough, then the design will become more complex.

Answer 4

Good measures can also be the number of files, the number of places where the configuration is stored, the compilation order in some languages.

Examples:

.- properties files, database configuration, xml files for storing related information.

.- tens of thousands of classes with interfaces and database mappings

.- extremely long and complex assembly file (build.xml, Makefile, others ..

Answer 5

If your application is built, you can measure it in terms of time (how long it takes for a particular task to complete) or calculations (how much code is executed each time the task starts).

If you have only projects, you can see how many components of your design are required to complete a given task or to complete an average task. For example, if you use MVC as a design template, you have at least 3 components that are affected by most tasks, but depending on your project implementation, you can get dozens of components (cache in addition to 3 layers, for example).

Answer 6

Finally something LOC can really measure? :)

I believe that complexity is best viewed as the number of things that need to be interacted.

An integrated design would have n levels, while a simple design would have only two.

Complexity is needed to solve problems that simplicity cannot overcome, so this will not always be a problem.

There is a problem of defining complexity in general, since complexity usually has a problem associated with it. Something can be difficult to understand, but just look (a very short code, for example) The number of interactions that get this web page from the server to your computer is very complicated, but the abstraction of the http protocol is very simple.

Thus, having a task (for example, maintenance) before choosing a measure, it can make it more useful. (i.e. adding a configuration file and writing to the application increases its objective complexity [yes, only a little confidently], but simplifies maintenance).

Answer 7

There are formal metrics. For example, read Cyclomatic Complexity .

---

Change

Also see Function Points . They give you a quantitative measurement of the complexity of the system without regard to the gut.