This article analyzes 4 reasons why PHP code maintenance and refactoring become difficult. Share it with everyone for your reference, the details are as follows:
Code maintenance and refactoring are very unpleasant things. The following situations will make code maintenance and refactoring difficult.
1. At the beginning of the project, everyone stipulated some code specifications and developed them under certain specifications. However, people’s ideas are different, which means that the logic implemented by each person with different functions may be like this or that. The difference has caused some people to be unwilling to look at other people's code. To change other people's code, you must first understand what the person was thinking at the time and what his logic was. So many people think that if they have time to look at other people's code, I will do it again. Don’t think this way, you can learn a lot by looking at other people’s code. If everyone thinks this way, I think there will be more and more redundant code, and later reconstruction will become more and more difficult.
2. Programmers generally change jobs frequently. When the project started, it was developed by 5 people (project founders). When the project was launched, some people may have resigned. There is not enough manpower, so the company is recruiting people. As for the project founder, he doesn't really trust the new recruits. He is afraid that modifying the original code will cause problems with the online functions, so he has issued new regulations. It is best not to modify the programs that have been launched. If the requirements change, it is best to Rewrite classes or functions. In this case, the code will become more and more. There may be several classes that are similar, or multiple functions that have similar functions.
3. Redundant database fields and too many redundant tables will also make code maintenance very difficult. Because of function optimization or new requirements, the original table structure cannot meet the new requirements at all. At this time, fields will be added to the table, or another table will be attached. Over time, the database has become very bloated, and the database is large. Needless to say, the code is definitely a matter of course. Programs are all centered around data. Redundant fields and redundant tables must be maintained, otherwise the data will not be unified. Necessary redundancy can reduce database queries, but too much will only be counterproductive. Therefore, you must think more clearly when modifying the database and consider whether the database and code will need to be reconstructed in the future.
4. Personal reasons are the main reason. First of all, we must have the idea of blocking, which can also be said to be oop thinking. This kind of thinking is developed in actual combat, and it takes a certain amount of time. Don’t neglect overall considerations in your rush to implement functionality. If a new need arises, I will first consider how to implement it. After I have an idea, I will not rush to develop this function. I will also consider this functional module. Will it be used in other places? If it is used in other places, how to make it more convenient to use in other places. I will make sure that wherever this function module is called, there will be only one interface. Then I will start developing it. Another point is, don’t believe that the demand won’t change once it’s set, it won’t. People have many ideas, and this must be taken into consideration when developing code. Therefore, when the requirements for a unified interface change, I only need to modify one place, and other places can be changed. If you think about it this way, the early development will take a little longer, but the later maintenance will be much faster.
To summarize, with the above 4 points, it is inevitable to reconstruct the database and code
1. People’s thoughts cannot be the same. Everyone is trying to think in the same direction, but there will always be differences like this.
2. Anxious to complete the function without a deep understanding of other people's code. Studying other people's code is not as fast as re-developing it. This kind of thinking is not good.
3. Database redundancy, I personally think this is bound to happen. To make a project bigger and stronger, it must continue to grow. During the growth process, the database cannot be static.
4. Lack of block thinking. I think a project is a lot of small blocks with independent functions strung together through certain lines. Code reconstruction is the recombination of these small blocks. Of course, each small block is implemented before and after reconstruction. The function will be different, but it is still to achieve certain functions, it is just changed from old to new.
The above points are what I actually encountered during the development of the project. Everyone is welcome to add.
Readers who are interested in more PHP-related content can check out the special topics of this site: "Introduction Tutorial on PHP Basic Syntax", "Introduction Tutorial on PHP Object-Oriented Programming" and "Summary of PHP Excellent Development Framework"
I hope this article will be helpful to everyone in PHP programming.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
