PHP code maintenance, analysis of four reasons for difficult refactoring, and analysis of four causes _ PHP Tutorial

PHP code maintenance, refactoring, and four causes analysis. There are four reasons for PHP code maintenance and difficulty in refactoring, and four reasons for this analysis. This article describes four reasons for PHP code maintenance and difficulty in refactoring. I would like to share it with you for your reference, for example, PHP code maintenance, four reasons for difficulty in restructuring, and four reasons for failure.

This article describes four reasons for PHP code maintenance and difficulty in refactoring. We will share this with you for your reference. The details are as follows:

Code maintenance and refactoring are a very unpleasant thing. The following situations make code maintenance and refactoring very difficult.

1. at the beginning of the project, we set some code specifications for development under certain standards, but people's thoughts are different, that is to say, the logic implemented by different people with different functions may be as different as this may lead to the reluctance of some people to look at other people's code and change others' code, first, we need to know what this person thought at the time and what his logic is. So there are a lot of people who think that they have time to read other people's code, and I will do it again. There is no such idea. you can also learn a lot from other people's code. If I think like this, I think there will be more and more redundant code, and later refactoring will become more and more difficult.

2. there are usually frequent job hopping for programs. at the beginning of the project, five people (the project founder) developed it. when the project was launched, some people may leave the company. The company is hiring because there are not enough employees. What about the project founder? I am not very confident about the new recruits. I am afraid that modifying the original code will lead to problems with the online functions. so there are new regulations. it is best not to modify the programs that have been launched, if the demand changes, it is best to re-write the class or function. in this case, the code will become more and more. Several classes may be similar, or multiple functions may have similar functions.

3. redundant database fields and too many redundant tables make code maintenance very difficult. Due to function optimization or new requirements, the original table structure cannot meet the new requirements. at this time, fields are added to the table or mounted to another table, the database is very bloated, and the database is large, and the code must be needless to say. The program is centered around the data. redundant fields and redundant tables must be maintained, otherwise the data will not be uniform. Necessary redundancy can reduce the number of database queries. if there are too many queries, they will only return. Therefore, when modifying the database, consider the situation where the database and code should be restructured in the future.

4. personal reasons are the main reasons. we should first have the idea of chunking blocks, which can also be called oop. this idea is developed in practice and takes some time. Do not ignore the overall consideration to implement the function urgently. If there is a new need, I will first consider how to implement this requirement. with my ideas, I will not rush to develop this function. I will also consider this function module, will it be used elsewhere? If it is used elsewhere, how can we make it easier to use it elsewhere. I will make it possible to call this function module. there is only one interface. Then I started development. Another point is, don't believe that the demand will not change. Many people have a lot of ideas. This should also be taken into account when developing code. Therefore, when a unified interface needs to be changed, I only need to modify one place and change it elsewhere. If this is taken into consideration, there will be a little more time during preliminary development, but later maintenance will be much faster.

Conclusion: with the above four points, rebuilding the database will be inevitable.

1. it is impossible for people to think the same way. everyone tries their best to think about it, but there will always be such a difference.
2. you are eager to complete the function without having to gain a deep understanding of other people's code. It is not a good idea to study other people's code as quickly as re-development.
3. database redundancy. I personally think this will inevitably happen. if a project is bigger and stronger, it must be growing constantly. during the growth process, the database cannot be static.
4. without the idea of chunking blocks, I think a project is a multi-functional and independent small pieces that are serialized through a certain line. code refactoring means re-combining these small pieces, the functions implemented before and after reconstruction will be different, but it is still designed to implement certain functions, but only changed from old to new.

The above points are my actual experiences in the development project process. You are welcome to add them.