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

This article mainly introduces "what are the reasons why writing code is too complex". In daily operation, I believe that many people have doubts about the reasons why writing code is too complex. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what are the reasons for writing code too complex?" Next, please follow the editor to study!

Preface

In software development, we often pursue high maintainability of the software, which means that when there are new requirements, the system is easy to expand; when there is bug, developers are easy to locate. When we say that the maintainability of a system is too poor, it often means that the system is so complex that it is easy to appear bug when adding new functions to the system, and it is difficult to locate after the emergence of bug.

So how is the complexity of software defined?

John Ousterhout defines it as follows:

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

It can be seen that the complexity of software is a very general concept, and anything that makes software difficult to understand and modify belongs to the complexity of software. To this end, John Ousterhout proposes a formula to measure the complexity of a system:

Where pp represents the module in the system, c _ {p} cp indicates the cognitive burden of the module (Cognitive Load, that is, the degree to which a module is difficult to understand), and t _ {p} tp represents the development time spent on the module in daily development.

From the perspective of formula, the complexity of a software is accumulated by the complexity of each module, and module complexity = module cognitive burden * module development time, that is, the complexity of the module is related to the module itself. it also has something to do with the development time spent on the module. It is important to note that if a module is very difficult to understand, but it is rarely involved in subsequent development, then its complexity is also very low.

The reasons for the complexity of software

The reasons for the complexity of software can be subdivided into many kinds, and there are no more than two: dependencies and obscurity. The former will make it difficult to modify and easy to appear bug, for example, when modifying module 1, module 2, module 3,. The latter can make it difficult for the software to understand, and it takes a lot of time to locate a bug or even just read a piece of code.

The complexity of software is often accompanied by the following symptoms:

Shrapnel modification (Change amplification). When only one function needs to be modified, but many modules have to be changed, we call it shrapnel modification. This is usually caused by excessive coupling and interdependence between modules. For example, there is a set of Web pages, each of which is an HTML file, and each HTML has a background attribute. Because the background properties of each HTML are defined separately, if you need to change the background color from orange to blue, you need to change all the HTML files.

Cognitive burden (Cognitive load). When we say that a module is obscure and difficult to understand, it has a heavy cognitive burden. In this case, it often takes a lot of time for the reader to understand the function of the module. For example, provide an unannotated calculate interface with two input parameters of type int and a return value of type int. Judging from the signature of the function, the caller simply does not know what the function is, and he can only call the function by taking the time to read the source code to determine the function.

Int calculate (int val1, int val2)

Uncertainty (Unknown unknowns). Uncertainty is more destructive than the first two symptoms, which usually refers to points that you must pay attention to but have no way of knowing when developing requirements. It is often caused by some obscure dependencies, which will make you feel confused after developing a requirement, vaguely feel that there is something wrong with your code, but do not know what the problem is. We can only pray that it can be exposed in the testing phase rather than in the commercial stage of vulnerabilities.

How to reduce the complexity of software on "tactical programming" Say No!

When many programmers do feature development or bug fixes, they often focus on how to get the program running easily and quickly. This is the typical tactical programming (Tactical programming) approach, which pursues short-term benefits-saving development time. The most common manifestation of tactical programming is that there is no module design before coding, and you can write wherever you want. Tactical programming may be more convenient in the early stage of the system. Once the system becomes huge and the coupling between modules becomes heavy, adding or modifying functions and repairing bug will become difficult. As the system becomes more and more complex, the system has to be reconstructed or even rewritten.

As opposed to tactical programming, strategic programming (Strategic programming) pursues long-term benefits-increasing system maintainability. Just making the program run is not enough, but also need to consider the maintainability of the program, so that later in the add or modify features, repair bug can respond quickly. Because there are many points to consider, it is doomed that strategic programming needs to spend a certain amount of time on module design, but compared with the problems caused by the later stage of tactical programming, this time is completely worth it.

Make the module a little deeper!

