왜 좋은 디렉터리 구조를 디자인해야 할까요?-파이썬 튜토리얼-php.cn

웹 사이트를 디자인할 때 작업의 시작점으로 미리 컴퓨터 하드 드라이브에 폴더를 만든 다음 폴더 아래에 여러 개의 하위 폴더를 만들어 다양한 유형의 파일이 저장될 수 있도록 합리적인 디렉터리 구조를 구성해야 합니다. 사이트에.
디렉토리 구조는 웹 사이트 구축에서 쉽게 간과되는 문제입니다. 초보자는 디렉토리 이름조차 쉽게 찾을 수 없으며 디렉토리가 생성된 이유와 위치를 잊어버리는 경우가 많습니다. 저장되는 문서의 일종입니다. 엄밀히 말하면 방문자는 디렉토리 구조의 품질에 대해 명확한 느낌을 가지지 못하지만 웹사이트 자체의 유지 관리와 향후 콘텐츠의 확장 및 이식에 중요한 영향을 미칠 것입니다.

디렉토리 구조를 디자인해야 하는 이유는 무엇입니까?

"코딩 스타일"과 마찬가지로 "프로젝트 디렉토리 구조 설계"도 개인 스타일의 문제입니다. 이 스타일 규범에는 항상 두 가지 태도가 있었습니다:

　　1. 한 유형의 학생들은 이러한 개인적인 스타일 문제가 "부적절"하다고 믿습니다. 그 이유는 프로그램이 작동하는 한 스타일 문제는 전혀 문제가 되지 않기 때문입니다.

　 2. 또 다른 유형의 학생들은 표준화가 프로그램 구조를 더 잘 제어하고 프로그램을 더 읽기 쉽게 만들 수 있다고 믿습니다. 나는 이전 학생들의 생각과 행동의 직접적인 희생자이기 때문에 후자에 더 관심이 있습니다. 읽기가 매우 어려운 프로젝트를 유지한 적이 있습니다. 구현 논리는 복잡하지 않았지만 표현하려는 내용을 이해하는 데는 매우 오랜 시간이 걸렸습니다. 그 이후로 저는 개인적으로 프로젝트의 가독성과 유지 관리성을 향상시키기 위해 매우 높은 요구 사항을 갖게 되었습니다. "프로젝트 디렉토리 구조"는 실제로 "가독성 및 유지 관리 용이성" 범주에 속합니다. 우리는 다음 두 가지 사항을 달성하기 위해 명확한 수준의 디렉토리 구조를 설계합니다:

　　1. 높은 가독성: 이에 익숙하지 않음 프로젝트를 코딩하는 사람들 디렉토리 구조를 한눈에 이해할 수 있고 프로그램 시작 스크립트가 어디에 있는지, 테스트 디렉토리가 어디에 있는지, 구성 파일이 어디에 있는지 등을 알 수 있습니다. 이를 통해 프로젝트를 매우 빠르게 이해할 수 있습니다.

　　2. 높은 유지 관리성: 조직 규칙을 정의한 후 관리자는 어떤 새 파일과 코드를 어떤 디렉터리에 배치해야 하는지 명확하게 알 수 있습니다. 시간이 지남에 따라 코드/구성의 크기가 증가함에 따라 프로젝트 구조가 복잡해지지 않고 잘 정리된 상태로 유지된다는 이점이 있습니다.

그래서 명확하고 계층적인 디렉토리 구조를 유지하는 것이 필요하다고 생각합니다. 게다가 좋은 프로젝트 디렉토리를 구성하는 것은 실제로 매우 간단한 문제입니다.

　디렉터리 구성 방법

　 더 나은 Python 프로젝트 디렉토리 구조를 구성하는 방법에 대해서는 이미 합의를 얻은 몇 가지 디렉토리 구조가 있습니다. Stackoverflow에 대한 이 질문에서 Python 디렉터리 구조에 대한 모든 사람의 토론을 볼 수 있습니다.

