. NET 2.0 new features: refactoring (2)

Kent Beck proposed the "bad code taste" Statement, which is the same as the "Team deformation" we proposed. What is the signal of team deformation? The following code symptom is a strong signal of "Team deformation:

◆Duplicate code exists in the code

There are 118 automakers in China, which are almost the same as the total number of automakers in the United States, Japan, and Europe. However, the national annual output is less than that of a large foreign automakers. Repeated Construction will only result in inefficiency and waste of resources.

The program code cannot be constructed repeatedly. If the same code block exists in the same class, extract it into an independent method of the class. If different classes have the same code, extract it into a new class and never repeat the code.

Too large classes and too long Methods

A class that is too large is often the result of unreasonable class abstraction. unreasonable class abstraction will reduce the code reuse rate. The method is the vassal states in the Kingdom. the huge size of the vassal states is bound to shake the centralization of power. Too long methods are too complicated because of the logic they contain. The probability of errors will go up straight, while readability will go down. the robustness of the class will be easily broken. When you see a method that is too long, you need to find a way to divide it into multiple small methods to facilitate separation and governance.

Make changes to the entire body

When you find that modifying a small function or adding a small function triggers a code earthquake, it may be caused by your design being less abstract than ideal and the function code being too scattered.

Requires too much communication between classes

Class A needs to call too many methods of Class B to access the internal data of Class B. In terms of relationship, these two classes seem a little cute. Maybe these two classes should be together and should not be separated.

Over-coupling information chain

"Computer is such a science, and it is believed that it can solve any problem by adding an intermediate layer", so it is often appended to the program too much. If you see in the code that you need to get a piece of information, you need a class method to call the method of another class, layer-by-layer mounting, just as the pipeline is connected. This is often because there are too many connection layers. check whether there is a detachable middle layer or whether more direct call methods can be provided.

The beginning of the revolution

If you find that two classes or two methods have similar or identical functions although they have different names, you will find that they are often caused by insufficient coordination among development team members. I once wrote a very useful string processing class, but because I did not notify other team members in time, I found that there are actually three string processing classes in the project. The revolutionary resources are precious, and we should not start the revolution.

Imperfect Design

In a comparison alert project just completed by the author, I arranged for Zhu to develop an alert module, that is, sending alert messages to the specified SMS platform, voice platform, and client alert reporter plug-in through socket, zhu has accomplished this task well. Later, the user raised the need for real-time comparison, that is, the third-party system is required to send a request to the comparison alarm system in the form of a message, and the comparison alarm system receives and responds to this request. This requires socket packet communication. Because the original design did not separate the packet communication module, the code developed by Zhu cannot be reused. Later, I promptly adjusted this design and added a new message sending and receiving module to reuse all the external communication of the system. The overall design of the system became more reasonable.

Every system has a more or less imperfect design. It may not be noticed at the beginning and will be highlighted later. At this time, only the courage to change is the best way out.

Missing comments

Although many software engineering books often remind programmers to avoid too many comments, this worry does not seem necessary. Programmers tend to be more interested in function implementation rather than code comments. Because the former gives a sense of accomplishment, code comments are often too small and too simple. The decline of the human memory curve is steep and scary. After a period of time and then comments, it is very easy to "Forget words, more words and more.

I once saw Microsoft's code comments on the Internet. The details are amazing and I have learned a successful experience from Microsoft.

5. How to Use refactoring

Vs. NET 2005 includes a menu "refactoring", which you can use to implement some common refactoring tasks.

Vs. NET 2005 refactoring methods include the following:

◆Reconstruction type

<1> Extraction Method

<2> rename

<3> encapsulate Fields

<4> extraction Interface

<5> promote local variables to parameters

<6> remove Parameters

<7> rearrange Parameters

[1]Extraction Method

<1> you can create a method by extracting the selected code from the code block of an existing member.

<2> the created new method contains the selected code, and the selected code in the existing member is replaced with the call to the new method.

<3> code segments are converted into their own methods, allowing you to quickly and accurately re-organize the code for better reuse and reliability.

◆Advantages

<1> encourage best coding practices by emphasizing discrete reusable methods.

<2> encourage organizations to obtain self-recorded code. When descriptive names are used, high-level methods can be read like reading a series of comments.

<3> Create refinement methods to simplify overloading.

<4> reduce code duplication.