PART 1.?開始之前
django作為一款功能強大的web應用框架，近年來逐步受到大家的歡迎，越來越多的python開發者投入到django的懷抱中，但是同樣由于django中的眾多內容，大家在初入django時總會感到有一些『心有余而力不足』，不知道從何處下手。或者在初步了解之后，仍不確定當前方法是否優雅，不知道如何組織項目，以及如何使代碼重用性更高。
PART 2. 項目架構?
好的項目結構是成功的一半。
2.1 整體結構
在默認情況下，由Django生成的項目結構大概是這樣的：
隨著項目中的Application不停的增加，本地根目錄下的package會不停的變多，導致越來越難維護，所以我們要對整個項目有一個清晰的規劃，合理的放置各個文件的位置。
如果項目較小，且不打算將其中的Application進行各種復用，可以考慮如下方式：
venv文件夾存放項目的virtualenv環境，非必須，可以放置在其他地方。database這個App專門用于存放model、manage的命令以及模板中用到的一些自定義filters，存放在項目根目錄下。docs和logs分別存放工程的相關文檔和運行時產生的log文件。static存放靜態文件，例如css/js/img/font等。utils存放工程中用到的工具函數、類，以及一些通用的模塊，例如logger等。templates存放模板文件，父模板或被多個模板繼承的模板放在根目錄，并且以base之類的名稱命名，方便維護，其余的模板放在對應的application名字的文件夾中。web目錄存放所有的Application，如果有很多的Application，可以在此基礎上分成更多的package來規劃，每個package里存放一類的Application。
2.2?Model
在Model模塊部分，我們主要關心數據到類的映射，一般情況下，每張表對應的類將放置在單獨的文件中，并在models/__init__.py中將對應的類依次導入，這樣在其他地方使用時可以通過from database.models import xxxx導入，給類命名時建議添加上項目的名稱，例如我這里有個項目的名字是Cherry，那么所有的類均為CherryLeaks，CherryVulns等，在reivew代碼以及編寫的過程中會一目了然，知道這個類代表了數據。
建議為Models添加單獨的manager，并實現相應的方法，以避免進行重復操作。
除此之外，還有一些建議，可以根據實際情況取舍：
不建議使用外鍵等類型
每張表添加is_deleted，created_time，updated_time字段
善用索引
2.3 View
大多數業務邏輯應該放在View部分，此部分應該是最核心的。這里也是推薦將功能相近的View全部放置在同一個文件中。方便未來的維護和開發，該文件應被放置于名為 “controller” 或 “view” 的包中。例如處理project相關的路由，全部放置在controller/project.py中。
優先使用Django內置的一些View類，例如ListView，TemplateView等，如果需要自己實現View的情況，推薦使用Class-based view，將不同的請求方法封裝到不同的方法中，方便日后維護。
2.4 Template
對于模板文件而言，最好的方法就是將不同的頁面、功能切割為不同的模板文件，并按Applicatio的名稱按文件夾存放，這樣在后期維護時，可以快速的從每個Application找到對應的模板文件。
除此之外，強烈推薦使用模板的繼承功能，所有的頁面均從父模板繼承下來，并且使用各種block來擴充頁面，父模板中定義好每個位置的block名稱，供子模板覆蓋。建議使用通俗簡短的名稱為每個block命名，例如：sidebar，script，header，main_content，page_title，page_description等。
對于通用的功能，例如評論框，可以考慮單獨存放在一個文件中，在需要的地方通過{% include ‘filename.tpl.html’ %}加載進來。需要注意的是，如果你需要同時使用extends和include指令，一定要在block中使用，否則是無效的。如下例子是無效的：
應當按照如下方式使用：
PART 3. 代碼風格 ?
3.1 docstring
Python語言的靈活性，使得我們有時會在寫代碼時忘記特定方法的參數類型或返回類型。在此情況下，我們需要使用docstring為每個方法提供清晰的信息標注，以便其他人進行開發和維護。參考這個鏈接，如果你在使用PyCharm，可以編寫自動補全docstring。
3.2 多返回值
很多情況下，我們的方法需要返回多個值給調用方，或者通過JSON返回給前端，如果胡亂的返回數據，就會導致開發混亂，到最后根本不知道方法返回了什么東西。
一個比較好的做法就是約定好返回的格式，對于返回給調用方而言，簡單的返回tuple即可，并在docstring中寫明每個值的含義。除了返回結果，有時我們需要返回一個err，以表明在處理數據過程中是否出現了問題或異常。一般情況下有幾種可用的方法：
通過raise拋出異常
通過多返回值返回，例如err, result = func()
通過類中的一個屬性返回，例如instance = Class(); err = instance.error_message
這三種方法均有利弊，需要根據項目的實際情況來選取，無論使用哪一種方法，都需要在整個項目中保持統一，盡可能的不要混合使用；
對于返回給前端的JSON，就需要稍微復雜一些，至少要返回2~3個字段：
code是本次調用返回的狀態碼，根據實際情況自行約定。message 是狀態碼的易于理解的信息，可供開發人員調試并向用戶提供通知。data是實際返回的數據信息，很多時候可以不需要這個字段，具體的字段格式也需要根據實際情況再次進行約定。
PART 4. 路由組織 ?
優雅簡單的路由保證項目質量，降低維護成本。
4.1 路由系統
Django有一套強大的路由系統以及路由算法，可以滿足業務中的各種需要，并且配置靈活簡單，每一個路由配置文件都是URL PATH到function/class的映射。全部都可以自己設置，完全不會受到框架或是其他的一些限制。可以參考文檔中關于Django請求路由尋找策略的這一部分。
在配置路由中，你可以用尖括號括起來一些變量，便于在后面使用。尖括號里可以用一些”路徑轉換器（Path Converters）”來指定變量類型，例如str, int, slug, uuid, path。一個完整的URL路由文件看起來像下面這樣：
除此之外，還可以通過re_path在路由中設置正則匹配：
有些時候，你可能希望為一些URL添加一個默認路由，例如訪問/blog/的時候返回一個默認頁面，而訪問/blog/page
4.2 路由包含
隨著項目的不斷擴大，用到的路由也會不斷的變多，所以Django提供了路由包含的機制，便于我們在不同的App中組織路由。我們來看一個簡單的例子：
這個例子中，將所有請求community/*的路由全部交由aggregator.urls去解析，同理，contact/*的請求也全部交給了另外的路由模塊去處理；如果你的項目中并沒有這么多的Application，依然想通過include的方式來管理路由，那么可以采用如下方式：
4.3 命名空間
一般情況下，我們的每個Django項目都由多個App組成，如果把所有App的路由全部放在URLCONF_ROOT里，時間久了這個文件會變的越來越難維護，十分混亂。在不同的App中可能會使用相同名稱的路由，導致沖突。為了解決這些問題，我們可以通過使用”路由包含”和”命名空間”來解決，特別是如果你在維護一個可以被復用的App，為了保證路由的唯一，命名空間就顯得尤為重要了。
命名空間通常有兩種：Application namespace和Instance namespace，例如admin:index表示admin命名空間的index路由。更多關于該部分的內容可以參考：官方文檔
Application Namespace比較好理解，指的是在應用程序層面上的命名空間，一般是如下方式組織的：
Instance Namespace則指的是實例級別的命名空間，常用于一個App被多次實例化的情況，為了區分每個實例，就需要引入Instance Namespace。我們使用官方文檔中的例子看一下：
可以看到兩個路由author-polls和publisher-polls其實都包含了相同的路由，但是指定了不同的命名空間，這就是Instance級別的命名空間，即當前正在訪問的對象的命名空間。不同的用戶身份訪問不同的URL，會得到不同的命名空間，例如游客和管理員均訪問polls:index所指向的頁面，但是由于命名空間的不同，會得到完全不同的結果。