여기서 말한 내용은 이미 매우 훌륭합니다. 나는 바퀴를 재발명하고 다른 방법을 나열하지 않을 것입니다. 여기서는 내 이해와 경험에 대해 이야기하겠습니다.

프로젝트 이름이 foo라고 가정하면 가장 편리하고 빠른 디렉터리 구조이면 충분하다고 권장합니다.

　Foo/

　　|-- bin/

　　　　| |-- foo

　　|

　　|-- foo/

　　　　|　|-- tests/

　　　　　　| | |-- __init__.py

　　　　　　|　| |-- test_main.py

　　　　| |

　　　　| |-- __init__.py

　　　　| |-- main.py

　　| 　|-- bin /

🎜🎜　　|-- foo 🎜🎜🎜🎜　　| 🎜🎜🎜<code>　　|||-- 테스트/ 🎜🎜🎜🎜　　|-- __init__.py 🎜🎜🎜🎜　　||| 🎜🎜🎜🎜　 🎜🎜🎜🎜　| 🎜🎜🎜🎜<code>　🎜🎜

|-- docs/　　|-- docs/

　　　　| |-- conf.py

　　　　| |-- abc.rst

　　　　|

　　|-- setup.py

　　|-- requirements.txt

　　|-- README

　　简要解释一下:

　　1.bin/: 存放项目的一些可执行文件，当然你可以起名script/之类的也行；

　　2.foo/: 存放项目的所有源代码。(1) 源代码中的所有模块、包都应该放在此目录。不要置于顶层目录。(2) 其子目录tests/存放单元测试代码； (3) 程序的入口最好命名为main.py；

　　3.docs/: 存放一些文档；

　　4.setup.py: 安装、部署、打包的脚本；

　　5.requirements.txt: 存放软件依赖的外部Python包列表；

　　6.README: 项目说明文件．

　　除此之外，有一些方案给出了更加多的内容。比如LICENSE.txt,ChangeLog.txt文件等，我没有列在这里，因为这些东西主要是项目开源的时候需要用到。如果你想写一个开源软件，目录该如何组织，可以参考这篇文章；

　　下面，再简单讲一下我对这些目录的理解和个人要求吧．

　　关于README的内容

　　这个我觉得是每个项目都应该有的一个文件，目的是能简要描述该项目的信息，让读者快速了解这个项目．

　　它需要说明以下几个事项:

　　1.软件定位，软件的基本功能；

　　2.运行代码的方法: 安装环境、启动命令等；

　　3.简要的使用说明；

　　4.代码目录结构说明，更详细点可以说明软件的基本原理；

　　5.常见问题说明．

　　我觉得有以上几点是比较好的一个README。在软件开发初期，由于开发过程中以上内容可能不明确或者发生变化，并不是一定要在一开始就将所有信息都补全。但是在项目完结的时候，是需要撰写这样的一个文档的。

　　可以参考Redis源码中Readme的写法，这里面简洁但是清晰的描述了Redis功能和源码结构．

　　关于requirements.txt和setup.py

　　setup.py

　　一般来说，用setup.py |-- conf.py

　 | >

🎜🎜🎜 |-- setup.py 🎜🎜🎜🎜 |-- 요구사항.txt 🎜🎜🎜🎜 　|-- 읽어보기 🎜🎜🎜🎜　 간략한 설명:🎜🎜🎜🎜　 1. bin/: 프로젝트의 일부 실행 파일을 저장합니다. 물론 이름을 script/와 같은 이름으로 지정할 수도 있습니다. work; 🎜🎜🎜🎜　　2.foo/: 프로젝트의 모든 소스 코드를 저장합니다. (1) 소스 코드의 모든 모듈과 패키지가 이 디렉터리에 있어야 합니다. 최상위 디렉토리에 두지 마십시오. (2) 하위 디렉토리 tests/는 단위 테스트 코드를 저장합니다. (3) 프로그램 항목의 이름은 main.py 🎜🎜🎜🎜　3입니다. docs/: 일부 문서 저장 🎜🎜🎜🎜　4.setup.py: 설치, 배포 및 패키징 스크립트 🎜🎜🎜🎜　5.

