Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to reduce the complexity of system design". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to reduce complexity in system design.

Law of Entropy increase

The concept of entropy originated from physics and is used to measure the degree of disorder in a thermodynamic system. The second law of thermodynamics, also known as the law of entropy increase, shows that in the natural process, an isolated system always tends to be scattered, chaotic and disordered from the initial centralized and orderly state, and when the entropy reaches the maximum, the system will be in a quiet state.

Popularly speaking: the entropy increasing process of the system is the process from primitive to death. "Entropy" is the opposite of "active" and represents negative energy.

Non-life, such as matter always evolves towards entropy, the house will become messy, the phone will become more and more stuck, the headphone line will be messy, the hot water will slowly cool, and the sun will burn and decay. Until the end of the universe-the heat death.

2. Entropy increase of software system

In the software development and maintenance process. The vitality of software always develops from the initial ideal state to complex, chaotic and disordered state, until the software can not be maintained and is forced to be offline or reconstructed. The gradual increase of the factors that damage the quality of software is called the phenomenon of entropy increase of software, that is, the complexity of software discussed in this paper.

Second, the performance of system complexity. 1. Representation

The code is chaotic and it is not easy for newcomers to get started.

The code is highly redundant, low reusability and low development efficiency

It is difficult to expand and modify, lead one to start the whole body.

Business data confusion

Poor performance of the program

The system is difficult to move.

The BUG rate remains high.

Other.

2. Deep causes (1) magnification of change

The first sign of complexity is that seemingly simple changes require code changes in many different places

(2) Cognitive load

The second symptom of complexity is cognitive load, which refers to how much knowledge a developer needs to complete a task. The higher cognitive burden means that developers have to spend more time learning the information they need, and there is a greater risk of errors due to missing something important.

(3) unknown unknown

The third symptom of complexity is that it is not obvious which code must be modified to complete the task, or what information the developer must obtain to perform the task successfully.

3. Summary

Of the three forms of complexity, the unknown is the worst. An unknown unknown means you need to know something, but you have no way to find out what it is, or even whether there is a problem. You won't find it until the error occurs and you make a change. Changing zooming in is annoying, but as long as you know which code needs to be modified, once the change is complete, the system will work. Similarly, a high cognitive load increases the cost of change, but if it is clear what information to read, the change may still be correct. For the unknown, it is not clear what to do, or whether the proposed solution is effective. The only way to be sure is to read every line of code in the system, which is impossible for a system of any size. This may not even be enough, because the change may depend on a subtle design decision that has never been documented.

Third, the reasons for complexity

Complexity is caused by two things: dependence and fuzziness.

1. Dependency relationship

Dependency is a basic component of software and can not be completely eliminated. In fact, we intentionally introduced dependencies into the software design process. Every time you write a new class, a dependency is created around the API of that class. However, one of the goals of software design is to reduce the number of dependencies and keep them as simple and obvious as possible.

2. Fuzziness

Blurring occurs when important information is not obvious.

A simple example is a variable name that is so generic that it doesn't carry much useful information (for example, time). Alternatively, the document for a variable may not specify its units, so the only way to find it is to scan the code for where the variable is used.

Obscurity is often associated with dependencies, in which case the existence of dependencies is not obvious. For example, if you add a new error state to the system, you may need to add an entry to a table that contains string messages for each state, but the existence of the message table may not be obvious to programmers looking at the status declaration.

Inconsistency is also a major cause of opacity: if the same variable name is used for two different purposes, the developer cannot clearly know what the purpose of a particular variable is.

3. Accumulation of dependence and fuzziness

Complexity is not caused by a single catastrophic error; it accumulates into many small pieces. A single dependency or fuzziness itself is unlikely to significantly affect the maintainability of the software system. The reason for the complexity is that with the passage of time, thousands of small dependencies and ambiguities gradually form. In the end, there are so many minor problems that every possible change to the system is affected by several of them.

4. Ways to reduce complexity 1. Set aside some strategic planning time for daily development

Most programmers develop software with the mentality of tactical programming. Such as new features or bug fixes. At first glance, this seems perfectly reasonable: what could be more important than writing effective code? But tactical programming is almost impossible to produce a good system design.

In contrast to strategic planning, the first step to becoming a good software designer is to realize that working code is not enough. Although the code must certainly work, "runaway code" should not be regarded as the primary goal. The main goal of strategic design must be to produce an excellent design, taking into account subsequent maintainability and expansibility.

Strategic programming requires an investment mindset. Although premise investment takes more time than tactical programming, as the system iterates, the advantages of strategic programming begin to emerge.

The recommended way is to run with small steps and set aside 5% of the time for strategic design in daily development.

2. Design of the module

Develop a new module, if there is inevitable complexity. Which of the two design ideas is better: 1, module users should be allowed to deal with complexity, 2, complexity should be handled within the module? If the complexity is related to the functionality provided by the module, the second answer is usually the correct answer.

As a developer, it's easy to do the opposite: solve a simple problem, and then pass the difficult one on to others. If there is a condition that is uncertain how to handle it, the easiest way is to throw an exception and let the caller handle it. Such methods will make your life easier in the short term, but they can add complexity. Most modules have more users than developers, so there will be many people to maintain this module. As a module developer, you should try to make life for module users as easy as possible, even if it means extra work for you. Another better approach is that it is more important for a module to have a simple interface than a simple implementation.

