My path of learning Python may be different from that of most people. At that time, my leaders arranged tasks to build an operation and maintenance platform and so on. At that time, I was still a rookie who could only write shell. After a week’s investigation, we found that Python is easy to use and Django framework is more comprehensive, so we looked at Django documents directly. So it is generally: the function of construction idea realization, how to realize Google function in Django, try to write it yourself, continue to Google when encountering problems, and repeat this process until the function you want to realize is completed. This kind of learning method can quickly achieve the goal of work. It is a top-down learning method. It is different from the bottom-up learning method, that is, the basic knowledge is not solid enough. Up to now, we have basically understood it. Let’s sum up the detour.
First of all, I think the structure of a project is the most important. Just like the human skeleton, a clear project structure is conducive to the separation and reuse of modules, and it is a kind of enjoyment for yourself or the people watching your code.
In the early days, my projects were all in the root project, and the code I wrote was all in the root project
views.pyThis file will soon exceed 2K lines, and each time you open it, you need to wait for a while. Even some plug-ins of pychar are on strike (files larger than 1000 lines will be ignored due to operational efficiency problems).
After a period of exploration and review of open source projects, the following structure is more suitable for me.
The following contents are key
- For all the business logic implemented by apps, each module has a separate app to write, and the relevant logic is put into the corresponding app
- Main root project, framework start entry. No business logic is implemented. A fixed name is called main.
- Env project configuration directory, which contains a project configuration instance. It is usually mounted as a file through a container.
urls.pyDo not write to a single file, otherwise once the number of interfaces becomes more and more difficult to maintain, open and place them in different files（ Before a long time can only rely on Ctrl + F search…)
Serializer methodDon’t talk to me
modelsWrite them together and put them in separate files.
- Extract the reusable functions of app and encapsulate them into tool classes. I did
utilsIt is also said on the Internet to build one
common.pyThe truth is the same.
For example, when I want to find the API of [user management] – > [background system], I can quickly locate it
apps -> user -> urls -> http -> systemYou don’t have to go to a big one
views.pyUse search in
Summary: the module configuration and function of the same function are extracted and put into a separate file.
Put in a general picture
This work adoptsCC agreementReprint must indicate the author and the link of this article