Shulou(Shulou.com)11/24 Report--

The correlation between code structures develops over time, because we treat different parts as part of the whole, and in practice, we should try to avoid doing so.

I have a lot of work to do in recent months. I'm having a hard time. I need a rest. My way to relax is to read. I chose Liu Cixin's "three-body". Before I started reading, I never knew about the book, nor did I understand the three-body problem, but after reading it, I was shocked. The three-body is a science fiction novel, the first of the Earth's past trilogy. This book constructs a three-body problem, one of the most complex problems in classical mechanics, and tells a story around it. So let me, without ruining the original story, do the same thing in my own way.

In order to explain the three-body problem and its relationship with software development, let me start with the single problem. Monomer problems are more often referred to as the central-force problem. The mental force problem tries to determine the motion state of a particle affected by the central force, and the position of the central force source is fixed. To put it more bluntly, stars can be regarded as stationary. The motion of the planet can be expressed as a trigonometric function.

Considering a slightly more complicated situation, let's imagine that two objects with mass influence each other's state of motion through gravity, that is, the two-body problem. This can be used to describe the motion of the earth and the moon around each other. Or take a better example, Pluto and Photo, as described in the motion picture below.

The side view of the Pluto-Pluto system shows Pluto orbiting a bit outside it. (Wikipedia) for many forces, including gravity, the generalized two-body problem can be transformed into two monomer problems, so the two-body problem can be solved completely. Therefore, there are corresponding solutions to the two-body problem.

But if we add another mass object and turn the whole system into a three-body problem, then things become unpredictable and often fall into chaos. For most of the initial conditions, the three-body problem does not have a general closed solution like the single-body or two-body problem.

The establishment of n-body problem in software development what is the relationship between the three-body problem and software development? Actually, it doesn't matter. But if we think about these two things, we can find that they have similarities. Strongly coupled and weakly coupled functions that influence each other can coexist peacefully in the same system without forcing one of them to change. Let's compare software development with n-body problems.

At first things were simple and easy to understand. We have a protagonist, that is, a center, and everything else revolves around it. The software does not have many functions and will not conflict with each other.

For example, we plan to develop an inventory management application. All we need to do is insert new items, add or delete quantities, and know the inventory status. So we completed these functions.

After a while we need to add something new. It is best to open an online store to sell products online. So we started to add new features to the inventory management software.

First, add a web page. We get the inventory status that contains the available quantity. Now this page needs to describe the status of available inventory, but this does not mean that these previously available items are no longer in inventory, they are just in a different state. So we need to set a new state in the inventory. We need to know the quantity of goods in the "spot" state and the number of goods in the "salable" state.

But now we need to change the operation of getting the available quantity to the online store to reflect this change. If we can't sell them, it doesn't matter how many goods there are in the warehouse. We just want to show the "spot" quantity in the online store. We need to modify the online store again.

The gravity of some objects in the system attracts other parts to change the state of motion. There is competition between the two parts until they reach a stable state. Once we have optimized the function, things will return to the original predictable state. We are very happy that everything is going according to plan. It is still relatively easy to predict what will happen next and how changes in one part will affect others.

Two objects with "slight" differences in mass move around the common center of mass (Wikipedia) but things can be optimized. We can provide express delivery service to our customers. So we checked the existing system and made changes at every step. The express service changes the inventory, the inventory changes the website design, the website in turn changes the express service, and the express service changes the inventory.

Express service expands commercial trade. A warehouse can no longer meet the demand, we want to develop business in more places, and the system needs to be able to support this way of working. But how will this affect existing systems? Inventory needs to be adjusted to accommodate multiple locations. And because the site reduces the number of items in stock, it also needs to be modified to support multiple locations. But how do you do that? This in turn requires changes in inventory and express services. What a mess.

The approximate trajectories of three identical objects with zero initial velocity at the vertices of unequilateral triangles (Wikipedia) return to the monomer problem. How can we avoid this problem? How can we prevent one function from having a serious impact on others?

There are many planets with enough mass in the solar system that they can affect each other's motion. However, if we try to predict the earth's orbit around the sun, we can ignore all the planets and focus only on the sun and the earth. This will give us a good enough initial approximation of the actual motion. The same is true for the orbits of Jupiter and any other planet.