Modules are designed to be deep, and the best modules are those whose interfaces are much simpler than their implementation. Such a module has two advantages. 1. A simple interface can minimize the complexity of imposing modules on the rest of the system. 2. If you modify one module without changing its interface, the modification will not affect other modules. If the interface of a module is much simpler than its implementation, many aspects of the module can be changed without affecting other modules.

3. How to write comments

The reason for writing comments is that statements written in a programming language do not capture all the important information that developers think of when writing code. Comments record this information so that later developers can easily understand and modify the code. The guiding principle of comments is that comments should describe what is not obvious in the code.

One of the most important reasons for comments is abstraction, which includes a lot of information that cannot be seen in the code. The idea of abstraction is to provide an easy way to think about the problem, but the code is so detailed that it is difficult to see the abstraction just by reading the code. Comments can provide a simpler, more advanced view ("after calling this method, network traffic will be limited to maxBandwidth bytes per second"). Even if this information can be inferred by reading the code, we don't want to force module users to do this: reading the code is time-consuming and forces them to think about a lot of information modules that they don't need to use. Developers should be able to understand the abstraction provided by the module without having to read any code other than its externally visible declaration.

4. Attach importance to naming

Names are an abstract form: names provide a simplified way to consider more complex underlying entities. Good names are a form of documentation: they make the code easier to understand. They reduce the need for other documents and make it easier to detect errors. On the contrary, improper choice of names can increase the complexity of the code and cause ambiguity and misunderstanding that can lead to errors.

Naming needs to meet the following requirements:

(1) accuracy

The most common problem with names is that they are too general or ambiguous. As a result, it is difficult for the reader to say what the name refers to. The reader may think that the name refers to something that is inconsistent with reality, as shown in the code error above. Consider the following method declaration:

/ * Returns the total number of indexlets this object is managing. * / int IndexletManager::getCount () {...}

The term "counting" is too general: count what? If someone sees a call to this method, they are unlikely to know what it does unless they read its documentation. More precise names such as getActiveIndexlets or numIndexlets are better: because with these names, readers may be able to guess what the method returns without looking at their documentation.

(2) consistency

In any program, certain variables are used repeatedly. For example, the file system repeatedly manipulates the block number. For each common usage, select a name for that purpose and use the same name everywhere. For example, a file system might always use fileBlock to hold the index of blocks in a file. Consistent naming, like reusing ordinary classes, reduces the cognitive burden: once readers see the name in one context, they can reuse their knowledge and make assumptions as soon as they see the name in different contexts.

Consistency has three requirements:

Always use a common name for a given purpose

Do not use a common name except for a given purpose

Make sure that the purpose is narrow enough so that all variables with names have the same behavior.

(3) the system function diagram can be constructed by naming.

The goal of choosing a name is to create an image in the reader's mind about the nature of the named thing.

A good name conveys a lot of information about what the underlying entity is and, just as importantly, not what. When considering a particular name, ask yourself: "if someone sees the name in isolation and does not see its declaration, document, or any code that uses the name, they will be able to guess what the name refers to. Is there any other name that can make the picture clearer?" Of course, there is a limit to how much information a name can enter. More generally, you can build a view of a module based on several names, a view of a single system based on the name of the module, and a view of the entire business based on the name of a single system.

5. Auxiliary tools (1) Agile development

One of the most important elements of agile development is the concept that development should be progressive and iterative. In agile methods, software systems are developed through a series of iterations, each of which adds and evaluates some new features.

Modern agile development ideas have been integrated into devops, continuous integration and other tools. Ready-made tools can be used in enterprises to achieve rapid verification and iteration of software development, and there are many open source tools. Like Jenkins.

(2) Coca

Coca is a Swiss Army knife for system reconfiguration, system migration and system analysis. It can analyze badsmell in code, count lines, analyze calls and dependencies, do Git analysis, and automate refactoring.

Example 1: class dependency

Example 2: method call diagram

Example 3: statistics on the number of occurrences of variable naming

+-+-+ | WORDS | COUNTS | +-+-+ | context | 590 | resolve | 531 | path | 501 | content | 423 | code | 416 | | resource | | 373 | | property | 372 | | session | 364 | attribute | 349 | properties | 343 | headers | 330 | +-+ |

Example 4: code quality assessment

+-- +-+ | TYPE | COUNT | LEVEL | TOTAL | RATE | +-- -- +-+-- + | Nullable / Return Null | 0 | Method | 1615 | 0.005% | | Utils | 7 | Class | 252 | 2.78% | | Static Method | 0 | Method | 1615 | 0.43% | | Average Method Num. | 1615 | Method/Class | 252 | 6.408730 | | Method Num. Std Dev / Standard deviation | 1615 | Class |-| 7.344917 | | Average Method Length | 13654 | Without Getter/Setter | 1100 | 12.412727 | Method Length Std Dev / Standard deviation | 1615 | Method |-| 20.047092 | +-+-+ -+ so far I believe you have a deeper understanding of "how to reduce the complexity of system design". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.