Detailed analysis based on code not being reusable

When I was just learning programming, I had an idea that the problem should only be solved once. But gradually get in touch with front-end development, often repeating code, especially when generating pages. What caused the code to not be reused?

Let's see how everyone thinks about this issue, maybe it will be instructive.

Aa: The main problem is that if you don't solve a lot of problems in different environments, it's hard to tell which part is generic and which part is closely related to your current environment. If you don't understand anything, the code you make is certainly not well reused. So the problem can't be solved only once. What we can only pursue is that it costs less every time it is solved, and tends to zero in the long run.

Ab: Because reuse is not without cost, and the cost is often high.

Engineeringly, any feature is not without cost. Reuse provides the flexibility to solve a type of problem, and flexibility as a function has the same cost—just as excessive use of virtual functions has performance penalties, and excessive use of interfaces reduces code readability to a certain extent. Sex. If the cornerstone of building flexibility comes at a price, then we can't expect flexibility to be available for free.

And the solution to all problems is essentially the same: we need to weigh the benefits and disadvantages of each choice and make the best solution for our current projects. For example: We won't discuss extracting business logic into a common framework when the project is most stressful. The reason is simple: time is not enough. We will not discuss the logic of our specific projects too much when discussing how to design a common framework, because the pursuit of universal design goals makes it impossible for us to completely optimize for a specific business.

So in this sense, the biggest reason that hinders code reuse comes from the project itself: in most cases, the reuse code is not the ultimate goal of a project. For any project, the only absolute purpose is to complete the customer's requirements within a specified time. When the need to complete a function and the reuse conflict in a short period of time, the sane project manager will not choose to focus on multiplexing. Of course, programmers who are keen on reuse will certainly defend the reuse on the grounds of long-term benefits; but as the previous rules point out, this is still an engineering choice and therefore still needs compromise. When encountering a problem, always go back to a certain result and then try to explain it. This is not a compromise, but a pre-set position. This is precisely a taboo for engineering.

As for the second question, the answer is: Yes, it is an ideal state to solve only one problem once, but it is not a hesitation to repeat the problem three to five times. The customer's concern is whether we can solve their problems, not whether we can solve them once. —— Don't mistake your own needs for the needs of users. This is still an engineering problem.

Ac: Reusable things (small to function, large to frame) must be extracted from many application scenarios. In other words, there must be scenes first, and the scenes can be abstracted after reaching a certain amount of complexity. The reusable part, which is often referred to as refactoring. It doesn't make sense to pursue reusability at the beginning. It's a waste of time. It's more likely that the imaginary scene doesn't exist at all, or the actual situation is more than imagined. Some veterans have enough experience. Rich, the more problems you have encountered before, you can take care of more reuse scenarios when you start designing. To do development, the stages of growth are essential:

1. No design (novice stage, can be achieved)

2. Over-engineering (to know more things, always want to pursue perfection)

3. Simplify design (cognitive deepening, learn to choose)

4. Optimal design (proficiency, know the concept adaptation scenario)

Two of the 2\3 states may reciprocate multiple times, eventually reaching a balanced position.

Therefore, I feel that the state of the subject is gradually entering the state of over-design. I want to pursue absolute reuse. There is nothing wrong with it. If you have ideas, go to practice and let the results verify your ideas. The degree of many things is not something that others can teach. , it is necessary to personally experience to understand and master.

Ad: Reusable code, the bottom layer is good to write, the upper layer is hard to write.

The underlying code abstracts the machine and the service is the programmer. The programmer is so eager to pursue, read and write data, manipulate data, be fast, be stable, be easy to use, and be satisfied.

The upper layer of code abstracts the requirements, and the service is the user. The needs of users vary, but everyone feels that their needs are unique and special. You said this we can't do it, because it used XX lib and was sprayed immediately.

So many front-end libraries are stalking and smashing, but they are endless, because nothing can be satisfied. Demand is always changing, and the library is also refurbished, but it is always a step or two. After all, what prevented the reuse?

It’s a heart-warming, unpredictable person’s heart.

The human heart is a moving target, with a fixed pattern to try to figure out the human heart. The result is a piece of code that wants to solve ten requirements, but one that does not solve the problem well.

Therefore, the underlying library can be top-down design; and the customer-oriented code, to solve the current problem first, wait for similar problems, and then consider reuse. Don't just encounter a problem, just want to write a general solution, such a tragedy.

Long-term hatred is not as good as water, waiting for waves.

Ae: It is unclear in one sentence because it is lazy.

The same problem should only be solved three times. For the first time, how do you know that this code can be reused? The second time, maybe just a coincidence? For the third time, it seems that this is indeed a recurring problem. Then you should refactor to reuse the code.

Of course it may be because of paranoia. Refactoring is prone to some obvious problems, especially when the language type system you use is not powerful enough and you don't have enough tests. At this time, the usual response of the maintainer is: the refactoring code is first put in the beta version, and the minor problem is fixed, as long as it is not a big problem that is difficult to handle. But if you encounter a paranoid defender, you have to give up: Give up your-get and switch to youtube-dl.

Af: Premature optimization is the root of all evil.

When writing code, the considerations of "reusable" and "extensibility" should be limited to a small scope. Otherwise, the time spent in the current version is much greater than the time saved in the future reuse of the code.

From the perspective of "programming art", this solution is not beautiful at all. Everyone has this idea when they start to develop: to be perfect, to be thoughtful, and to write a bunch of "prepared code" for non-existent needs. However, after summing up several projects, I will find that it is a waste of time and effort. The 90% of the expected demand did not appear, and the part that appeared was quite different from the assumption.

Ag: When writing code, if you consider future reuse, the workload is generally only three times considered for the current situation. (See "The Myth of Man and Moon") "Considering future reuse" can only rely on guessing, which is generally wrong.

Reading code is harder than writing code, so code that is "only for the current situation" is rarely rewritten into more generic code when the problem changes slightly. To add, the original third article was written too short. Article 3, although it mentions a difficult status quo, it also shows that this is the correct way of reuse. That is, every time you write code, it is only considered for the current situation. To be precise, it is only for the situation that has been encountered so far. Such a code goes through a process from private to generic. But this process is also very difficult.