[專案開發日常—8]

Tags
linebot
飲水機
Last edited
Feb 19, 2022 02:21 PM
by:陳澤榮 (timothychenpc@gmail.com)
日期:0219-0220
 
先獻上一張今天的Github修改紀錄(一個addition是一行)
先獻上一張今天的Github修改紀錄(一個addition是一行)
notion image

改動:

一、修改專案整體架構

這裡主要是因為上次針對專案結構進行的修改,開始採用封包Package的方式管理整個專案,然後上次也有提到希望未來可以將原本的主程式的內容app.py中的東西根據功能丟到不同的檔案中進行處理,也希望能夠方便之後的維護,然後上次在跟巨耀資訊的工程師對談(就是開發學習歷程檔案系統的公司)的時候,對方也有提到專案的元件化的重要性和影響(模塊化),這個東西我其實一直有在嘗試這樣的想法(大概國一用ExcelVBA那時候),但是那個時候也只是函式化之類的,也並沒有嘗試到進行如此完整的一個專案的開發。
當然在元件化的過程中最困難的就是數據的互通(因為不同的檔案往往需要使用同一組變數),原本的想法是直接將變數寫在__init__.py檔案裡面,然後由其他的檔案對其進行import獲取變數,但是如果是這樣要實現變數的同步就會非常困難(比如在A檔案修改import的變數希望在B檔案也可以同步看到修改過的結果),當時也是卡在這一步超久。後來經人指點,發現OOP好像可以解決這樣的問題(使用物件),就是說python的物件,在實例化之後,在檔案之中import的時候在所有檔案都會是同一個物件(就不會像其他的變數是複製的效果,這樣是reference的好處啦)。
在__init__.py中針對Parameter物件進行實例化
在__init__.py中針對Parameter物件進行實例化
然後後來就是將所有共用的變數和函式都放在一起,在__init__.py建立一個Parameter物件,然後之後所有要用到相關的函式就可以直接匯入實例化後的parameter物件。這樣做的好處就是我只要在一個檔案確保所有變數跟資料庫同步,那本地的所有檔案中的parameter的屬性也都會自動同步(而這也為我能夠把大概建構提供很好的幫助)
_ _init_ _.py實際上大概看起來會是這樣
_ _init_ _.py實際上大概看起來會是這樣
當然我也同樣把所有linebot的方法比如search等函式都放在__init__.py中編寫。因為最終的目標是在app.py檔案中可以只剩下簡短的程式碼來描述這個專案的架構流程(有點像是app.py是流程圖而實際的實現和執行都分到不同檔案進行)。
但是這樣也就意味著基本上每一個檔案都要大概要大量重改,好在改完效果還不錯(app.py從快200行縮減到36行左右,應該還可以縮減),而且整體的專案結構也相對起來更加的清晰
 
before
before
 
after
after
但是方便的程度也是顯而易見,只要我想新增一個檔案(可能用來做表單處理),只要from ProjectPackage import parameter就可以得到我想要的所有變數
 

目前的專案結構:

  • app.py 伺服器主程式
  • ProjectPackage
    • __init__ .py 封包的初始化文件也是parameter物件定義的地方
    • routes.py 使用blueprint將路由處理分離出來
    • forms.py 用於定義表單處理所需要的class
    • config.py 伺服器的設定檔(包含APScheduler)
    • linebot_control.py linbot callback handler所對應的處理函式,用於處理linebot的各個指令,以及進行回覆
    • tools.py
  • templates 渲染網頁模板的路徑
  • static 靜態資源的路徑
  • startup.txt azure的啟動指令(gunicorn)
  • requirements.txt 依賴庫以及版本的限定
 
——————————————————————————

插曲時間

檔案在改的過程中真的遇到相當多的問題。

裝飾器問題

因為眾所周知(應該吧),在使用linebot的時候針對callback路徑的請求會先被解析,包裝成event然後在呼叫函式裝飾器對event進行處理,但是裝飾器(decoratiors)是綁定函式運作的
notion image
類似這樣,然而當我將callback的處理函式和裝飾器分開後,就出現了沒有回應的情況(就是我使用自己定義的指令呼叫linebot但是卻沒有得到任何的回應,也沒有報錯)
notion image
當時的猜測就是因為因為裝飾器要跟對應函式在一起,所以如果在callback所在的檔案中沒有import那個被綁定的函式就會導致裝飾器沒有對應到處理的函式(這裡是echo),也就自然不會進行處理
加入了針對裝飾器對應函式的import
加入了針對裝飾器對應函式的import
然後結果跟我想的一樣,就好了
 
——————————————————————————

二、檔案路徑修改

因為原本的針對檔案的讀寫,是用資料夾進行路徑的認定(後來全部改成當前位置的相對路徑認定)
before
before
after
after
before
before
after
after

心得:

到現在還是感覺上次去面談很有收穫,因為回來就一直在想專案的結構(搞不好之後會走架構師也說不定,因為架構師的薪水高高的,而且我覺得架構才是王道,因為像是Copilot這類的東西的出現,在未來單純寫程式實現特定功能的工作很有可能被AI所取代。但是目前看起來AI還沒有能力觸及架構設計的領域),反正就是在專案的架構上花了很多的心力想要去維護跟做得更好,因為這次的專案其實沒有到非常難,但是我覺得也剛好用這個題目好好的針對專案的結構進行一次設計(然後那個通過物件傳遞的方式真的是太妙了解決我苦思冥想很久的問題),而且隨著對物件的接觸越來越多,也漸漸的開始意識到OOP的重要性和方便性,很多時候很多的事情都可以通過OOP進行解決,而且用物件寫出來的東西結果通常都還不錯。
而當我開始解決完元件化的問題(包含變數的同步問題)之後就開始嚐到一些甜頭了,之後的編寫變得很快,腦中的結構也更加的清晰。
然後呢從寒假什麼一有空就是半天一天的坐在電腦面前開始,開始會有一些肩頸痠痛等等,而且因為平常的通勤時間的關係也沒有時間可以運動,但這樣好像身體漸漸會開始有些問題,所以我要開始鍛鍊了(健身房健身房~~~),希望可以好轉
然後接下來就是繼續完善整體的架構,然後找個時間深入了解一下關於MVC架構的內容,然後就是要盡快完成功能的實現咯(希望28號前可以完成)
notion image
notion image