The so-called "Mountain"** is not necessarily "Mountain" at the beginning, as long as you are a programmer, it is basically difficult to avoid writing "Mountain"**It may be very elegant before it becomes "Mountain"**, and there is actually a process to become "Mountain"**. Especially those programmers who have come into contact with the "mountain"**, if they feel indignant, have you ever thought that you may be the creator of the next "mountain"**? When you can't help but want to run, think about your mentality when you first came into contact with "Mountain"**, maybe you will have a certain understanding of "Mountain"**!
I used to work for an ERP software company that had iterated to 2Version 0, according to the R&D director, is the reason why it is necessary to iterate to 2Version 0, that's because of 1Version 0 of the framework is just too ""!
The boss of this company used to be the R&D manager of a well-known ERP software company in China, and later went out with a few friends to start this company alone. The ability of the boss and these few friends is good, for 1The 0 version of the ERP software development is very attentive and the development is completed very quickly.
Because there were relatively few ERP software companies in China at that time, the ERP software they developed was recognized by customers as soon as it was launched. ERP software is basically paid on a monthly or annual basis, but monthly or annual fees alone are certainly not enough to support a company's survival. Therefore, the boss deliberately adopts low monthly and annual fees to increase the competitiveness of his products, and the main way to make profits is to rely on the development of personalized needs! Of course, the decision to develop profits based on personalized needs was not made at the beginning, so it also laid the groundwork for the "mountain" behind.
Actually, at the beginning I was writing 1When the 0 version of the software is used, several R&D personnel are still very thoughtful about the software design, after all, it is from a large factory. However, when the number of users increases, there will still be a lot of needs that are not within the scope of their consideration. What can be done to meet the needs of this group of people? You can only write the bottom ** or add slots! However, this is different from plug-in development, which is premised on reserving interfaces on the basis of the framework, and what they encounter is basically the problem of directly modifying the source code.
Therefore, after a few years of operation in the company, the original ** framework is "full of holes", and it is impossible to see it at all! So, the boss is ready to refactor 1Version 0, Development 20 version of the software idea, and give 2Version 0 is sufficient for post-development flexibility. However, although it has been well thought out, 2Version 0 of the software still met and 1Same problem with version 0 of the software! It can't be avoided!
This is just a small example, so, how did the "Mountain" ** come about? The examples given above are a bit too big, so let's give a few small examples.
For example, if there is an if statement in a certain paragraph, at the beginning of the program, this if statement assumes that it is necessary to determine whether a number is 0, and many people may just write if(num == 0) and it's done. However, if suddenly one day, this number will not only become 0, but also ......Probably most programmers will only add an else if(num == 1) when it becomes 1, or even when it becomes 1.
At this point, this if statement is good enough to refactor it into a switch-case, but most programmers don't dare to move this ** structure at this point, because it is likely to cause problems.
In order to keep this ** in an error-free state, many programmers may know that writing more else-if will only push this ** up the "mountain", but they have to write it like this! In most cases, that's how the "Mountain" actually came about!
For example, when I am in charge of a project, because the customer is a factory, the main operation interface of each workshop software is the same, and the sub-operation interface is different. Therefore, when I designed the software, the main operation interface was basically fixed, and the sub-operation interface could be flexibly configured according to different situations.
After I sent out the software design, the people involved praised me for being "thoughtful" and "perfect", but what was the actual situation?
One day, the supervisor of workshop A said that he wanted to add a function to the main interface, and I told him that it was okay to add it, but I had to ask the supervisors of other workshops if they wanted this thing, and the supervisors of other workshops said that they didn't want it, which made me embarrassed.
Later, after discussing with the R&D personnel on the customer's side, the solution given was to add special judgments to the main interface according to the type of workshop for the display and hiding of function buttons. Although I am very reluctant, but there is a boss, he has to earn this money, there are customers, he has to have this function, I am just an ordinary research and development, I can only write hard **!
However, this matter is not over, I met the requirements of the supervisor of workshop A, but in the next time, the supervisor of each workshop put forward new requirements to me, and finally a large number of hard ** in the main interface.
It's not that this thing can't be refactored, but once refactored, the software customer is already using it, and if there is a problem with the refactoring, no one can afford this responsibility, so let's do it!
What's funny is that when a young programmer in our company took over my **, because he didn't know that this ** was developed by me, he directly told me that this was "Mountain"!
Therefore, "Mountain"**Like many things, it may be thoughtful and elegant at first**, but with the passage of time, it can only be reconstructed because of special judgments, hard **or because of fear of problems**, and can only be reconstructed, and finally slowly deterioration of readability and maintainability, which becomes "Mountain".
Whether it is a large company or a small company, in fact, it is impossible to avoid the "mountain"**We sometimes see some well-known software suddenly have a big update, and even before and after it feels like there are two versions, and the old programmer can see through what is happening at a glance!