Art of code modification-1.1 four reasons for Software Modification

Modify (existing) generation
Code itself has no problem, and we are making a living. However, improper modification may cause trouble. Of course, as long as the method is correct, we can make things much easier. In the industry
CodeThe methodology is not discussed much, and the closest one is probably the reconstruction literature. Therefore, I think the scope of the discussion can be slightly extended, that is, to discuss how to process code in the most challenging situations. Is
Therefore, we must first have a deep understanding of the deep mechanism of modification.

1.1 four reasons for Software Modification

To be concise, let's take a look at the four main causes of software modification:

(1) Add new features;

(2) fixed bugs;

(3) improved design;

(4) optimize resource usage.

1.1.1 add features and fix bugs

Adding features seems to be the most direct change: the software was originally operated in some way, and now the user asks the system to do other things.

Suppose we are building a web-based application.
Sued us (customer) for moving the company logo from the left side of the page to the right. So we talked to her and found that this was not as simple as we thought. She not only wants to move the logo, but also wants
He changes. She hopes to make it work in the next version of the system. So is this a bug fix or a new feature? The answer depends on your perspective on this issue. From the customer's point of view, she is
Obviously, we are asked to correct a problem. Not long ago, She previewed the website and then convened a meeting for her Department staff. Finally, we decided to change the logo location and asked for more features.
From the developer's standpoint, this change can be seen as adding a brand new feature. Developers will say, "If the customer doesn't change his mind, our work is now complete ." However,
In some companies, the position of the mobile logo is only seen as bug fixes. They do not care about the fact that the development team has to start some new work from scratch.

We can think of the above differences as subjective opinions: In your eyes
It is a bug fix. In my opinion, it is as simple as adding new features. However, in reality, for some contractual or quality reasons and purposes, bug fixes and feature additions are mandatory.
Records must be recorded and resolved separately. From a human perspective, we can argue over the question of "are we adding features or fixing bugs. However, at the code level, these are actually being modified
Code and other legacy things. Unfortunately, this dispute over bug fixes or feature additions masks something technically important to us: behavior changes. Fact
There is a huge difference between adding new behaviors and changing old ones.

Behavior is the most important thing for software. The user of the software depends on the behavior of the software. Users like us to add behaviors (provided that new behaviors are exactly what they need). However, if we change or remove the behavior they originally relied on (introduce bugs ), then they will not trust us any more.

Looking back, in the case of the company logo mentioned above, are we adding new behaviors? Yes. After the modification, the system displays the logo on the right side of the page. So have we removed some behaviors? Yes, because there will be no logo on the left side of the page.

Let's look at a more complex case. Assume that the customer wants to add a logo to the right of the page, and there is no logo on the left of the page. In this case, we are adding new behaviors, but have we removed any existing behaviors? Is the place where we are about to place the logo originally occupied by other patterns or text?

Are we changing behavior, adding behavior, or are we both?

In fact, we can extractProgramMore useful differences for members. That is, if we have to modify the code (HTML is also regarded as code), then we are changing the behavior. If we only add code to it and call it, we usually add behavior. Let's look at an example. The following is a Java class method:

Public class cdplayer

{

Public void addtracklisting (Track
Track ){

...

}

...

}

This class has a method of addtracklisting. We can use this method to add the audio track list. Now, let's add a new method to replace the audio track list:

Public class cdplayer

{

Public void addtracklisting (Track
Track ){

...

}

Public void replacetracklisting (string
Name, track ){

...

}

...

}

When we add this method, do we add a new behavior to the application or change the existing behavior? The answer is: neither of them. Adding a method does not change the code behavior unless we call this method in some way.

Now let's make another modification to use the CD player software.
Put a new button on the user interface. This button allows you to replace the audio track list. This action not only adds the action specified by the replacetracklisting method, but also
Slightly changed the behavior of the software. With this new button, the rendering of the user interface (render) is different from the previous one. It takes about one millisecond to display the user interface (used to render the new
Button ). Therefore, it is almost impossible to add a new behavior without changing the existing behavior.

1.1.2 Improved Design

