適切なディレクトリ構造を設計する必要があるのはなぜでしょうか?-Python チュートリアル-php.cn

Web サイトをデザインするときは、作業の開始点としてコンピューターのハードドライブに事前にフォルダーを作成し、そのフォルダーの下にいくつかのサブフォルダーを作成して、さまざまな種類のファイルを保存できる適切なディレクトリ構造を形成する必要があります。サイトの真ん中にあります。
ディレクトリの構造は、Web サイト構築において見落とされやすい問題です。初心者は、ディレクトリ名さえも、後で簡単に見つけられるように計画して作成することはほとんどありません。保存される文書の一種。厳密に言えば、訪問者はディレクトリ構造の品質について明確な感覚を持ちませんが、Web サイト自体の保守と将来のコンテンツの拡張と移植に重要な影響を与えます。

なぜディレクトリ構造を設計する必要があるのでしょうか?

「プロジェクトのディレクトリ構造の設計」は、「コーディングスタイル」と同様に、個人のスタイルの問題です。このスタイルの規範に対しては、常に 2 つの態度があります:

1. 生徒の 1 つのタイプは、この個人的なスタイルの問題は「無関係」であると信じています。その理由は、プログラムが機能する限り、スタイルの問題はまったく問題ではないからです

2. 別のタイプの学生は、標準化によってプログラム構造をより適切に制御でき、プログラムをより読みやすくできると信じています。私は前者のクラスの生徒たちの考えや行動の直接の犠牲者であるため、後者に傾いています。以前、非常に読みにくいプロジェクトを保守していましたが、その実装ロジックは複雑ではありませんでしたが、何を表現したいのかを理解するのに非常に時間がかかりました。それ以来、私は個人的に、プロジェクトの読みやすさと保守性の向上に対して非常に高い要求を持っています。「プロジェクトのディレクトリ構造」は実は「可読性と保守性」のカテゴリーに属し、以下の2点を実現するために明確なディレクトリ構造を設計しています:

1. 可読性の高さ: プロジェクトをコーディングする人に馴染みがない。ディレクトリ構造が一目でわかり、プログラムの起動スクリプトがどこにあるのか、テストディレクトリがどこにあるのか、設定ファイルがどこにあるのかなどがわかります。これにより、プロジェクトを非常に迅速に理解できます。

2. 高い保守性: 組織ルールを定義した後、保守者はどの新しいファイルとコードをどのディレクトリに配置する必要があるかを明確に知ることができます。利点は、時間の経過とともにコード/構成のサイズが増加しても、プロジェクト構造が乱雑にならず、適切に整理された状態を維持できることです。

そのため、明確で階層的なディレクトリ構造を維持する必要があると思います。さらに、適切なプロジェクトディレクトリを整理することは、実際には非常に簡単です。

ディレクトリ構成方法

Pythonプロジェクトのディレクトリ構造をより良く整理する方法については、すでにコンセンサスを得ているディレクトリ構造がいくつかあります。 Stackoverflow のこの質問では、Python のディレクトリ構造に関するみんなの議論を見ることができます。

ここで述べられていることはすでに非常に良いことなので、車輪を再発明してさまざまな方法を列挙するつもりはありません。ここでは私の理解と経験について話します。

プロジェクトの名前が foo であると仮定すると、私が推奨する最も便利で迅速なディレクトリ構造で十分です:

Foo/

|-- bin / code><code>Foo/

　　|-- bin/

　　　　| |-- foo

　　|

　　|-- foo/

　　　　|　|-- tests/

　　　　　　| | |-- __init__.py

　　　　　　|　| |-- test_main.py

　　　　| |

　　　　| |-- __init__.py

　　　　| |-- main.py

　　|

🎜 | |-- foo 🎜🎜🎜🎜 ||-- テスト/ 🎜🎜🎜🎜 | |-- __init__.py 🎜🎜🎜🎜 🎜🎜🎜🎜 🎜🎜🎜🎜 > 🎜🎜

|-- 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