requirements.txt code>: 소프트웨어가 의존하는 외부 Python 패키지 목록을 저장합니다. 🎜🎜🎜🎜　　6. <code>README

: 프로젝트 설명 파일. 🎜🎜🎜🎜 그 외에도 더 많은 콘텐츠를 제공하는 계획도 있습니다. 예를 들어 LICENSE.txt, ChangeLog.txt 파일 등은 프로젝트가 오픈 소스일 때 주로 필요하기 때문에 여기에 나열하지 않았습니다. 오픈 소스 소프트웨어를 작성하려면 디렉토리 구성 방법에 대한 이 기사를 참조하세요. 🎜🎜🎜🎜 다음으로, 이 디렉토리에 대한 나의 이해와 개인적인 요구 사항에 대해 간략하게 이야기하겠습니다. 🎜🎜🎜🎜　🎜README 내용에 대하여🎜🎜🎜🎜🎜　 프로젝트에 대한 정보를 간략하게 설명하고 독자들이 프로젝트를 빠르게 이해할 수 있도록 하는 것이 목적입니다. 🎜🎜🎜🎜　다음 사항을 설명해야 합니다: 🎜🎜🎜🎜　1. 소프트웨어 위치 지정, 소프트웨어의 기본 기능 🎜🎜🎜🎜　2. 코드 실행 방법: 설치 환경, 시작 명령 등 🎜🎜🎜 🎜　3. 간략한 사용 지침 🎜🎜🎜🎜　4. 소프트웨어의 기본 원리를 더 자세히 설명할 수 있는 코드 디렉토리 구조 설명 🎜🎜🎜🎜　5. 자주 묻는 질문에 대한 설명. 🎜🎜🎜🎜 위의 내용이 더 나은 README라고 생각합니다. 소프트웨어 개발 초기에는 위의 내용이 불명확하거나 개발 과정에서 변경될 수 있으므로 처음부터 모든 정보를 완성할 필요는 없습니다. 하지만 프로젝트가 완료되면 그러한 문서를 작성해야 합니다. 🎜🎜🎜🎜 Redis 기능과 소스코드 구조를 간략하면서도 명확하게 설명한 Redis 소스코드의 Readme 작성방법을 참고하실 수 있습니다. 🎜🎜🎜🎜🎜　requirements.txt 및 setup.py 정보🎜🎜🎜🎜🎜🎜　setup.py🎜🎜🎜🎜🎜일반적으로 setup.py를 사용하여 코드 패키징, 설치, 배포 문제를 관리합니다. . 업계 표준 작성 방법은 Python의 인기 있는 패키징 도구 setuptools를 사용하여 이러한 항목을 관리하는 것입니다. 이 접근 방식은 오픈 소스 프로젝트에서 일반적으로 사용됩니다. 그러나 여기서 핵심 아이디어는 이러한 문제를 해결하기 위해 표준화된 도구를 사용하는 것이 아니라 🎜프로젝트에는 빠르고 쉽게 환경을 설치하고 코드를 배포하며 코드를 배포할 수 있는 설치 및 배포 도구🎜가 있어야 한다는 것입니다. 새로운 기계가 실행됩니다. 🎜🎜🎜🎜 저는 이런 함정을 겪은 적이 있어요. 🎜🎜🎜🎜 처음 Python으로 프로젝트를 작성하기 시작했을 때 환경 설치, 코드 배포, 프로그램 실행 과정이 모두 수동으로 이루어졌는데 다음과 같은 문제가 발생했습니다. 🎜🎜

　1. 최근 환경을 설치할 때 새로운 Python 패키지를 추가하는 것을 잊어버리는 경우가 많습니다. 그 결과 온라인에서 실행하자마자 프로그램이 작동하지 않게 됩니다.