A module is composed of interface (interface) and implementation (implementation). If a module is compared to a rectangle, then the interface is the top edge of the rectangle, and the implementation is the area of the rectangle (can also be regarded as the function provided by the module). When the function provided by a module is certain, the characteristic of the deep module (Deep module) is that the edge of the top of the rectangle is relatively short, and the overall shape is tall and thin, that is, the interface is relatively simple; the characteristic of the shallow module (Shallow module) is that the edge of the top of the rectangle is longer, and the overall shape is chunky, that is, the interface is more complex.

The users of the module often only see the interface, and the deeper the module is, the less information the module exposes to the caller, and the lower the coupling between the caller and the module. Therefore, making the module a little deeper helps to reduce the complexity of the system.

So, how can we design a deep module?

Simpler interface

A simple interface is more important than a simple implementation. A simpler interface means that the module is easier to use and the caller is more convenient to use. On the one hand, the simple implementation + complex interface affects the ease of use of the interface, on the other hand, it deepens the coupling between the caller and the module. Therefore, when designing a module, it is best to follow the principle of "leave simplicity to others and complexity to yourself".

Exceptions are also part of the interface, in the coding process, we should put an end to the phenomenon of throwing exceptions up at will without processing, which will only increase the complexity of the system.

A more generic interface

When designing an interface, you often have two choices: (1) to design a dedicated interface and (2) to design a general-purpose interface. The former is more convenient to implement and can fully meet the current needs, but it has low scalability and belongs to tactical programming; the latter needs to take time to abstract the system, but it has high scalability and belongs to strategic programming. A common interface means that the interface applies to more than one scenario, typically in the form of "one interface, multiple implementations".

Some programmers may retort that GM means overdesign when it is impossible to predict future changes. It is true that overgenerality is overdesign, but moderate abstraction of the interface is not, on the contrary, it can make the system more hierarchical and more maintainable.

Hide the details

When designing the module, you should also learn to distinguish which information is important and which is not important to the caller. Hiding details means exposing only important information to the caller and hiding unimportant details. Hiding details makes the module interface simpler and the system easier to maintain.

How to determine whether the details are important to the caller? Here are a few examples:

1. For the Map interface of Java, important details: every element in Map is composed of; unimportant details: how the underlying Map stores these elements, how to achieve thread safety, and so on.

2, for the read function in the file system, important details: each read operation from which file, read how many bytes; unimportant details: how to switch to the kernel state, how to read data from the hard disk and so on.

3. For multithreaded applications, important details: how to create a thread; unimportant details: how multicore CPU schedules the thread.

Carry out hierarchical design!

A well-designed software architecture has a characteristic, that is, the hierarchy is clear, each layer provides a different abstraction, and the dependence between each level is clear. Whether it is the classic three-tier architecture of Web, the four-tier architecture and hexagonal architecture advocated by DDD, or the so-called Clean Architecture, they all have a distinct sense of hierarchy.

When doing hierarchical design, it is important to note that each layer should provide a different abstraction and try to avoid a large number of Pass-Through Mehod in a module. For example, in the four-tier architecture of DDD, the domain layer provides the abstraction of the domain business logic, the application layer provides the abstraction of the system use cases, the interface layer provides the abstraction of the system access interface, and the infrastructure layer provides the abstraction of basic services such as database access.

The so-called Pass-Through Mehod refers to those functions that "call other functions directly in the function body, but do very little". Usually, the signature of the function is very similar to that of the function called by it. The modules in which Pass-Through Mehod is located are usually shallow modules, which adds unnecessary layers and function calls to the system, which will make the system more complex:

Public class TextDocument... {private TextArea textArea; private TextDocumentListener listener;... Public Character getLastTypedCharacter () {return textArea.getLastTypedCharacter ();} public int getCursorOffset () {return textArea.getCursorOffset ();} public void insertString (String textToInsert, int offset) {textArea.insertString (textToInsert, offset);}.} learn to write code comments!

Annotation is an extremely cost-effective method in the software development process, which takes only 20% of the time to gain 80% of the value. It can improve the readability of obscure code; it can hide the complex details of the code, such as interface comments can help developers quickly understand the function and usage of the interface without reading the code; if well written, it can also improve the design of the system.

At this point, the study of "what are the reasons for the complexity of writing code" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.