왜 좋은 디렉터리 구조를 디자인해야 할까요?

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

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

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

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

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

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

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

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

　디렉터리 구성 방법

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

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

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

　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()는 파일 경로에 현재 파일 경로를 추가하여 파일 경로 구성과 동일한 수준의 호출을 실현하는 것입니다.

　　

위의 내용은 앱의 전체 파일 형식입니다. 실제로 앱에는 프로그램의 기본 입구가 있습니다. 환경 변수는 프로그램의 주요 입구입니다. 앞으로는 표준화된 방식으로 코드를 작성하고 다양한 모듈 간 호출을 시도해야 합니다. 간단한 웹 프레임워크 유형을 살펴보겠습니다.

먼저 위는 DJ 프레임워크입니다.

--backend 데이터베이스 검증 모듈 및 논리 모듈을 저장하는 데 사용되는 프런트엔드

　--파일 구성 정보를 저장하는 데 사용되는 구성 모듈

　--프런트엔드는 프런트엔드입니다.

　--user_main.py는 프로그램의 주요 입구이자 프로그램의 실행 모듈입니다.

위 내용은 왜 좋은 디렉터리 구조를 디자인해야 할까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!