Read the article Experience

Read the article Experience

read a few articles, feel the big loach this article and our team project particularly close, feel a lot of feelings want to share a bit,

I would like to talk about the big mud ball this article and our team project to improve the process of their own sentiment.

First of all, the big mud ball, the extension of meaning in the text refers to a structure arbitrary, no obvious constraints of the system, such

The system is due to a variety of reasons for growth in the completion stage caused by runaway results, in order to maintain the sudden emergence of various problems, the right to choose

The system is repaired on the whole, and the patches on the last patch lead to the disorder of the whole, and the important information is between the elements of the system.

Being unconditionally shared, often turning almost all of the information used into a global general, the system's political performance structure may never be well-established

and design, even if previously designed, and the initial plan blueprint compared to the changes beyond recognition.

This point I have deep experience, first of all, the initial personal project, got the problem after thinking about it, feeling is a graph theory of the problem,

Then did not think too much began to write, at first, I am sure to record the adjacency information of each node, I first set a structure to record

This information, after writing to think about, anyway, the final must write the shortest path of the search, then first write a think it, and so on this

Some finished, and began to consider the problem of the overall structure, and found that the problem seems to me the first thought of some discrepancies, the path of the search good

As simple as I thought, I'd have to modify the function of the search path, modify it to half find, eh, the struct I defined earlier

There seems to be a little something missing, and then go back to modify the function of the search, the whole process is confusing, feel that they are doing

A lot of work is to fill their own digging before the pit, while regretting that they did not think of the first one side to change the generation of unrecognizable

Code to fill the patch. Just like a piece of mud in a code loophole, a piece of it is called a big mud ball.

This is also reflected in the article:

       Why does A system become A big ball of MUD? Sometimes, big, ugly systems emerge from

throwaway code. throwaway code is Quick-and-dirty code that is intended to is used only once

and then discarded. However, such code often takes on a life of its own, despite casual structure and poor

o R non-existent documentation. It works, why fix it? When a related problem arises, the quickest-to

address it might is to expediently mo Dify This working code, rather than design a proper, general program

from the ground up. Over time, a simple throwaway program begets a big Ball of MUD.

One of the reasons the system becomes a big mud ball is the existence of a lot of disposable code, which refers to fast and dirty code,

Designed to be used only once, and then discarded, this code, although structurally not formal and accurate, and does not exist or is a bad description of the document,

But this code often appears. When it comes to issues related to these codes, you only need to modify the code for those parts, not from the

Head design an appropriate program, over time, one by one patch up, a simple one-time program to make up a big

Mud Ball.

Such behavior is actually an erosion of the entire system structure, but even a well-structured system is prone to such problems.

, because in the process of perfecting the system, inevitably encounter the impact of various problems, these may gradually undermine the overall structure, patching behavior

If it keeps growing, then the whole system is stuck in a situation that can't be repaired, so it's just like falling into a quagmire

Can continue to patch before the behavior, the deeper and deeper, constantly patching. The consequence is that maintenance can become very cumbersome because

Hit every patch generally will not have a clear comment, mostly a one-time code, see there is a problem to fill a, so in the later dimension

It costs a lot to cover the cost.

At this point the team project also gives us a good example, in reading the previous code process, we also found a similar problem,

For example, many of the functions in a class are just an empty function, or the function body is just one line calling another function inside another class, and

is to add many if judgments, set all variables to global static variables, and so on, the consequence is that when we take over the code, the Roots do not

Understand the role of these judgments, and do not know why these functions are placed in this class, this function is in which function is implemented

, where the global variables are being modified, and so on, and so on, the work can only be debugged by a line of code, to see where the debug information

A variable has been modified so that the clumsy way to understand it.

It is difficult to maintain a complete structure when building a project, and it remains intact during subsequent maintenance

The structure is also difficult, the original system and the castle analogy:

A major flood, fire, or war could require, a city is evacuated and rebuilt from the ground up. More

Often, change takes place a building or block at a time when the city as a whole continues to function. Once

Established, a strategy of keeping it working preserves a municipality ' s vitality as IT grows.

The Big Mud Ball project is also very difficult in subsequent maintenance because of its loose structure, leading to any major sudden situation that could make this

The system completely crashes, and keeping the system working becomes a daunting task.

It is mentioned in the text that we are, of course, in favour of a well-structured building, and we are well aware, in common sense, that good structures make it easier to build and

Repair, then how to do a good structure, please big mud ball? The author gives the following suggestions:

Our ultimate agenda are to help drain these swamps. Where possible, architectural decline should be

Prevented, arrested, or reversed. We discuss ways of doing this. In severe cases, architectural abominations

May even need to be demolished.

The advice given in this passage is to consume the mire in the system and, where possible, to circumvent it, but in strict

Heavy case, we need to dismantle the entire structure, but in the following paragraph the author quickly added the instructions:

At the same time, we seek not to cast blame upon those who must wallow in these mires. In part, our

Attitude is to "hate the sin, but love the sinner". But, it goes beyond this. Not every backyard storage shack

Needs marble columns. There is significant forces that can conspire to compel architecture to take a back

Seat to functionality, particularly early in the evolution of a software artifact. Opportunities and insights that

Can allow for architectural progress often is present later rather than earlier in the lifecycle.

The author's words are "hatred of sin, but love sinners", this sentence I understand is, make certain changes, these changes can retain the original

Part of the content, especially in the early stages of the project, while the opportunity to allow the optimization of the architecture generally appeared later in the whole, broken understanding I might

Not particularly clear, but the general meaning I think is that the part of the problem, in the early to have some reservations to remove and modify, and

Project improvement opportunities, usually in the late stages of the project.

At this point, I think our team project does quite well in line with this theory, when we find that the original project has a structural confusion, code

Redundancy, we believe that this code is difficult to provide an efficient environment for subsequent development, so we decided to make a

For some functional code, we choose the most important part of it to retain. So we made this

For the core goal of our beta phase, we re-built the previous code, redesigned the overall structure, and removed the

The classes used, the core functions are improved, the new functions are filled in, the functions are divided into modules, the final complete part is combined,

became a project of structural re-construction and functional filling optimization. I think the part we're doing is actually breaking up the big mud ball,

Wash off the previous piece of mud, take out the clean code, add a new function code on it, and reassemble it, and put the original item

The eye from the big mud ball inside pulls out, facilitates afterwards the development and the maintenance.

Previous seniors in the last sigh:

Watch the next session of the younger brothers learn: Please tear down our code, re-architecture! Start by communicating with all groups, get to know everything, and get started, or you'll be stuck in the mire. Bear in mind that .....

If the previous seniors can see this blog, I would like to tell predecessors, we would like to listen to the teachings, the project from the mire clean off

Leave out, we will not be troubled by the big mud ball, please rest assured.

Read the article Experience