Code refactoring I have experienced

This afternoon, the architect took me to writeCodeThere are still a lot of gains after restructuring. I 'd like to share with you now.

PS: because you are too fond of cooking, Do not joke. Pai_^

 

If there is no unit test or automated test, the primary principle of refactoring is to ensure that the existing functions are not impressed:

 

If you refactor an existing class, write a new class to implement the same functions as the current class;

If you refactor an existing function, add a new function to the original class to ensure the same functionality as the function to be restructured.

 

The above two points are my deepest feelings.

 

In addition, the main line of the problem should be grasped when dealing with complicated problems.

 

For example:

One of our modified functions includes asynchronous access to the network, task queue, message center, and task objects in task queue. If many problems are softened together during implementation, this will make me feel a big head. We should consider the possible problems before we start, for example, how the task handles asynchronous requests, and the objects in the task queue have dependencies, some tasks depend on the previous tasks that must be correctly executed. If you use the message center notification interface, you can handle errors. However, in actual implementation, we should simplify the problem. At the beginning, we just completed a simple framework to complete the basic functions of the task queue, but the task object in the task queue is empty, then, when the task is executed, it only sends a simple task object to the message center. The test task queue can correctly execute the task in order, the message center can notify you of the task execution result during task execution. After all the basic paths are passed, the system then processes other exceptions, such as the dependency between tasks in the task queue and how Asynchronous Network requests notify the task object task execution results through delegation. In short, we just don't want to be perfect at once. Instead, we need to build a framework to allow the basic process to run smoothly, and then add things to it to handle various attachment conditions and exception scenarios.

Consider the interface design from the user's perspective.

Layer-based thinking.

Simple functions can be run, indicating that these simple functions are the essential responsibilities of the class, and other functions are the responsibility of other classes or derived classes.

The simpler the thing, the more stable it is, the easier it is to find the essence of the problem and the nature of the class.

From top to bottom, from view.

Review functional requirements.

The information and code to be exchanged must be readable. For example, if yes is used, No 1 is required.

ProgramSeveral standards to be achieved with the class design: conciseness, consistency, and naturalness.

Ask a user about the role of a class.

Three dimensions of software requirements: functional requirements, non-functional requirements, software architecture or hierarchy.