Errors about over-Design and business logic

Some time ago, I designed a blog and made an incorrect decision on the function for encapsulating query statements, that is, over-design. The reason is as follows:

Because the requirements are not fully understood, and I do not know whether other query judgment statements will be added in the future, in the function parameters, return Value and other options are non-finalized interface {}, that is, C's (void *). At that time, I wanted to drop it like this: even if it is modified later, or it does not matter if you have added a query Condition Statement. Because the parameter is not set, the function call has no impact. You can modify it only within the function.

However ,,,,,,,

It turns out that the decision is wrong.

There are four situations:

1. It will not be changed in the future.

2. It should not be changed in the future.

3. I'm not sure whether it will change in the future.

4. It should change in the future.

In the first case, needless to say,CodeYou just need to write it hard. You don't need to consider flexibility (scalability ?).

Second, in the three cases, it is difficult to grasp. There was a misunderstanding in the past, which is also a common mistake for most people: choose to make efforts for future expansion. It can show the technical level, but the correct practice is: in this case, we should assume that we will not change the design in the future. Why? The reason is that there will be too many variability in the future. Even if we have done a complicated job to adapt to the future, most of the designs will fail when the future comes. The second point is: simple implementation will save time, reduce bugs, clear code, and other benefits. But why do many people choose to over-design them: because they can satisfy their technical desires,ProgramCommon Problems of personnel.

In the third case, there is no doubt that you need to consider the design of scalability.