AI話題強強滾，自己最近也花了點時間透過某家產品來優化了學校行事曆的管理流程，這個應用面還挺無趣的，但也因為自己不懂程式設計，所以在整個優化過程倒是覺得學到很多。
為何選定行事曆這個主題來做?因為它很煩，每學期得花不少時間才能將學校行事曆內容弄到Google日曆，眼睛也吃不消，所以一開始只是想做個轉檔工具，我只要把學校的行事曆word檔案餵給converter就能變成Google日曆標準格式的csv匯入檔，再將檔案下載匯入Google日曆就完工，結果沒想到一下子就做好了。
轉出的結果也不賴，拿100學年度行事曆來測試轉出了147/2(全天事件站一行)筆活動。但是不難發現其實內容還是有少許地方怪怪的，因為過濾條件不能訂太嚴格，所以會漏掉一些符號在過濾後沒有被處理到。定嚴格一些如果分寸沒拿捏好的結果會造成沒有多少活動能轉出來，所以寬鬆一點後面再微調是比較適合的做法。
所以再增加了一個後台作活動微調用途，因為在Google日曆上修改的方式要每個活動點進去再修改日期、內容、時間，活動沒有辦法一目了然，所以改一個可以切換月份活動的事件列表，直接在操作欄位修改或刪除後自動同步回去Google日曆，我是覺得這樣的工作效率好多了。這個列表最後沒有做成自動雙向同步的版本，其實過程中有做到，但後來決定打掉不要，畢竟內容不是一天到晚在變動，需要修改時手動將最新資料同步回來再改就好了，而且其實也做了排程，每小時同步一次就夠了。
最後也做了一個新的前台，學校網站之前都是放Google的格狀日曆，每個小小的格子其實呈現不了幾個字，總覺得給人不小的閱讀障礙。所以改的這個前台捨棄格狀日曆改採事件列表方式呈現，資料來源沒有選擇走自己的後台，理由很簡單，學校行事曆在大宗活動都上去之後，同事日常更新的習慣肯定是透過手機中的日曆隨時進行增刪或修改，那麼最新的資料來源肯定會是在Google日曆，而我的後台最慢會在1小時後才觸發同步。也因此前面提到後台最終的版本沒有決定做自動雙向同步這個功能。
前端公開的行事曆為了完全獨立運作又不能受到影響，所以讓他走API KEY這條路，後台行政登入以及行事曆操作則是走Oauth的認證，必須是學校Google信箱帳號且為行政團隊的群組成員才能進到後台。前端另外整合了台灣假期的日曆，讓兩個不同的日曆來源一起呈現在前端公開瀏覽的行事曆中。為了做到這樣的區隔，於是請AI幫我將calendar-service.php這支程式一分為二，改成專走API用的calendar-service-public.php以及專為Oauth用途的calendar-service-oauth.php。
最後，不得不提一下資安議題，雖然只是一個看似沒什麼特別的服務，但實際上用到不少敏感的參數，舉凡API Key、Token、Google Client Id、Calendar Id、Google Client Secret、Admin Group…甚至連Log這些都應該要避免暴露。藉由AI寫程式很方便，但是除非自己有經驗能夠判斷與稽核，不然很容易在自己還不是很有經驗的時候、還沒有想清楚的時候就任由AI幫忙寫或搭建一個系統出來，如果有一直在這個系統堅持下去時，應該會發現初期的產品或許能用但一開始的架構並不嚴謹，後續得花很多時間來調整架構與提升安全性。我遇到的狀況就是一開始沒涉獵過API、Oauth、token…這些東西，雖然知道要避免暴露敏感資訊但是不知該如何設計較適宜的架構，所以AI初期幫我寫的程式會把敏感資訊固定寫死在每個需要的php之中，到了中期當架構規模變大之後開始建議我集中設定檔再個別引入以免日後維護不易，這個時候其實我已經上線測試了，要改架構得逐頁檢查再行抽離，其實還挺累人的。但是做到這邊都還談不上是個安全的架構，只有在維護上提升了便利性，但不宜暴露的參數或資訊雖然獨立了，但是都還沒有改為環境變數.ENV再透過定義變數的中介程式去讀取ENV設定值。所以在後期的工作又再次將環境參數等設定調整為.env的架構並放置到站台目錄無法直接存取的位置，接著編輯中介程式再次逐頁比對各項參數進行定義，才能讓這個網站在一個具備基本安全的架構上運作。至於AI給出的程式碼寫得是否安全無虞？這個不是我有能力判斷的事情，連Google、Microsoft等大廠寫出的系統或瀏覽器都需要不斷進行安全性更新，就不要天真的還認為世上會有絕對安全的系統或平台這件事了。
結論，透過AI的輔助容易讓人產生自以為是的錯覺，但是等到海水退了就會知道是誰沒穿褲子@#$…~