If we decouple the two functions of the software system, we can deal with them like planets in the solar system. The gravity of one planet is not enough to affect the orbit of another planet. Although it is true that they still influence each other, the changes brought about by these effects will not be very obvious and in some cases do not even exist.

Imagine if we try to calculate the date of Easter in the next ten years. Easter is a Christian holiday, which falls on the first Sunday after the first full moon after the Spring Equinox. When we calculate these dates, do we really care about Jupiter's 79 moons? Of course not, and we don't have to.

We break down the software development solution into many small parts, so that each part revolves around the "sun". The "sun" here can be an information intermediary, a service bus, or just an established contract (interface). We decide how much decoupling our solar system needs. It doesn't matter whether the widgets that move around the sun are modules, domains, or micro-services. It's important that the components be as independent as possible. This will make them easier to understand. It is not even necessary to know that Jupiter has 79 moons to calculate the Easter date in this way.

It is true that the moon has significantly affected the orbit of the earth. If we care about the relationship between the sun and the earth, then we are not talking about the orbit of the earth and the moon around the sun, we are just talking about the orbit of the earth. No matter how complex a function is (for example, Jupiter has 79 moons), we only need to think of them as a whole in the whole system (such as the solar system).

In this way we do not need to deal with (about) 1.2 million celestial bodies in the solar system, nor do we need to deal with about 700 planets, asteroids or moons. We only think about the eight planets. Because generally speaking, when we talk about the solar system, we only care about these eight planets. Although the result of this calculation is not perfect, it is accurate enough for us to cause problems at work.

Simplify the problem when we consider the inventory of a warehouse, what exactly are we thinking about? Maybe it's a big warehouse with a lot of goods stored in it. What is the job of warehousing? To store goods until they are sold. Our software system should only consider these functions.

Online stores should only be responsible for displaying goods and creating purchases. But the purchase in the online store needs to change the inventory status. So how to solve this problem? There are many solutions, but with all due respect.

Buying is already a complex enough function. It takes orders, checks inventory to see if there are items that can be purchased, performs payments, and creates shipments. This may seem like just another feature, but because of its size, it can be easily divided into separate parts.

We create strict contracts for inventory, according to which we can get a list of all goods, a list of all available goods, and check whether these goods can be sold and reduce their quantity. The online store only needs to know the goods available. If we decide to support soft deletions or multiple states at some point, as we did in the above example, the online store does not need to be aware of these changes. As long as you change the data received by the online store, you can complete the above operation without the knowledge of the online store.

For the "buy" function, we need to do the same thing. The contract requires an operation to complete the purchase. The online store initiates this operation, and then its task is completed. the "buy" function takes over. It checks to see if there are available goods, and then, if everything is all right, it completes the purchase and reduces the number of goods in stock accordingly.

Throughout the system, we have clearly separated all the functions that can exist independently (some rather than others). We start with inventory, so of course it has its own system. Next, we added "online store" and "buy" two functions that can be realized independently.

We do have a courier service, but so far the whole process does not need to know its existence. So we should also regard it as an independent system. We should not force it into existing systems and make them match.

Okay. At present, we do not have a system with many complex dependent functions. We have many subsystems, each with a specific complexity, which together constitute a compatible and sustainable solution.

Conclusion it is a complicated thing to build, maintain and expand the software. It may seem easy at first. "I'm just adding this feature." But the more we add, the more complex the equation becomes. If we want to force in too many things, we will eventually find ourselves caught in an unsolvable problem. There is only a fine line between the two.

For the multi-body problem, we can simplify the system as much as possible and divide it into many small parts. There are a lot of people can solve these small parts, such as primary school students can solve single problems. The three-body problem seems to be unsolvable, however, the difference between the two kinds of problems is very small at first glance, so we can use the idea of software design to try to break it into parts and do some simplification and approximation to the problem.

Original text link:

Https://krste-sizgoric.medium.com/the-three-body-problem-in-software-development-74adeda6807c

The translated content only represents the author's point of view, not the position of the Institute of Physics of the Chinese Academy of Sciences.

This article comes from the official account of Wechat: Institute of Physics, Chinese Academy of Sciences (ID:cas-iop), author: Krste "I" gori, translator: Tibetan idiot, revision: Nuor, Editor: zhenni

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.