Where is complexity swelling?

Question

Many of our design decisions are based on our gut feeling on how to avoid difficulty and bloating. Some of our fears of complexity are true, we have a lot of painful experience in discarding obsolete code. In other cases, we learn that a specific task is actually not as complex as we expected it to be. We notice, for example, that keeping 3,000 lines of code in one file is not that difficult ... or that using special "dirty flags" is actually not a bad OO practice ... or that in some cases it is more convenient to have 50 variables in one class that have 5 different classes with shared responsibilities ... One friend even stated that adding functions to a program does not really add complexity to your system.

So, where do you think complexity complexity comes from? Is it the number of variables, the number of functions, the number of lines of code, the number of lines of code per function, or something else?

Answer 1

I think that this came from your problem area, any software project will sooner or later become bloated and complex as it detects a new error or new functions.

at the first design, you will never know or understand what problems are ahead, it’s natural, and a modification to solve this problem that will make your code evolve from the original design path, and basically we consider it complex, as it is not our initial design.

To prevent this best practice, it will regularly reorganize your codes, and also allow your codes to evolve, since no codes are perfect in any iteration. you can read a book on refactoring, it will explain all the techniques for handling complexities and bloated codes.

e.g .: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

Answer 2

Complexity does not "creep" from a variable counter, the number of functions, or anything else in your code or models. Complexity may or may not be. You can (try) measure it by counting variables or functions, but the number of variables or functions is not a source of complexity. This is a subtle but important point.

Complexity comes from two sources:

• The problem domain that the system is accessing. Launching a space shuttle is inherently more complex than managing a video store.
• selected solution . Different models and implementations can make it easier or harder to solve the same problem. This is where developers' skills can shine or hide the process.

So, think about the problem area you are working in. It's complicated? How difficult is it? Then think about what solutions you create to meet your needs. Do they comply with KISS principles? Are they skinny and elegant?

of the consequences:

• You cannot get rid of the complexity of a problem area using simple solutions. This residual complexity will always be there.
• Refactoring, as a method that works in a decision domain, can reduce or increase complexity. Do not think that it will reduce it. See refuctoring .

Answer 3

Encapsulating, but not the typical way, "everything I do with the file, I call the .xyz () file."

What I mean by encapsulation is encapsulation looking the other way - when you change something, how much more do you need to think? What is the smallest area you can deal with when working on something?

Ideally, you can reduce less than a few hundred lines to a single file and not worry about one thing outside of that file.

Answer 4

The physicist will say entropy and the second law of thermodynamics. Why should software be different from the rest of the physical world in which it lives? And the fix is ​​the same as in the non-software world: you need to expend energy to clear it with thinking and refactoring.

Not very useful on the surface, I know. It seemed to me that I read your question about what you would like to make a list of sources that you could observe in order to try to contain complexity and bloat.

My answer says it will never work. The second law will not be denied.

Answer 5

The great complexity of the code base is due to the lack of a component. The complexity comes from the dependency graph between your classes. If classes are embedded in components with clear boundaries, complexity is summed up according to the dependency graph between components. If this graph is multi-level (Direct Acyclic Graph), the complexity of the application is greatly reduced, especially if you have hundreds of components.

A tool such as NDepend is needed to handle large code complexity scenarios. Disclaimer: I am one of the developers of this tool

You can read on the topic:

• Fighting Complexity
• Keep Clean Code Structure
• Component dependency for a clean architecture
• Refactoring, restructuring, and alignment costs

In addition, I believe that the namespace is the most suitable code construct for creating .NET components. Here are two white papers on making .NET components and keeping them interconnected simply:

• Codebase separation through .NET assemblies and Visual Studio projects (8 pages)
• Defining .NET components with a namespace (7 pages)

Answer 6

Here's how complexity creeps on you IMO. We begin to program the task, and at the beginning nothing is fixed. The algorithms are dynamic, so we believe that all decisions and choices are possible. After a few thousand lines, you begin to weaken this feeling of freedom and notice that programming is the development of some kind of static system that has real limits, and it either works badly for you or doesn't work at all. You hope that your OO design will serve exactly the task you need, but to be honest, the chances are pretty dull. Then you acknowledge that the program is "bloated" and try to fix it by refactoring.

So, in the end, bloating is caused by the limitation of our programming methods. We simply cannot write a large system and still believe that there is freedom of choice (which we feel when we start from scratch).

EDIT:

Also, Bloating is not something that just slows you down, or slightly reduces your motivation. In the worst case, this is what paralyzes your decision in such a way that you cannot write a single line of code. You notice that fixing one thing breaks ten others, and nothing that you do promotes your project in any way. This is why some projects have a limit on the number of functions that they can have. And after this limit is reached, it is a dead end maaan ... :)