　2. Python의 버전 의존성 문제; 패키지, 때로는 우리 프로그램에서 Python 패키지 버전을 사용하고 있지만 공식 패키지는 이미 최신 버전입니다. 수동 설치를 통해 잘못 설치할 수 있습니다.

　　3. 종속 패키지가 많으면 매우 위험합니다. 이러한 종속성을 하나씩 설치하는 데 시간이 많이 걸립니다.

　　 4. 신입생이 프로젝트 작성을 시작하면 다양한 종속성을 설치하는 방법을 잊어버릴 수 있기 때문에 프로그램을 실행하는 것이 매우 번거롭습니다.

　setup.py는 이러한 작업을 자동화하고 효율성을 높이며 오류 가능성을 줄일 수 있습니다. "복잡한 것은 자동화하고, 자동화할 수 있는 것은 자동화해야 한다. 이것은 아주 좋은 습관이다." setuptools의 문서는 비교적 방대합니다. 처음 사용하는 경우 진입점을 찾는 것이 쉽지 않을 수 있습니다. 기술을 배우는 방법은 다른 사람들이 그것을 어떻게 사용하는지 보는 것입니다. Python의 웹 프레임워크와 플라스크가 어떻게 작성되는지 참고할 수 있습니다: setup.py. setup.py可以将这些事情自动化起来，提高效率、减少出错的概率。"复杂的东西自动化，能自动化的东西一定要自动化。"是一个非常好的习惯。setuptools的文档比较庞大，刚接触的话，可能不太好找到切入点。学习技术的方式就是看他人是怎么用的，可以参考一下Python的一个Web框架，flask是如何写的: setup.py．

　　当然，简单点自己写个安装脚本（deploy.sh）替代setup.py也未尝不可．

　　requirements.txt

　　这个文件存在的目的是:

　　1.方便开发者维护软件的包依赖。将开发过程中新增的包添加进这个列表中，避免在setup.py安装依赖时漏掉软件包；

　　2.方便读者明确项目使用了哪些Python包。

　　这个文件的格式是每一行包含一个包依赖的说明，通常是flask>=0.10这种格式，要求是这个格式能被pip识别，这样就可以简单的通过 pip install -r requirements.txt来把所有Python包依赖都装好了。具体格式说明：点这里。

　　关于配置文件的使用方法

　　注意，在上面的目录结构中，没有将conf.py放在源码目录下，而是放在docs/目录下：

　　很多项目对配置文件的使用做法是:

　　1.配置文件写在一个或多个python文件中，比如此处的conf.py；

　　2.项目中哪个模块用到这个配置文件就直接通过import conf这种形式来在代码中使用配置．

　　这种做法我不太赞同:

　　1.这让单元测试变得困难（因为模块内部依赖了外部配置）；

　　2.另一方面配置文件作为用户控制程序的接口，应当可以由用户自由指定该文件的路径；

　　3.程序组件可复用性太差，因为这种贯穿所有模块的代码硬编码方式，使得大部分模块都依赖conf.py

물론 setup.py 대신 설치 스크립트(deploy.sh)를 직접 작성하는 것도 나쁜 생각은 아닙니다.

　requirements.txt

　 이 파일의 목적은 다음과 같습니다.

　 1. 개발자가 소프트웨어 패키지 종속성을 유지할 수 있도록 합니다. setup.py에 종속성을 설치할 때 소프트웨어 패키지 누락을 방지하려면 개발 프로세스 중에 추가된 새 패키지를 이 목록에 추가하세요.

