Django應(yīng)用、配置文件以及其他各種相關(guān)目錄的最佳布局是什么樣的？”
    總是有朋友問我們這個問題，因此我想花一點時間，寫一下我們究竟是如何看待這個問題的，這樣我們就可以很容易讓其他人參照這個文檔。請注意，這里是基于 Django 1.7.1 版寫的，但是可以很容易應(yīng)用在 Django 1.4 版之后任何版本。
    雖然 Django 1.4 發(fā)布時，它包含了一個改進后的項目布局（這還用了很長一段時間），但本文有一些優(yōu)化項目布局的更好建議。
    為什么這種布局比較好
    我們在這里推薦的項目布局有幾個優(yōu)點，即：
    讓你獲得、重新打包并復(fù)用單個的Django應(yīng)用來用于其他的項目。這通常是不明確的，正如你正在構(gòu)建一個不管是否要復(fù)用的應(yīng)用。在一開始以想要復(fù)用的方式構(gòu)建應(yīng)用，會讓這一切變得更加簡單。
    鼓勵設(shè)計可復(fù)用的應(yīng)用。
    環(huán)境的詳細設(shè)置。在一個單一的整體配置文件中，if DEBUG==True 沒有什么意義。這使得很容易能看到哪些配置是共享的，哪些是在每個環(huán)境的基礎(chǔ)上可覆寫的。
    環(huán)境的具體安裝要求(PIP requirements)。
    如果有必要，項目級的模板和靜態(tài)文件可以覆寫應(yīng)用級的默認值。
    小而更具體的測試文件更易于閱讀和理解。
    假設(shè)你有兩個應(yīng)用 blog 和 users，以及兩個開發(fā)環(huán)境 dev 和 prod。你的項目布局結(jié)構(gòu)應(yīng)該是這樣的：
    代碼如下:
    myproject/
    manage.py
    myproject/
    __init__.py
    urls.py
    wsgi.py
    settings/
    __init__.py
    base.py
    dev.py
    prod.py
    blog/
    __init__.py
    models.py
    managers.py
    views.py
    urls.py
    templates/
    blog/
    base.html
    list.html
    detail.html
    static/
    …
    tests/
    __init__.py
    test_models.py
    test_managers.py
    test_views.py
    users/
    __init__.py
    models.py
    views.py
    urls.py
    templates/
    users/
    base.html
    list.html
    detail.html
    static/
    …
    tests/
    __init__.py
    test_models.py
    test_views.py
    static/
    css/
    …
    js/
    …
    templates/
    base.html
    index.html
    requirements/
    base.txt
    dev.txt
    test.txt
    prod.txt
    本文的剩余部分介紹了如何將項目遷移到這個布局，以及為什么這種布局比較好。
    當前默認布局
    我們將調(diào)用示例項目foo，我知道這是一個非常有創(chuàng)意的名字。我們假設(shè)在這里，我們將要啟動foo.com。但當我們希望將我們的項目名稱映射最終域名時，該項目將以不以任何意義要求的方式存在在這里。
    如果你使用 django-admin.py startproject foo 命令開啟這個項目，你會得到一個像這樣的目錄結(jié)構(gòu)：
    ?1234567 foo/ manage.py foo/ __init__.py settings.py urls.py wsgi.py
    這種布局是一個好起點，我們有一個頂級目錄foo，里面包含了manage.py文件和項目目錄foo/foo/。在這個目錄，你可以查詢到源代碼控制系統(tǒng)（比如 Git） 。
    你應(yīng)該想到子目錄foo/foo/就是這個項目。這里的所有文件，不是一個Django應(yīng)用程序，就是與項目相關(guān)的配套文件。
    修改配置
    這里的任務(wù)是修正不好的配置文件。我將這個布局向新用戶展示，我往往驚訝于這幾個人怎么知道這甚至可能做到。事實上，當大家都知道這些配置只是Python代碼時，他們也不將它們當做Python代碼。
    因此，讓我們來改進配置。對于oo項目而言，將有4個開發(fā)環(huán)境：dev、stage、jenkins 和 production。給每個開發(fā)環(huán)境一個它們自己的配置文件。這個過程中要做的事情是：
    在foo/foo/目錄下新建一個配置目錄，并在里面創(chuàng)建一個空的__init __.py文件。
    將foo/foo/settings.py移動并重命名為foo/foo/settings/base.py。
    在foo/foo/settings/目錄下創(chuàng)建單獨的dev.py、stage.py、jenkins.py 和 production.py文件。這四種環(huán)境的特定配置文件應(yīng)該包含如下內(nèi)容：
    ?1 from base import *
    為什么這很重要呢？對于本地開發(fā)你想要設(shè)置DEBUG=True，但很容易不小心將這個推到生產(chǎn)代碼中，因此需要打開 foo/foo/settings/production.py 文件，在初始導入base后加上DEBUG=False?，F(xiàn)在，對于這種愚蠢的錯誤，你的生產(chǎn)環(huán)境是安全的。
    還有什么可以定制？很明顯你可以針對不同的數(shù)據(jù)庫，甚至是不同的主機來配置staging、jenkins和production等開發(fā)環(huán)境。然后在每個環(huán)境配置文件中來調(diào)整那些配置。
    使用這些配置
    無論你通常使用哪種方法，使用這些配置都非常簡單。要使用該操作系統(tǒng)的環(huán)境，你只要做：
    ?1 export DJANGO_SETTINGS_MODULE=“foo.settings.jenkins”
    現(xiàn)在你就在使用 jenkins 的配置。
    或者，也許你更喜歡把它們作為這樣的命令行選項：
    ?1 ./manage.py migrate —settings=foo.settings.production
    同樣的，如果你使用 gunicorn，命令則如下：
    ?1 gunicorn -w 4 -b 127.0.0.1:8001 —settings=foo.settings.dev
    還有什么可自定義的配置？
    另一個實用建議是將一些默認的集合配置從元組改為列表。例如 INSTALLED_APPS，將它從：
    ?123 INSTALLED_APPS =（ ... ）
    改為：
    ?123 INSTALLED_APPS = [ … ]
    現(xiàn)在，基于每個環(huán)境的特定配置文件，我們可以更輕松地在 foo/settings/base.py文件中添加和刪除應(yīng)用。例如，你可能只想在dev環(huán)境而不是其他環(huán)境中安裝Django調(diào)試工具欄。
    這個技巧對 TEMPLATE_DIRS和MIDDLEWARE_CLASSES 配置也非常有用。
    我們經(jīng)常使用的另一個技巧是把應(yīng)用分為兩個列表，一個是項目的必要前提，另一個用于實際項目應(yīng)用。如下面所示：
    ?12345678910111213141516 PREREQ_APPS = [ ‘django.contrib.auth', ‘django.contrib.contenttypes', … ‘debug_toolbar', ‘imagekit', ‘haystack', ] PROJECT_APPS = [ ‘homepage', ‘users', ‘blog', ] INSTALLED_APPS = PREREQ_APPS + PROJECT_APPS
    為什么這個有用？第一，它有助于更好地區(qū)分Django核心應(yīng)用、第三方應(yīng)用及你自己的內(nèi)部項目的具體應(yīng)用。對于測試和代碼覆蓋率等事情，寫明你的特定應(yīng)用的PROJECT_APPS列表往往就派上了用場。你有寫一個應(yīng)用列表，因此你可以輕松自動地確保它們的測試運行，記錄的測試覆蓋率只包括它們而不包括任何第三方的應(yīng)用，且無需在兩個不同的地方維護這個列表。
    修改要求
    大多是項目有一個requirements.txt文件，它用如下命令安裝：
    ?1 pip install -r requirements.txt
    對于簡單的小項目這以足夠了，但requirements.txt文件有一個鮮為人知的特點是，你可以使用-r參數(shù)來包括其他文件。因此，對于所有常見的安裝要求，我們可以創(chuàng)建一個base.txt文件；然后，如果我們需要能夠運行測試，我們可以創(chuàng)建一個包含如下內(nèi)容的特定的requirements/test.txt文件：
    復(fù)制代碼 代碼如下:-r base.txt
    pytest==2.5.2
    coverage==3.7.1
    我承認這沒有巨大的好處，但它確實有助于區(qū)分什么是每個開發(fā)環(huán)境的要求。同時，對于其性能，它不會安裝一堆在實際生產(chǎn)中用不上的東西，來減少生產(chǎn)環(huán)境中的pip安裝時間。
    測試文件
    我們?yōu)槭裁匆鸱趾艽蟮臏y試文件呢？其中的一個主要原因是，如果你在一個tests.py文件中對每個應(yīng)用寫了足夠多的測試，那么這個文件最終將變得非常臃腫。這樣的代碼可讀性很差，并且你不得不在編輯器中花很多時間來滾動瀏覽代碼。
    當你和其他開發(fā)者一起工作時，小文件也能讓你在代碼合并時少遇到?jīng)_突。小文件是你的朋友。
    URLs
    對于小型項目，把所有的URL定義放在foo/urls.py文件中，讓它們在同一個地方。但是，如果你的目標是代碼的清晰和可復(fù)用，你最好在每個應(yīng)用中定義它們的url，再將它們包含在你的主項目中。你不應(yīng)如下所做：
    ?12345678 urlpatterns = patterns(‘', url(r'^$', HomePageView.as_view(), name=‘home'), url(r'^blog/$', BlogList.as_view(), name=‘blog_list'), url(r'^blog/(?P<pk>d+)/$', BlogDetail.as_view(), name=‘blog_detail'), … url(r'^user/list/$', UserList.as_view(), name=‘user_list'), url(r'^user/(?P<username>w+)/$', UserDetail.as_view(), name=‘user_detail'), )
    你應(yīng)該這樣做：
    ?12345 urlpatterns = patterns(‘', url(r'^$', HomePageView.as_view(), name=‘home'), url(r'^blog/‘, include(‘blog.urls')), url(r'^user/‘, include(‘user.urls')), )
    模板和靜態(tài)資源
    每個應(yīng)用中都有templates/和static/目錄，這讓一個應(yīng)用可以基本上復(fù)用到其他的項目中。
    對于一個很酷的功能，我們?nèi)谝粋€包中獲得應(yīng)用提供的默認模板和任何相關(guān)的靜態(tài)資源，如特殊的Javascript。
    但是，它也讓我們可以覆寫每個項目主目錄foo/templates/下的模板。我們通過增加一個 templates/blog/detail.html 模板覆寫默認的 blog/templates/blog/detail.html 模板。
    復(fù)用Django應(yīng)用
    假設(shè)你已經(jīng)使用這個布局一段時間，有一天你會意識到你的新項目需要一個blog應(yīng)用，這個從你的foo項目出來的應(yīng)用將是完美的。所以你復(fù)制、粘貼文件……錯誤！現(xiàn)在你有這個應(yīng)用的兩個副本。假定你還記得，在一個副本中進行Bug修復(fù)和新功能增添需要手動地在項目間遷移。
    相反，為你的博客創(chuàng)建一個新的目錄，并把foo/blog/目錄中的內(nèi)容放入其中。同時，調(diào)整現(xiàn)有的foo項目和你的新項目來進行安裝。
    如果需要的話，它們?nèi)匀豢梢愿欉@兩個不同版本的應(yīng)用，或持續(xù)更新，且獲得它們不斷發(fā)展中的所有bug修復(fù)和新功能。你仍然可以在每個項目的基礎(chǔ)上，根據(jù)需求覆寫模板和靜態(tài)資源，所以這樣做真的沒有任何問題。