Refactoring to, towards, and away from Pattern

Refactoring to, towards, and away from Pattern

(Implementation mode, trend mode, and removal mode through reconstruction)
Reconstruction and Model 1 ~ Chapter 3 Post reading

1. Over-Design and under-design are equally undesirable

The so-called excessive design, Gu mingyu isCodeMore flexibility and complexity than needed. This problem won't happen to people without project responsibility, because they won't carefully design the system to make the project more flexible and functional, instead, it often happens to people who are willing to design projects. The reason for this problem is actually not understanding the true meaning of the model. The mode is used to make the system simpler, not to make the system more complex.

It is a good starting point to design a flexible system that can meet future demand changes, but we must face up to the reality: if the expectations for future needs are incorrect, the expected needs will not become a reality at all, so what about the code written here? After all, we cannot predict what the crowdsourced security testing means.

If we encounter a module that may change our needs in the future, we need to measure the possibility, the cost to be invested, and the benefits we will bring.

Generally, it is no longer easy to reconstruct a system that has a three-year life cycle. So, when we do general software, there is no need to consider the problem of five or ten years later. The farther away from the present, the smaller the measurability of the demand, and the lower the correctness of Self-estimation of the demand, the smaller the probability that the current design can meet the demand.

Besides, we can do some small work first, so that once the demand changes in the future, we only need to reconstruct the module, without having a major impact on the surrounding modules.

As a matter of fact, there is no standard model for the design pattern. Each pattern may be implemented differently in different scenarios. How to Implement the pattern is inseparable from the actual environment. Therefore, meaningful models are produced through refactoring, while refactoring often produces patterns.

This is also the "evolutionary design ".

It is like we want to transform a house, and we want to replace all the walls with sound insulation tiles. So, are we changing a small area and a small area, or are we suddenly breaking down a wall and building a new wall? Oh, be careful when the house goes down ~~ Pai_^

2. Design arrearage

Suppose you ask the Development Manager to give you some time to refactor the existing code to "improve its design", what will he do? The answer may be no: It's hard to deal with endless demands and bugs. There is still time for you to "wait for a while and what functions have not been completed ".

Using the restructured language to communicate with most managers often results in poor performance. However, we can use design arrearage as a metaphor.

Humans cannot write perfect code at once. We will naturally accumulate design debts. So the question is, "When should I repay the design debt "?

In financial terms, if you do not pay off your debt, a late payment will be incurred. If you do not pay the late payment, the late payment will become more and more, which is calculated based on compound interest. As time passes, the amount of debt is as high as a snowball or as we call it. The same is true for design accounts.

Therefore, it is necessary to regularly clear design accounts in arrears.

3. The true value of a model is just an idea, not a block diagram.

People who are too obsessed with design patterns tend to go to another extreme. If a simple helloworldProgramSome people use the factory, command, observer, and templete methods. What do you think? Speaking of this, I think of Microsoft's petshop website. This website uses a large number of design patterns-in fact, this website is a routine of online training in the Microsoft Design Pattern series. Many people interviewed previously mentioned that they have read petshop. However, I don't know what the model is used to solve. Some people even say that the petshop has been a system-is this useful? In database textbooks, the third or N paradigm of the second paradigm is mentioned. Should we follow the N paradigm when designing databases? The design is not a system, but a vase.

In fact, petshop is only used to demonstrate "what can a mode achieve", rather than "When should a mode be used.

During the previous interview, many people asked about the design pattern and described the diagrams in the Design Pattern tutorial. In fact, the design pattern is just an idea. It is just some best practices. The real value lies in telling you how to solve a certain situation, instead of telling you, ". Really good system design often does not match those blocks in the tutorial.

4. Does the pattern make the code more complex?

The author of this book mentioned the same problem we often encounter in reality.

Someone a well transformed a module using the design pattern. In the author's opinion, this transformation makes this module flexible, scalable, clear and simple. Another B who does not know the design pattern, after seeing this refactoring, shouted, "the current code is too complicated! I prefer the original code !". After the author taught B to learn and master this mode, B reluctantly agreed that the code was not as complicated as he thought, but still said that the reconstructed code is not better than the original one.

Yes. The author's familiarity with the design model makes the reconstruction excellent in the author's eyes. This case shows that people's familiarity with the pattern determines how they view the pattern-based reconstruction. Therefore, the development team needs to learn more about these patterns. On the other hand, the implementation of some patterns will indeed make the code too complex. In this case, it is necessary to return or further refactor the code.