🎜🎜🎜 |--requirements.txt 🎜🎜🎜🎜 |-- README 🎜🎜🎜🎜 簡単な説明:🎜🎜🎜🎜 1. bin/: プロジェクトの実行可能ファイルをいくつか保存します。もちろん という名前を付けることもできます script/ のようなものでも構いませんwork; 🎜🎜🎜🎜 2.foo/: プロジェクトのすべてのソースコードを保存します。 (1) ソースコード内のすべてのモジュールとパッケージはこのディレクトリに配置する必要があります。最上位ディレクトリには置かないでください。 (2) そのサブディレクトリ tests/ には単体テストコードが格納されます。 (3) プログラムのエントリの名前は main.py とすると最適です🎜🎜🎜🎜。 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. 依存パッケージが多い場合は、非常に危険です。これらの依存関係を 1 つずつインストールするのは時間がかかります。

4. 新しい学生がプロジェクトを書き始めると、さまざまな依存関係をインストールする方法を忘れてしまうことがよくあるため、プログラムを実行するのが非常に面倒です。

setup.py はこれらの作業を自動化し、効率を向上させ、エラーの可能性を減らすことができます。「複雑なものは自動化する。自動化できるものは自動化する必要がある。これは非常に良い習慣だ。」 setuptools のドキュメントは比較的多く、初めて使用する場合は、エントリポイントを見つけるのが簡単ではないかもしれません。テクノロジーを学ぶ方法は、他の人がそれをどのように使用しているかを確認することです。Python Web フレームワークと flask の記述方法を参照できます (setup.py)。

もちろん、setup.py の代わりに独自のインストールスクリプト (deploy.sh) を作成するだけでも悪い考えではありません。 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

requirements.txt

このファイルの目的は次のとおりです:

1. 開発者がソフトウェアパッケージの依存関係を維持しやすくするため。 setup.py に依存関係をインストールするときにソフトウェアパッケージが見つからないことを避けるために、開発プロセス中に追加された新しいパッケージをこのリストに追加します。 2. 読者にとって、どの Python パッケージが使用されているかを知るのに便利です。プロジェクト。

このファイルの形式は、各行にパッケージの依存関係の説明が含まれており、通常は flask>=0.10 の形式で、この形式が pip で認識できることが要件となります。 を使用すると、すべての Python パッケージの依存関係を pip install -rrequirements.txt を介して簡単にインストールできます。特定の形式の手順: ここをクリックしてください。

🎜 設定ファイルの使い方について🎜🎜🎜🎜 なお、上記のディレクトリ構成では、conf.py はソースコードディレクトリではなく、

docs/ ディレクトリ: 🎜🎜🎜🎜 多くのプロジェクトは次のように構成ファイルを使用します: 🎜🎜🎜🎜 1. 構成ファイルは、ここでは conf.py などの 1 つ以上の Python ファイルに記述されます 🎜🎜🎜 2. どのモジュールか。プロジェクトでこの構成ファイルを使用する場合は、<code>import conf

を通じてコード内の構成を直接使用できます。 🎜🎜🎜🎜 私はこのアプローチには同意しません: 🎜🎜🎜🎜 1. これにより単体テストが困難になります (モジュールが外部構成に依存するため) 2. 一方、構成ファイルはユーザー制御プログラムとして機能します。インターフェイスでは、ユーザーはファイルのパスを自由に指定できる必要があります。 🎜🎜🎜🎜 3. すべてのモジュールを介して実行されるこのハードコードされたコードにより、ほとんどのモジュールが に依存するため、プログラムコンポーネントの再利用性が低すぎます。 conf.pyThis file;🎜🎜🎜🎜したがって、構成を使用するより良い方法は次のとおりだと思います:🎜🎜🎜🎜 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() は現在のファイルの絶対パスを取得します; os.path.dirname() は現在のファイルのファイル名を取得します。現在のファイルパスの上位パス; sys.path.append() は、ファイルパスの構成と同じレベルでの呼び出しを実現するために、現在のファイルパスをファイルパスに追加します。