Hi everyone, and welcome to the Stop Refactoring channel.
In this issue, we will talk about a relatively open topic, which is also a problem often encountered in projects.
In actual projects, due to factors such as development costs and launch cycles, it is inevitable to use open source software.
Open source software means that the source code is made public.
But does using open source software mean easy maintenance ?
Should you choose an open source software with similar functions, and then modify it according to actual needs, the cost will be greatly reduced?
Regarding the answer to the question, you are welcome to write your own practical experience in the comment area.
And our practical conclusion is: not necessarily, especially when the project needs continuous maintenance and upgrading .
We state our views in this order:
1. What are the real difficulties in maintaining open source software?
2. Why open source code is difficult to understand
3. Why is it embarrassing to change the open source code
4. How to choose open source software
What are the real difficulties of open source software maintenance
In fact, most open source software is not easy to maintain , unless there are only a few hundred or thousands of lines of code.
Although the code of open source software is public, the difficulty of maintaining open source software is the understanding of the source code .
Whether it is to modify the bugs of the open source software itself, or to add functions to the open source software, it is based on the understanding of the code.
For the source code that cannot be understood and controlled, it means that there is no source code.
If you can't understand and control the source code, you will inevitably have ten bugs when one bug is modified, and several functions will be paralyzed by adding one function.
For these black-box-like source codes, it is impossible to estimate the cost more accurately. They are often busy for a long time, and working overtime every day will only go further and further away from the plan.
Even if you are lucky enough to understand the structure and context of the source code, you can add functions smoothly, but as the version is iterated, it will inevitably become more and more chaotic, and the difficulty of maintenance will become higher and higher.
Why open source code is hard to understand
So why is open source code hard to understand?
In fact, not only is open source code difficult to understand, but code written by others , even code written by myself a few weeks ago, is often difficult to understand .
This has little to do with whether there are comments, whether the documentation is complete, or what basic framework is chosen, because code writing is very open. There are many if/else, many layers of function/class calls, and even many very individual algorithms in the existing code.
Understanding existing code is undoubtedly understanding a spider web .
It is worth noting that understanding the code is not just about understanding the code. Understanding the code means mastering it, and truly understanding and mastering open source code also means spending a lot of inestimable trial and error costs.
When discussing the front-end and back-end architectures, we all emphasized the importance of regularization , and also proposed the concept of top-level architecture.
Regularization is to fundamentally alleviate the difficulty of understanding existing codes . If you can have very clear and concise coding rules and write codes in the same way, you can greatly reduce the cost of code understanding, which will continuously improve development efficiency, Communication costs, bug response time, and maintenance and upgrade costs are greatly reduced.
This is not guaranteed by any basic framework, which is why some projects using vue and SpringBoot are of high quality, while some projects are greatly delayed and cost overrun.
Why is it embarrassing to change open source code
In our opinion, the source code of open source software is often just psychological comfort .
Even if you control the open source code, when a bug occurs, you can only avoid it, not directly modify it . We often look at the source code of vue, springboot, and FFmpeg, and found some bugs, but we always bypass these bugs instead of directly modifying the source code.
Because it will be very embarrassing to modify these source codes , the upgrade of open source software will become very difficult , and there may be some deeply buried bugs, such as memory leaks, if not upgraded. And don't forget, the development team is fluid, which makes upgrading even more difficult.
How to choose open source software
But having said so much, it is impossible not to choose open source software .
In most cases, it is impossible to develop a very mature component, such as a text editor, player, etc.; it is impossible to develop a basic framework, such as Vue, SpringBoot, etc.; it is impossible to develop a software that is not familiar with the field, such as FFmpeg for codec processing; in most cases, some very mature business systems, such as mall systems, cms, etc., will be directly selected.
Before choosing open source software, we need to have the mentality of using it, not the mentality that it can't be changed.
Therefore, popularity and completeness of documentation are the primary indicators .
It needs to be specially explained: popularity does not mean that it is popular when you hear that a certain big manufacturer is using it, or whoever you hear is also using it, but that you can find answers to many usage questions on the Internet.
Sometimes, the functional fit of open source software is not 100%, especially business systems, such as mall systems. For these software, it's better to get their technical support than to estimate the workload blindly.
Just relying on a few architecture diagrams and a few documents, even if you are familiar with the basic framework such as SpringCloud, the workload cannot be estimated . Often you think it takes one day, but it takes more than half a month in the end.
If there is no technical support, it is necessary to carefully evaluate whether the software architecture is easy to maintain, and at this time, the quality of the software architecture is more important than the degree of function satisfaction.
Of course, it is difficult to tell whether the software architecture is good or bad by "looking". Our habit is to try to modify a typical function first. If this function is particularly troublesome to modify, then don't use it.
Summarize
Open source software is often only maintainable. After all, software is written by people and must be labored by people. There will be a big gap in the quality of the output.
Therefore, when we discuss large-scale website architecture, we always refer to rules, regularization, and top-level architecture, rather than discussing the use of technologies, frameworks, and tools.
Because there is no framework or tool that can guarantee the final quality, software quality is determined by the project process.
The project process is not about the Eight Immortals crossing the sea to show their magical powers, but a team that completes tasks according to clear and concise rules, and the project cycle, project cost, and software quality will naturally improve.