by:陳澤榮 (timothychenpc@gmail.com)
日期：0213
因為·這個專案包含了前端和後端，而且也是第一個有明確進行分工的專案。
在開發中主要分成：
- 前端
- 後端
而我不用多說就是負責後端的開發和整個專案的架構設計。後端的部分因為和整體的渲染有關，所以需要等前端，然而前端的
code拿到了，所以理所當然的我就開始後端時間了。。。一、前後端整合：
因為這個專案的前後端是分開分別由不同人進行開發的，所以中間就有一個必不可少的部分就是針對前後端進行一定的整合，
那整合的內容主要分為這幾個方便：
1. 路徑統合（已完成）
路徑是因為前端在開發的時候基本上使用的路徑就是
html默認的相對路徑，包含靜態素材的使用也都是如此，但是後端Flask的部分有另外一套路徑管理專案資料夾
staticcsstemplate.cssjs
templates
server.py
那要將前端並入後端的第一步也就是先統合兩邊的路徑系統（我是直接把前端使用的路徑都改成網域下的相對路徑），
2. 修一些bug（已完成）
這一步主要是為了確保程式碼最後的效果是符合需求的，但是在修
bug的過程中也發現了因為前端的素材中有一個竟然1.8mb，而且每一次載入畫面都需要優先載入，嚴重影響了載入的速度（後來我才發現之前做網站使用的都是1mb以下的素材）3. 構建渲染模板（已完成）
主要是因為
Flask有一個內建的模板渲染引擎jinja2（用於渲染成html）。渲染的好處就是提高可讀性，減少重複不必要的程式碼，方便後續修改等好處。
這邊主要就是可以將前端多個頁面的相同程式碼提取出來，製作成模板，然後每一個單一文件就只需要儲存不同的部分即可（實際使用可能會相對複雜一點）
但最基本的功能就如下圖
4. 實現前後端的數據溝通
這一步也是最難的部分。
一個網站能不能用的關鍵就是完成前後端的溝通（讓前端的功能有實質的作用）
而前後端的溝通基本上就如下圖（至少在我這裡是這樣）
在實際的案例中前端擔任的工作基本上都是可視化的控制台或者美觀的資料顯示等。
前後端溝通的流程
在圖中有很多的下拉選單，而選單的選項內容就需要通過後端動態渲染出來（為了安全性還會渲染出表單的
csrf_token來防止跨佔點存起）。而在選擇完內容後點下確認按鈕的時候就需要將這些資料通過Http Post請求（通常會是表單）傳遞到後端，而後端也不能直接針對這些資料進行使用（因為資料中有時候會有輸出框），所以就需要增加一步，也就是在後端針對前端傳送的表單進行驗證，確保資料的輸入是正確且符合規格的，然後才能進行使用。在驗證完成後還需要將錯誤訊息再渲染進html中，然後再回傳給瀏覽器。5. 寫表單驗證
這部分就是要針對每一個頁面的表單建立一個
Class（因為我是使用WTForms），然後針對每一個欄位的內容編寫驗證的方式等。6. 將後端的功能和前端形成對應關係
主要是為了讓前端可以直接使用後端的功能。
7. 測試和修正bug
二、專案結構優化（已完成）
因為一開始在實現後端功能的時候把大部分的功能實現都放在了主程式檔案
app.py之中為了能讓專案的結構更有條理，並且不讓重複的代碼一直不斷的重複，我把整個專案的目錄大概
最明顯的變化就是在最外層多了一個名叫
ProjectPackage的封裝，會這麼做主要是因為在很多個檔案中都有需要共同的變數，像是client（用來連線數據庫）等，但是重複寫就會多很多冗余的程式碼，所以我就像構建一個全域變數，而這個全域變數是在多個檔案中都可以直接使用的，所以我就想到了package的封裝（你可能會想為什麼不都定義在主程式，然後其他要用就從主程式import。因為這樣會把檔案之間的交互關係搞得很亂，而且很容易就引發循環import的錯誤），如果把這些共用的變數函式定義在ProjectPackage的__init__.py文件中再由其他檔案從中import就可以了（from ProjectPackage import db）
但之後應該就是會持續將主程式
app.py中的程式碼依照功能分出來（方便日後維護小插曲
因為我原本想把
app.py也一起塞到package中的，但是呢上傳到azure的時候就直接報錯了，好像是因為azure的docker容器找不到要執行的對象，所以我就寫了一個啟動指令（類似於heroku的Procfile）但是要寫成startup.txt或者startup.sh
然後我翻到了ms官方寫的文檔，於是照著寫，然後就一直
deploy失敗
嗯還是失敗，後來發現說因為這個方法好像不支援
package
所以後來我才把
app.py獨立在package之外，但是我還是想把app清空，只留下最基本的宣告伺服器物件和一堆import，其他的全部由package完成（期待之後吧）心得：
這個專案距離測試還有大概7天的時候（還已經開學了QQ），所以之後的開發可能會更難抽出完整的時間研究或者進行開發，開發紀錄可能也不會那麼完整（或者是產出可能會比較慢）。
但是呢我也確實在這次的專案中嘗試跟學習了很多（像是之前就一直不太熟的
package），也開始對於專案的架構設計比較由眉目了（主要是也看了很多別人的專案），就希望自己可以繼續進步，然後可以一直保持這這種大局的思考模式吧。然後畢竟這次是團隊的專案，所以在過程中也自然而然的遇到了很多合作的問題，比如像是檔案的同步，銜接，分工等。但我覺得這都是很好的經驗（畢竟我之前比較多都是獨立開發，而一個人的能力畢竟是有限的），就是希望能利用這次的經驗不斷找到更好的共同開發的方法和流程吧（應該會讓大家都使用
Github，因為自從我開始使用GitHub開始就停不下來了），然後讓整個團隊可以一直不斷的進步。