🎜　　　2. 독자가 어떤 Python 패키지가 사용되는지 알 수 있어 편리합니다. 프로젝트. 🎜🎜🎜🎜　이 파일의 형식은 각 줄에 일반적으로 flask>=0.10 형식의 패키지 종속성 설명이 포함되어 있다는 것입니다. 요구 사항은 이 형식이 pip에서 인식될 수 있다는 것입니다. 를 사용하면 모든 Python 패키지 종속성을 pip install -r 요구 사항.txt를 통해 간단히 설치할 수 있습니다. 특정 형식 지침: 여기를 클릭하세요. 🎜🎜🎜🎜 구성 파일 사용법에 대해🎜🎜🎜🎜 위 디렉터리 구조에서 conf.py는 소스 코드 디렉터리에 위치하지 않고

docs/ 디렉터리: 🎜🎜🎜🎜 많은 프로젝트에서는 다음과 같이 구성 파일을 사용합니다. 🎜🎜🎜🎜 1. 구성 파일은 여기에서 conf.py와 같은 하나 이상의 Python 파일로 작성됩니다. 🎜🎜🎜 🎜　2. 프로젝트에서 이 구성 파일을 사용하면 <code>import conf

를 통해 코드의 구성을 직접 사용할 수 있습니다. 🎜🎜🎜🎜 나는 이 접근법에 동의하지 않습니다: 🎜🎜🎜🎜 1. 이는 단위 테스트를 어렵게 만듭니다(모듈이 외부 구성에 의존하기 때문입니다). 2. 반면에 구성 파일은 사용자 제어 프로그램 역할을 합니다. 인터페이스에서는 사용자가 파일 경로를 자유롭게 지정할 수 있어야 합니다. 🎜🎜🎜🎜　　3. 모든 모듈을 통해 실행되는 하드 코딩된 코드로 인해 대부분의 모듈이 에 의존하게 되므로 프로그램 구성 요소의 재사용성이 너무 낮습니다. conf.py이 파일🎜🎜🎜🎜그래서 구성을 사용하는 더 좋은 방법은 다음과 같습니다.🎜🎜🎜🎜　1. 모듈 구성은 유연하게 구성할 수 있으며 외부 구성 파일의 영향을 받지 않습니다. ; 🎜🎜🎜🎜　 2. 프로그램 구성도 유연하게 제어할 수 있습니다. 🎜🎜🎜🎜 이 아이디어를 뒷받침할 수 있는 것은 nginx 및 mysql을 사용해 본 학생들이 nginx 및 mysql과 같은 프로그램이 사용자 구성을 자유롭게 지정할 수 있다는 것을 알고 있다는 것입니다. 🎜🎜

　그래서 코드에서 직접 import conf来使用配置文件。上面目录结构中的conf.py，是给出的一个配置样例，不是在写死在程序中直接引用的配置文件。可以通过给main.py启动参数指定配置路径的方式来让程序读取配置内容。当然，这里的conf.py你可以换个类似的名字，比如settings.py。或者你也可以使用其他格式的内容来编写配置文件，比如settings.yaml 등을 해서는 안 됩니다.

모듈에서 서로 다른 파일의 호출 문제는 동일한 수준의 디렉터리에서만 실현될 수 있습니다. 서로 다른 수준의 모듈에 있는 경우 프로그램이 동일한 디렉터리 구조에 있도록 환경 변수를 구성해야 합니다. .

환경 변수를 구성하는 단계는 다음과 같습니다.

'''환경 변수는 서로 다른 디렉토리에 가져오기 때문에 먼저 프로그램이 포함될 수 있도록 환경 변수를 구성해야 합니다. 동일한 디렉터리 상태를 구현할 수 있습니다'''
　 Import sys,os
　''os.path.abspath는 파일을 가져오는 절대 경로입니다''
　data = os.path.dirname (os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
　　print(data)
　sys.path.append(data)

　먼저 sys, os, __file__ 모듈을 가져오면 os.path.abspath()는 현재 파일의 절대 경로를 가져옵니다. 현재 파일 경로의 상위 경로; sys.path.append()는 파일 경로에 현재 파일 경로를 추가하여 파일 경로 구성과 동일한 수준의 호출을 실현하는 것입니다.