The improved design is another software modification. When we want to change the software
When the structure and organization of the component is easier to maintain, it is usually expected that its behavior will not be changed during this process. If a behavior is lost in this process, we usually refer to it as introducing a bug.
Many programmers usually do not try to improve existing design. One of the main reasons is that this action is relatively easy to cause loss or bad behavior.

The act of improving the design without changing the software behavior is called refactoring.
(Refactoring ). The idea behind refactoring is that if we write a test to ensure that the existing behavior remains unchanged and carefully verify the immutability of its behavior every small step in the refactoring process, we can
It makes software more maintainability through refactoring without changing software behavior. Over the years, people have been working to clean up the existing code in the system, and the emergence of refactoring has been a matter of recent years. Refactoring and general code
Clean up the differences. During refactoring, we are not just doing low-risk work (such as restructuringSource codeOr invasive dangerous work (such as rewriting code blocks), but a series of small changes in the structure, and
With the support of tests, it is easier to modify the code. From the perspective of changes, the key to refactoring is that no functional changes should be made in the reconstruction process. (But the behavior can be slightly changed, because
Your changes to the code structure may lead to performance changes, and the performance may be worse or better .)

1.1.3 Optimization

Optimization is similar to refactoring, but the goal is different. For refactoring and optimization, we
It can be said: "We will keep the function unchanged during the modification process, but we may change some other things ." For refactoring, the "something else" here refers to the structure of the program. We want
Makes the code easier to maintain. For optimization, "some other things" refer to some resources used by the program, usually time or memory.

1.1.4

The similarity between refactoring and optimization seems a bit strange. The similarity between them seems higher than that between adding features and fixing bugs. But is that true? The commonality between refactoring and optimization is to keep the functions of the software unchanged while changing something.

Generally, when a system is modified, its structure, functions, and resource usage may change.

Let's take a look at the four changes that the system usually changes in and remains unchanged (usually in three aspects, but let's see what is a typical situation ):

	Add features	Bug fixes	Heavy Structure	Excellent Informatization
structure	change	change	change	-
function	change	change	-	-
Resource usage	-	-	-	Change

On the surface, refactoring and optimization are indeed quite similar. They all remain functional. But what if we separate the appearance of new features? When we add a new feature, we usually add new features while keeping the existing features unchanged.

	Add feature	bug fixes	heavy structure	optimized
structure	change	change	change	-
new functions	change	-	-	-
function	-	change	-	-
Resource usage	-	-	-	Change

Adding features, refactoring, and optimization all remain unchanged. If you carefully observe the bug fix, we will find that it will change the (existing) function, but this change is usually very small compared to the existing functions that have not been changed.

Feature addition and bug fixes are very similar to refactoring and optimization. In all four cases, we want to change some features and actions, but we want to stay unchanged much more (see Figure 1-1 ).

Figure 1-1 existing behavior persistence

Figure 1-1 shows what happens when the system is modified.
In actual work, what does this picture mean to us? From a positive perspective, this figure seems to tell us what we should focus on. Make sure that the modified few items have been
Modified correctly. From a negative perspective, we not only need to pay attention to this, but also know how to keep other behaviors unchanged. However, it is a pity that retaining the existing behavior does not mean that as long as the code is not touched
. We need to know that these actions have not changed, and this may be tricky. The number of actions to be maintained is usually very large, but this is not a big problem. The problem is that we generally do not
Know which behaviors are at risk of joint changes during the modification process. If we know, we can focus on those behaviors without worrying about others. Therefore, the key to making changes securely lies in
"Understanding ".

Keeping existing behaviors unchanged is one of the most challenging tasks in software development. Even when changing the main features, there are usually many actions that must be retained.

Modify (existing) generation
Code itself has no problem, and we are making a living. However, improper modification may cause trouble. Of course, as long as the method is correct, we can make things much easier. In the industry
The methodology of code is not discussed much, and the closest one is probably the refactoring literature. Therefore, I think the scope of the discussion can be slightly extended, that is, to discuss how to process code in the most challenging situations. Is
Therefore, we must first have a deep understanding of the deep mechanism of modification.