42、ソフトウェアのディレクトリ構造

なぜ良いのディレクトリ構造を設計？

スタイルの個人的な問題であるように、「デザインプロジェクトのディレクトリ構造」と「コードのコーディングスタイル」、。このスタイルの仕様については、常に2人の態度があります：

個人的なスタイルの質問のこの種その生徒のクラス「無関係」。その理由は、プログラムの仕事がうまく作ることで、問題は、スタイルの問題ではありません。
標準化プログラムの構造をより良く制御は、アプリケーションをより読みやすくすることを他の学生。

私はかつての思考学生や行動の直接の犠牲者だったので、私は、後者の賛成でよりバイアスされています。私はプロジェクトの非常に悪い読書を維持してきた、その実装ロジックが複雑ではありませんが、それは私にそれを表現したいかを理解するために非常に長い時間がかかります。高い上の可読性、保守性の要件を改善するために、私の個人的なプロジェクトから。「プロジェクトのディレクトリ構造は、」実際に我々は明確な階層ディレクトリ構造を設計する「可読性と保守性」のカテゴリに属する、それは以下の2点を達成することです。

高い可読性：このプロジェクトの人々のためのコードに慣れていない、1はその上のテストディレクトリ、設定ファイル、および起動スクリプトを、知られているディレクトリ構造を理解することができます。だから、このプロジェクトについて非常に速いです。
高い保守性：良い組織のルールの定義は、守備は非常に明確に新しいファイルとコードは任意のディレクトリの下に置かれるべきかを知ることができるようになります。利点は、時間の経過とともに、コード/構成サイズが増加すると、プロジェクトの構造はまだ、よく整理することが混同されない、ということです。

だから、私は必要な明確なレベルのディレクトリ構造を維持するために、と思います。よく組織化プロジェクトディレクトリはもちろんのこと、実際には、それは非常に単純なものです。

Directory組織

良いPythonプロジェクトのディレクトリ構造を整理する方法について、既にいくつかのコンセンサスは、ディレクトリ構造があったされています。StackOverflowのでは、この問題について、私たちは、Pythonのディレクトリ構造の説明を参照してくださいすることができます。

いえ、非常に良いがあった、と私はホイールは、さまざまな異なる方法を挙げて再作成するつもりはありませんし、そこに私は私の理解と経験が言いました。

プロジェクトが名前fooと仮定すると、私はこのような最も便利なディレクトリ構造は十分でしょう比較をお勧めします：

Foo/
|-- bin/
|   |-- foo
|
|-- foo/
|   |-- tests/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |
|   |-- __init__.py
|   |-- main.py
|
|-- docs/
|   |-- conf.py
|   |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README

簡単に説明します。

bin/：もちろんという名前の実行可能ファイルに保存されているいくつかの項目は、次のことができますscript/も同様に並びます。
foo/：すべてのプロジェクトのソースコードを保存してください。（1）すべてのソースコード・モジュールは、パッケージは、このディレクトリに置かれるべきです。最上位のディレクトリを入れないでください。（2）そのサブtests/記憶ユニットテストコードを、入口（3）プログラムは、好ましくは、命名されmain.py。
docs/：いくつかの書類を保管してください。
setup.py：インストール、展開、スクリプトパッケージ。
requirements.txt：Pythonパッケージは、外部ソフトウェア依存関係のリストを格納します。
README：プロジェクトのドキュメント。

また、プログラムの数は、より多くのコンテンツを与えられているがあります。たとえばLICENSE.txt、ChangeLog.txt必要が使用するときに、これらのものは主にオープンソースプロジェクトであるため、ファイルなど、私は、ここに記載されていません。あなたは、オープンソースソフトウェアを書きたい場合は、ディレクトリを整理する方法を、あなたはを参照することができ、この記事。

ここでは、単に私のこれらのディレクトリの理解と個人的な要求、それについて話しています。

READMEの内容について

私は、これは、各プロジェクトがファイルを持っている必要があることだと思います、目的は、読者がすぐにプロジェクトを理解することができ、プロジェクトの説明の情報をブリーフィングすることができることです。

これは、以下の事項ことに留意すべきです。

ソフトウェアのローカリゼーション、ソフトウェアの基本的な機能。
設置環境、起動コマンド：コードを実行する方法。
使用の簡単な説明。
コードのディレクトリ構造は、より詳細な説明は、ソフトウェアの基本的な原則を指すことができます。
よくある質問。

私はいくつかの点が良いとされる以上はあると思いますREADME。ソフトウェア開発の初期の頃には、開発プロセスは、すべての情報は、冒頭で補完される必要はないし、明確ではないか、上記変更される可能性があるため。しかし、プロジェクトの終わりに、そのような文書を記述する必要があります。

