Business Logic Implementation Method Selection

 

When the business logic is relatively complex, my brain will always come up with one or more solutions that have been used and not used. In the face of such a choice, my brain is chaotic. I always want to abstract a layer before I start, or put it in an SQL statement, I always feel that this method is quick.

 

In reality, when we were doing this page, we already had a similar page. The page we were doing was just a little changed on the basis of the previous page, then, why don't I take the prepared page directly and change some parts that need to be changed, instead of creating a new solution or implementation solution on my own, I need to verify each of these steps.

This may be a different way of thinking.

 

I still need to review the story of a physicist and a physicist, because sometimes this kind of thinking is really needed in code. The story is as follows.

I hope I can give some inspiration to others.

 

A mathematician asked the physicist A question: I want to open a pot of water with a faucet, a water bottle, and a gas stove. What should I do? The physicist said that it would be enough to fill a pot with a kettle in the faucet, put it on the gas stove, and then catch fire. Mathematicians said: Yes, people do this. Now the conditions are the same, and the task is the same. The difference is that the water in the kettle is filled with water. How can you do this. The physicist said: Put the kettle filled with water on the gas stove and just click the fire. Mathematicians say that this is the practice of your physicist. Our mathematicians do not. Physics asked how to do it. The mathematician said: Drop the water in the kettle. ---. In fact, mathematicians use this analogy to tell people that a very important method in mathematics is transformation, that is, converting the current problem into a solved problem.

 

This way of thinking will allow us to constantly turn new problems into old problems that have been solved. Recently, we have been getting CAS single-point logon, and we are eager to accomplish one thing, but we are not doing anything faster, when a problem occurs according to the document, we can return the configuration steps that do not solve the problem, locate the problem, and further narrow down the problem scope based on the tests we have added, finally, find the question, analyze the question, guess the answer, try, and guess again... Until you are excited to see what you want.

Do what you fear!