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

This article focuses on "how to understand the second Law of Thermodynamics in Software Systems". 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 understand the second law of thermodynamics in software systems.

1. Broken window theory

Imagine that two teams are working on the same project at the same time. Team A, in the project development process, despite a detailed and comprehensive plan, has the most capable engineers, the final result of the project is not satisfactory, with the passage of time, the code becomes very poor.

While another team B, in the development of the project, although also encountered great difficulties and a series of problems, but can maintain a good code state, successfully completed the project task.

What is the reason for this difference?

In cities, we can always find the opposite of things, such as neat and beautiful buildings, while others are dilapidated houses. What caused such a strong sense of impact?

The reason for these two phenomena is the same, that is, the "broken window theory".

Take a building with a few broken windows as an example, if those windows are not repaired, saboteurs may break more windows. In the end, saboteurs may even break into the building, and if they find it uninhabited, they may even settle down or set fire to it. In a relatively short period of time, the building will be destroyed at an alarming rate, and the owners are unwilling to repair the dilapidated house.

When it comes to the field of software development, this "broken window" may be left by engineers inadvertently, may be caused by carelessness, may be left over by poor design, or may be caused by wrong requirements.

We have refactored the code architecture within our team before, and many businesses have been redesigned, but with the passage of time, broken windows begin to appear, and then quickly become difficult to maintain and bloated. There are other reasons, of course, but the most important reason is to ignore the problematic code.

Don't keep the "broken window". Fix one when you see one. If you don't have enough time to fix it, it's best to add a comment or a bug tag to indicate that this part of the code needs to be fixed to prevent more and more broken windows.

two。 Boiled frogs in warm water

Scientists at Cornell University in the United States have done an experiment of boiling frogs: when a frog is put into boiling water, the frog will jump out of the pot and escape as soon as it touches the boiling hot water.

Try to put the frog into a pot filled with cold water. The frog swims freely in the water as usual, and then slowly heats up the water in the pot until the water is unbearably hot. The frog tries to jump out of the water to escape the dangerous environment, but his limbs are weak. Finally died in hot water.

The experiment shows that due to the adaptability and habit to the gradual change, the vigilance and resistance have been lost.

It is also applicable in the program system, programmers work for a long time, will enter a state of comfort, called the "comfort zone". In the comfort zone, programmers tend to be paralyzed and numb to changes in the outside world.

The software code is changing slowly and quietly over time, and this change will eventually get out of control.

Most software systems start with a tiny little bug and die slowly.

Software projects are bothered by all kinds of small bug and can only be postponed day by day.

Every requirement in a software project is like a hole in a dress, patched one by one, and finally it is impossible to see the appearance of the software architecture itself, just as it is impossible to see the color of the clothing itself.

The most terrible thing is that every programmer admits that this is a normal and acceptable state and enjoys bugfix every day, just like frogs in warm water. There is no feeling that the whole software system is becoming rubbish and beyond recognition. Finally, they are greeted by bloated, hard-to-maintain code.

Boiled frog and broken window effect are different, their difference lies in whether they have subjective will or not.

On the problem of broken windows, the software system becomes disorganized, because programmers do not stop this from happening in time when they see the "broken window", so they think that no one will notice the problem.

As for the boiled frog, the key point is "slow". If you put it in hot water or heat up quickly, the frog will try its best to escape. So programmers really just don't know it, and the software system is slowly dying.

3. Self-centered

The picture below is a very famous painting called Salisbury Cathedral seen from Bishop's Garden, by Constable, a famous British oil painter.

One day, Constable went to the home of Mr. Fisher, Bishop of his financier Cathedral.

Bishop Fisher said to the painter, "Dear painter, help me draw a picture. Draw me in the picture with my beautiful wife and my cathedral. I will leave the painting in the church and become the treasure of the town hall." So Mr. Constable gladly took over the project.

The painter began his hard work and finally finished the painting after a period of time.

The painter may be in a bad mood when painting this picture, so there is a dark cloud in the sky above the church spire. When Bishop Fisher saw the picture, he was very dissatisfied. Although the painter painted the bishop, the bishop's wife and the church, the couple only showed their back in the lower left-hand corner and put up with it. "what's going on with those cows down there? why do they take more shots than we do?" Asked the bishop. The painter said, "you don't understand? I'm flattering you. I mean, you and your wife are so good!" Mr Fisher had nothing more to say, and then found a new point: "Why are all the clouds in the sky dark?"

He invited the painter to visit his house again and observe again in order to modify the painting. The painter was very unhappy, so he exhibited the paintings alone. After the exhibition, he received a lot of praise, so he wrote back to Bishop Fisher: "you see, everyone says it is very beautiful and there is no need to change it." Bishop Fisher was also angry when he received the letter and replied with a sentence: "correct me!"

This is the story of demand. Let's look at the picture above to see where the bishop and his wife have been drawn. Can you find it?

Master Dayu wanted a picture of the couple and the church. After the needs were expressed, there was no more specific explanation of the needs.

If you think more deeply, why is there always a situation that is not clearly described?

Readers must have encountered similar problems, and the deeper reason is "self-centeredness".

The process of human growth is a "decentralized" process. After about 6 years of age, children's ability to decentralize themselves has been developed. At the beginning, we can recognize the feelings and opinions of others, but everyone will show a different state of de-egocentralization in the process of socialization.

It can be said that every adult is self-centered, and it is impossible for us to be completely objective in our feelings, thoughts and understanding. So we need to use structured thinking (see my other article, "programmers' essential abilities-structured thinking") and systematic thinking (refer to my article "programmers' essential abilities-Deep thinking").

The same conclusion applies in the process of software development. I think at least the following points are shown:

In the design and development, if the programmer does not fully comply with the requirements of the product manager, it is inevitable to modify the design of the code repeatedly, resulting in an increase in entropy.

When programmers are developing, they change and disrupt the architecture framework at will, resulting in increased code coupling and difficulty in maintenance.

4. Business

The common objective reason for code entropy increase is mainly due to high business pressure, resulting in no time or willingness to pay attention to code quality. After giving in to business pressure and producing bad code, development efficiency will decline, resulting in greater business pressure, forming a typical vicious circle.

At this point, I believe you have a deeper understanding of "how to understand the second law of thermodynamics in software systems". 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.