1.我看到这篇文章，写的不错，在此复制了一份，防止之后找不到！
感谢做者的翻译－－－＞原文的连接：http://www.loonapp.com/blog/11/
若是原文存在，请打开原文件阅读
偶然看到一份关于Django工程目录的文章，英文版版的，以为写得不错。在此翻译下供读者参考 Django 工程目录结构 你已经配置好你的Heroku帐户（译者注：Heroku是一个老牌的免费云空间），而且建立了第一个Heroku应用，让咱们来讨论一个很是重要的话题（虽然常常被忽略）：Django工程结构管理。 概述 多数Django工程很是混乱。不幸的是默认的Django工程布局并无对此有任何帮助，它过于简单对工程的管理致使在处理大的工程时带来不少维护性问题。 本文将帮助让你的工程有个合理的布局。致力于： 遵循最佳实践 让你的工程尽量地直观--你（做为开发者）能够当即认出代码每一个部分的做用 让你工程仍然保持规范随着你的工程中的应用愈来愈多。 让你工程在不一样环境下部署更加方便 让其余程序员喜欢你的代码 具体步骤 这部分我将和你一块儿开始一个新的项目。过程当中，你须要将你的项目目录结构调整为下面描述的布局。 本文描述了高维护性结构分明的Django项目布局的最佳实践。 基础- 缺省的Django项目 在深刻以前，让咱们建立一个新的Django项目（工程） $django-admin.py startproject djanolicious $cd djangolicious $tree . . ├── djangolicious │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── manage.py 1个目录，5个文件 在根目录djangolicious下，能够获得： 项目目录：djangolicious manage.py脚本：用于管理Django站点 在项目目录djangolicious里包含： settings.py: 包含项目的全部配置参数 urls.py: URL根配置 wsgi.py: 内置runserver命令的WSGI应用配置 __init__.py: 用来告诉python，当前目录是python模块 如今让咱们来看下一个工程的基本架构，让咱们来作些改进。 管理项目需求说明 首先咱们在项目中新建一个文件：requirements.txt。每一个Django项目都应该有一个顶级的requirements.txt文件来列出项目中全部使用到的python包。 Note：若是你对于requirements文件不太熟悉，你能够阅读Heroku指引 来经过pip管理python的需求关系。 requirement.txt中相似以下内容： Django==1.6 psycopy2==2.4.5 South==0.7.3 gunicorn==0.14.1 nrerelic==1.2.0.246 django-cerlery==2.4.2 建立requirements文件是为了让其余开发者 拷贝你的项目代码后能够快速地根据此文件中内容安装好必须的python依赖包。这样他们能够方便地运行你的代码，而没必要煞费苦心地猜想项目依赖包的版本。 如今你知道为何咱们须要这么作了，照作吧！ 第一步--模块化 在项目目录中建立一个顶级的requirement.txt是必须遵循的要求，并且这样能够保证能够方便地管理项目依赖关系 这意味着：颇有可能，项目的开发环境依赖关系不一样于你的生产环境，全部你须要将你的开发和生产环境的依赖都放到requirement.txt中，可是这会使得管理起来比较困难。 因此，最好是区分好不一样环境的依赖和需求 咱们的作法以下（在项目djangolicious根目录下): $ls djangolicious manage.py $touch requirements.txt $mkdir requirements $touch requirements/{common.txt,dev.txt,prod.txt,test.txt} $tree. . |-- djangolicious | |-- __init__.py | |-- settings.py | |-- urls.py | |-- wsgi.py |-- manage.py |-- requirements | |-- common.txt | |-- dev.txt | |-- prod.txt | |-- test.txt |-- requirements.txt 2个目录，10个文件 能够看出，我新建了一个顶级目录：requirements,包含一系列的需求说明文件，分别针对每一个环境。 若是你的应用只须要在开发环境下运行，那么只须要在一个dev.txt文件。若是你的应用须要开发、生产、测试、tom和rudy环境下运行--那么就分别为他们建立一个.txt文件 Note：common.txt内含各类环境下共享的需求说明。例如Django。全部环境下都须要Django，不论是开发环境仍是生产环境，你都须要使用它。 将各种需求文件分开的目的是，看成为程序员的我只须要在本地环境下运行项目，那么我只须要安装requirement/dev.txt中提到的软件包，而不须要安装其余的包（生产环境，staging，测试环境等等） 可是为何我这么关心哪些包是我必须安装的？为何我不将他们所有安装？ 安装依赖包须要耗费很长时间，对于大型项目来讲可能会耗费大块的时间（30分钟以上）。 不少需求依赖于外部软件或者库文件按装到你的本地机器来完成编译。这么避免安装库文件能够节省时间还能够免去大量没必要要的麻烦，好比要安装哪一个版本的libxml2和libpq-dev。 下降了初学者学习的门槛。若是的你项目组来了一个新的开发，尝试提交代码，对他来讲安装不多的软件包就能够运行系统要比安装全部软件包要简单的多。 第二步--定义需求文件 如今咱们明白了为何要模块化需求说明文件，下面了解下实践中需求说明文件的具体内容。 下面我列出了4个从我实际项目中拿来的需求说明文件，我将详细的给予说明。 首先，requirements/common.txt文件列出了全部基本的需求包，其中的么个软件包在任何环境都是必须的（不论是开发环境，测试环境仍是生产环境等的）： # requirements/common.txt Django==1.4 django-cache-machine==0.6 django-celery==2.5.5 django-dajaxice==0.2 django-guardian==1.0.4 django-kombu==0.9.4 django-pagination==1.0.7 django-sorting==0.1 django-tastypie==0.9.11 Fabric==1.4.1 lxml==2.3.4 pyst2==0.4 South==0.7.4 Sphinx==1.1.3 下面的requirements/dev.txt文件包含了个人开发环境所须要包，其中的包只有是在开发环境下才会用到。 # requirements/dev.txt -r common.txt django-debug-toolbar==0.9.4 在个人开发环境，我一般使用轻量级的SQLite3数据库（因此我不须要安装任何驱动程序），并且很是好用的包django-debug-toolbar能够容许我检查数据库查询和性能问题，等等。 可能你会疑惑文件第一行的做用，'-r common.txt'告诉pip引入全部通用的依赖包附加到后面列举内容。 这将容许我在命令行中直接运行pip intal -r requirements/dev.txt来安装开发环境须要的全部依赖包： $ pip install -r requirements/dev.txt Downloading/unpacking Django==1.4 (from -r requirements/common.txt (line 1)) Downloading Django-1.4.tar.gz (7.6Mb): 7.6Mb downloaded Running setup.py egg_info for package Django Downloading/unpacking django-cache-machine==0.6 (from -r requirements/common.txt (line 2)) Downloading django-cache-machine-0.6.tar.gz Running setup.py egg_info for package django-cache-machine ... snipped for brevity ... 从上面的运行结果能够看出，很是好用！当咱们使用pip安装requirements/dev.txt中包，它不只成功安装了开发环境中须要的依赖包，同时也将common.txt中列举的包都安装好了！很是漂亮！ 下面是一个简单的requirements/pord.txt需求说明文件。其中包含了全部生产环境的依赖包和基本的依赖包： # requirements/prod.txt -r common.txt boto==2.1.1 cssmin==0.1.4 django-compressor==1.1.2 django-htmlmin==0.5.1 django-pylibmc-sasl==0.2.4 django-storages==1.1.3 gunicorn==0.14.1 newrelic==1.2.0.246 psycopg2==2.4.5 pylibmc==1.2.2 raven==1.3.5 slimit==0.6 最后，这是一个比较旧的requirements/test.txt文件，列出测试环境下的依赖包。这些包用于项目的单元测试环节。 # requirements/test.txt -r common.txt django-coverage==1.2.2 django-nose==0.1.3 mock==0.8.0 nosexcover==1.0.7 当我须要在本地开发环境下运行个人代码，我就安装requirements/dev.txt中的依赖包 当我在生产环境下运行个人代码，就安装requirements/prod.txt中的依赖包 当我要针对个人代码作一些测试的时候，我就安装requirements/test.txt中的依赖包 重点在于将你的项目依赖文件按照如下原则来拆分： 简单的 高效的 直观的 第三步--Heroku最佳实践 如今，咱们模块化了咱们的需求说明文件。我敢说你必定疑惑：为何在项目根目录下还有个requirement.txt的文件？ 缘由以下： 标准化要求存在requirements.txt文件 Heroku在你部署项目的时候会自动读取你根目录下下的requirements.txt文件，而且将这些需求包安装起来。 Heroku会安装你在requirements.txt中定义的全部包，你能够有多种选择： 让Heroku安装全部的依赖包：comon.txt,dev.txt,prod.txt等 让Heroku只安装他须要的包 咱们使用Heroku来部署咱们的站点，全部最好是让Heroku只安装必须的包。 由于Heroku须要作的事情少了，这会让咱们部署后的项目更加快速。 打开根目录下的requirements.txt文件而后输入如下内容： #Install all of our production dependencies only. -r requirements/prod.txt 这样Heroku就会安装咱们的要求来安装须要的包。 分离应用和库文件 管理Django工程接下来的工做就是把你的应用从库中分离出来。 总所周知，每一个Django工程包括一系列的应用。有些应用中包含模型和视图等等。还有些是辅助性的应用。 一般，这些辅助应用用于自定义templatetag，管理命令以及一些其余代码。请不要将这些放到别的应用里面。 幸运的没，有一种简单的方法来构建的Django项目： 开发人员能够很容易地找到你的django应用 开发人员能够很容易的找到你的django库文件 不要在你工程目录下包含大量的自定义应用，不要让你的目录结果混乱，而很难找到你想要的东西 我都会在每一个Django工程的主目录下建立两个目录：apps和libs用来各自存放应用和库文件。 再看咱们的例子工程：djangolicious，个人作法以下： $ mkdir djangolicious/apps $ mkdir djangolicious/libs $ touch djangolicious/apps/__init__.py $ touch djangolicious/libs/__init__.py $ tree . . ├── djangolicious │ ├── apps │ │ └── __init__.py │ ├── __init__.py │ ├── libs │ │ └── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── requirements │ ├── common.txt │ ├── dev.txt │ ├── prod.txt │ └── test.txt └── requirements.txt 4个目录，12个文件 如上所示，个人djangolicious工程中包含了新的apps目录和libs目录。剩下的就是将Django应用和库移动到合适的位置。 在djangolicious的例子中，我建立了一些django应用和库，如今到时候将django应用移动到合适位置。 $ cd djangolicious/apps $ django-admin.py startapp blog $ django-admin.py startapp reader $ django-admin.py startapp news $ cd ../libs $ django-admin.py startapp management $ django-admin.py startapp display $ cd ../.. $ tree . . ├── djangolicious │ ├── apps │ │ ├── blog │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ ├── __init__.py │ │ ├── news │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ └── reader │ │ ├── __init__.py │ │ ├── models.py │ │ ├── tests.py │ │ └── views.py │ ├── __init__.py │ ├── libs │ │ ├── display │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ ├── __init__.py │ │ └── management │ │ ├── __init__.py │ │ ├── models.py │ │ ├── tests.py │ │ └── views.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── requirements │ ├── common.txt │ ├── dev.txt │ ├── prod.txt │ └── test.txt └── requirements.txt 9个目录，32个文件 如今咱们的工程已经有了实际的架构！已经将django应用和库文件清晰地分开了。这样不只很容易找到想要的应用或者库，并且目录结构也是很是的清晰。 移动应用和库文件后，还须要更新你的引入路径。若是你以前的是这么写的： # blog/views.py from djangolicious.news.models import Newspaper from djangolicious.display.templatetags import top_stories 那么你须要改为： # blog/views.py from djangolicious.apps.news.models import Newspaper from djangolicious.libs.display.templatetags import top_stories 尽管import语句变长了，我发现这对于我这个开发者来找到我所引入的须要修改的app、librarie是颇有帮助的。 你还须要更新你的settings文件来包含新的应用的路径： # settings.py INSTALLED_APPS = ( ... 'djangolicious.apps.blog', 'djangolicious.apps.news', 'djangolicious.apps.reader', ... ) 构建一个完美的Django settings模块 构建完美的Django settings模块被认为是Django开发的“必杀技”。每一个开发者都有着本身的想法，也可能会为此争论。 然而，不少人的作法真实很是错误的。 在此，我来展现了一种正确的方法来构建完美的Django settings模块，无论你工程的大小，需求以及其余因素。 咱们所建立的settings模块： 容许你方便地分离Django各类环境（开发，生产，测试等等）。 容许你保持全部配置信息都在版本控制下。 容许你经过环境变量将密码和其余证书从基本代码中分离出来。 让你能够方便地修改配置。 第一步--模块化，模块化，模块化 就像咱们在前面的章节中处理需求说明文件那样，配置信息也须要模块化！ 首先，让咱们处理掉讨厌的默认settings.py，取而代之的是建立一个更好的目录结构： $ rm djangolicious/settings.py $ mkdir djangolicious/settings $ touch djangolicious/settings/{__init__.py,common.py,dev.py,prod.py,test.py} $ tree . . ├── djangolicious │ ├── apps │ │ ├── blog │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ ├── __init__.py │ │ ├── news │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ └── reader │ │ ├── __init__.py │ │ ├── models.py │ │ ├── tests.py │ │ └── views.py │ ├── __init__.py │ ├── libs │ │ ├── display │ │ │ ├── __init__.py │ │ │ ├── models.py │ │ │ ├── tests.py │ │ │ └── views.py │ │ ├── __init__.py │ │ └── management │ │ ├── __init__.py │ │ ├── models.py │ │ ├── tests.py │ │ └── views.py │ ├── settings │ │ ├── common.py │ │ ├── dev.py │ │ ├── __init__.py │ │ ├── prod.py │ │ └── test.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── requirements │ ├── common.txt │ ├── dev.txt │ ├── prod.txt │ └── test.txt └── requirements.txt 和需求说明文件同样，settings模块也应该针对每一个环境一个配置文件（dev.py,prod.py,test.py）,和一个被各类环境共享的文件(common.py)。 资源 严格来讲，管理Django工程发很须要技术。 然而我也尚未不少好的书籍或者资料能够推荐给你。 要想更好地维护和管理工程，就须要你建立不少项目，而且持续地改进你的代码
