Improve the dimension of the project: The directory organization is clear and the directory depth is not much

Framework development with no single entry, the number of code and catalogs is getting bloated, and project maintenance costs are high

There is no negative example to use for reference, the human brain does not agree. The following is a medium-sized project later into the directory structure, the project code is getting messy, developers are reluctant to maintain the code of the system, because to find code to modify, become very painful, code confusion, a lot of directories, find code will look preoccupied.

is a typical discuz-based ucenter system, with the company's business volume increasing, with the passage of time, the system increased the functionality of more and more developers later. Such a system is difficult to maintain.

Specific to the inside code, to find code to modify, especially hard, it is difficult to locate the variable from where it came from. When programmers are developing, they do not need to follow the specifications of the files because they are not using the framework.

The organizational structure of the directory can be arbitrary, resulting in the ability to drop code files anywhere, as long as the include comes in and can be used, code running can.

The following root directory can put a lot of files, as long as the core class include in the still can run through the code.

Because it is not a single-entry frame, you can put a lot of directories, but also put a lot of files

The following directories are enough.

And there are many more subdirectories under the directory

With so many catalogs, there is no regularity in the catalogue, and the memory burden of the brain is heavy. To look for code changes, often see preoccupied. The development of the peers will have a similar feeling.

Think: Today, the code is not just a function of completion. And the organizational structure is clear, actually is not write code aspect. We need to be clear about everything else.

From the writing of the code, you can see a person's organizational nature. For example, the table of contents is hierarchical. A lot of levels, the above is a very deep directory. It does seem like a bit confusing.

Too many catalogs, too many files, do not conform to the people's brains clear reading habits. From the text, from the code is actually can be seen a person's thinking is not clear.

In fact, especially do not like the Phpcms,discuz system code organization, more chaotic. The form of multiple portals, code maintenance up laborious.

Because it is not a single entry, the developer who takes it is free to place the directory. Make a copy folder, copy files, files and directories with the same name are many. It's hard to remember.

The way the code in a single-entry framework organizes the catalog will make the project clearer

See items from the outermost layer. Public is a web resource, visible. The app is the back-end code for the project.

Go to the specific directory below.

Specific to the directory inside the code, it looks very clear, easy to find. Take over the developer, to modify a function, pull the directory can guess where to find.

A directory under the 20 code files, the system can do a lot of functions.

As seen above, the entire project directory is controlled in a limited number of organizations, the above organizational structure, dealing with a daily access to tens of millions of systems.

Even if the above directory file will be more, but there is a feature, very clear and organized, the brain seems to be very easy to know what the contents of this directory is to do.

Static files can also be very clear when stored

CSS, pictures, JS files are stored in separate directories. And there is a WAP version of the static files involved, I simply build a directory to forget it. In fact, you can do this: in the CSS built a WAP directory, in the IMG directory built a WAP directory, in the JS directory built a WAP directory.

It depends on the situation. Because the file itself is few. So I simply separate a single WAP folder anyway. As long as the brain clearly read, organized, good.

A large number of images uploaded by users

Can be placed in the IMG inside, built a folder inside, specifically distinguish what is the picture.

1, such as the Avatar, then the Head_img folder. The folder is then generated by the date of the month.

2, if it is a product picture, create a goods_img folder.

As below, do a demonstration:

It is also very clear that it is named by the folder individually. In the future, it is also convenient to copy the pictures in this folder directly.

Accumulated experience

One, the depth of the directory to be controlled. The hierarchy cannot be too deep. Too deep words. Find the code to modify, find the file. become more laborious. Look at preoccupied.

When the project is initially developed, the catalogue is planned. This requires experience and can anticipate future growth. But it's okay to be able to imitate other areas of work, to keep it clear and rational, so that someone who takes over can see the clear structure of the project.

At first, the members who are involved in the development follow a clear approach. At first it was not clear, and everyone behind would be casual. The power of example is still great.

There is no obvious effect on other people, but it is very necessary to demonstrate it in the body. Even if you are not like that, people around you will not form a positive improvement.

Second, sorting and sorting. Static and dynamic files should be separated. The project's static files (css,js, pictures) are stored separately from the dynamic PHP files.

Three, the common part, to be drawn out. Avoid copying, copying the same code to each directory, and finally make the project more and more difficult to maintain, because it is messy, not clear.

Regular refactoring of code, dedicated time to do, for many companies is not realistic, because often business parties have new features always required to do. So I dedicate time to do it. may not be very realistic.

My idea is that when adding new functionality, I find it necessary to refactor some part of the code to better enhance the current functionality, then I'll refactor. If not, I'll write it down first, and I'll refactor this part of the code when I have the time. Adopt the way of gradual substitution, stones.

Over time, the discovery of other places also need to verify the phone verification code, then think, this piece of verification SMS Verification Code code, generate verification code part of the code, is not able to get a common part, encapsulated into two functions convenient for other places to call.

So I wanted to get a Phoneverfiycode class to store these functions.

We are not gods, we cannot fully anticipate the needs of the future, and the great programmers are no exception, but we can solve them in a way that periodically reconstructs the code. In fact, in the design patterns have seen similar views, when the code has a bad taste, it is necessary to clean up and refactor the code.

The code on the line is running, and the controller is called in several ways using $this->____validatephonecode ($phone _code).

is refactoring the code, or does it not refactor the code? Without refactoring the code, the functionality can still be developed normally. Other places need to use the same authentication, generate verification code, copy the same code past?

But the code is getting bloated. Redundant, repetitive code can make the system more and more bloated. Maintenance is getting worse. Periodically refactoring the code to make the system clearer.

So it has to be done. Just what time to do, how not to affect the development of new features under the premise, how to modify not to affect the online running code on the premise of refactoring the code

My implementation is as follows:

The original ____validatephonecode function is not deleted, nor commented out, to avoid affecting the code that has been called. Instead, draw this part of the code into a class file.

Use in some places first

This change is gradual, and debugging is done on-line with other features. The next time you might develop another feature, you can modify another call place. or spare time to do it.

Finally: Wait until multiple places are modified to call the encapsulated class. You can comment out the original function. In the first picture, some of the functions have been commented out. After all the changes have been made, be sure to comment out or delete the code, do not comment out, will confuse the other developers, thought that the function may still be used. If there is a reference value, it is not deleted, just comments, so that later can be consulted, other people know what to do. Remove the code if you don't need it at all.

Thinking: If some colleagues talk about the same, at the beginning of the time, we are more comfortable development, because the project is less functional, then the directory is few, the code is less, so no attention to what directory planning and code structure. More to the back, more features, if the structure is not clear enough, the code will become more and more bloated.

Find a bad place, not conducive to future project maintenance. To be written down, to be regularly optimized

The catalogue cannot express the meaning clearly.

In fact, the WAP template and the PC version of the template can be placed in a separate two folders to go: WAP and PC

The login and index and password directories do not necessarily have to be such a point at all. is the template of the PC page, unified into the PC folder to go

It looks a lot easier to find a template.

Regularly also technical debt, do not wait until the amount of code in a lot of time to tidy up. The amount of work that was modified at that time was huge. Because change a place, want to change many places at the same time. Do not want to change, do not dare to modify. You can only continue to adapt to the original code structure to write code. So I continued to brake the car.

Improve the dimension of the project: The directory organization is clear and the directory depth is not much