ソースコードのRedisを参照することができたReadme文言、ソース構造と機能のRedisの明確なしかし簡潔な説明があります。

requirements.txtとsetup.pyについて

setup.py

一般に、使用setup.pyコード、インストールと展開の問題を管理するために梱包。業界標準は、Pythonの人気のパッケージツールの中に書かれているsetuptoolsのこれらの事を管理すること。このモードは、一般的に、オープンソースプロジェクトを使用しています。しかし、ここではこれらの問題を解決するために標準化されたツールを使用していないの核となるアイデアは、ですが、と言ったプロジェクトをインストールするには、デプロイメントツールを持っている必要があり、迅速かつ容易に環境に新しいマシンにインストールすることができ、コードが展開して実行されますアップ。

私は、このピットを踏ん。

私が最初に全体のプロセスを手動で行われているプログラムを実行し、コードを展開し、Pythonの執筆プロジェクト、設置環境に接触したとき、私は次のような問題が発生しました：

設置環境がしばしば忘れたとき最近、新しいPythonパッケージ、ラインへの実行の結果、間違ったプログラムを追加します。
Pythonのパッケージの依存関係の問題のバージョン、時には我々はプログラムで使用Pythonパッケージのバージョンですが、公式には、手動で、それは間違っている可能性がありますインストールすることによってインストールされた最新のパッケージを持っています。
あなたは多くのパッケージに依存している場合は、一つずつ、これらの事は、非常に時間のかかるインストールを依存しています。
新しい学生がプロジェクトを書き始め、それは多くの場合、さまざまな依存関係をインストールする方法を忘れてしまった可能性があるため、プログラムは、稼働して非常に面倒になります。

setup.pyこれらのことは、効率を改善し、エラーの確率を減らすこと、一緒に自動化することができます。「自動化された複雑な事は、物事は自動化されなければならない自動化することができます。」非常に良い習慣です。

setuptoolsの文書がケースに新しい、比較的大きな、あなたは良いエントリポイントを見つけることができません。技術の方法を学ぶことは他の人が、あなたがフラスコが書き込まれたか、PythonのWebフレームワーク、を参照することができます使用しているかを確認することです。 setup.py

もちろん、単純なポイントは、独自のインストールスクリプト（書き込みdeploy.sh）代替setup.pyも悪いアイデアではありません。

requirements.txt

現在のドキュメントには、を目指して：

ソフトウェア保守パッケージの依存関係の発展を促進します。新しいパッケージの開発プロセスは、避けるために、このリストに追加setup.pyインストールパッケージの依存関係が欠落します。
読者の便宜のPythonパッケージを使用して明確なプロジェクト。

ファイル形式は、各行に記載されているパケットに依存し、通常含まflask>=0.10このフォーマットを、このフォーマットが必要とされることができるpip単にによってように、識別された pip install -r requirements.txtパッケージが装着されているすべてのPythonに依存します。特定の形式の説明：こちらをクリックしてください。

プロファイルの使い方

上記のディレクトリ構造に、何の意志がないことに注意してください`conf.py`ソースディレクトリに、しかし上の`docs/`ディレクトリが。

多くのプロジェクトは、設定ファイルのためのプラクティスを使用しています：

など、ここでconf.py.としてPythonで書かれたプロファイルの一個の以上のファイル、
直接この設定ファイルを使用するモジュールプロジェクトimport confコード形式でこの構成を使用します。

私は、このアプローチに同意しません。

これは（これは、内部モジュールの外部構成を依存関係）ユニットテストにそれが困難
制御プログラムのユーザインタフェースとして一方のプロファイルに、ファイルへのパスは、ユーザが自由に指定しなければなりません。
このようなモジュールは、に最も依存していることなど、すべてのコードモジュールをハードコーディングを通じた不正な再利用プログラム部品、conf.pyこのファイル。

だから、私は設定して、より良い方法を使用して考えて、

構成モジュールは、柔軟な構成で、外部のプロファイルの影響を受けません。
設定プログラムはまた、柔軟な制御です。

アイデアは自由に指定されたユーザ設定することができ、これらのプログラムをMySQLや使用やnginxのmysqlの学生が知っている、nginxの、証拠のことができるようにすることです。

したがって、コードを直接すべきではないimport confプロファイルを使用します。ディレクトリ構造の上にconf.py、サンプル構成は、与えられた直接プログラムで参照設定ファイルをハードコーディングされていません。あなたは与えることができmain.py、プログラムが指定した構成パスの設定起動パラメータの方法の内容を読み聞かせします。もちろん、どこconf.pyあなたは、たとえば、類似した名前を変更することができますsettings.py。それとも、このようなコンフィギュレーションファイル、書き込みに他のフォーマットのコンテンツを使用することができますsettings.yamlように。

オリジナルリンク：https://www.cnblogs.com/alex3714/articles/5765046.html