最近剛換到了新工作不久，新公司與前東家類似，有交易系統的業務存在：幫 user 建立訂單、加扣款、改狀態，核心邏輯圍繞著餘額在轉。
明明到了新的地方，加入了不同的團隊，但卻發現了一個幾乎一樣的 pattern：A、B、C 三個服務都在直接操作餘額表和訂單表，table 都沒有明確的歸屬，誰想操作就去操作。在前公司時每次看到這種架構都覺得哪裡不太對，在新公司看到一樣的 pattern 就更難忽視了。
本篇想從這個 pattern 出發，聊聊微服務架構下資料表的歸屬問題：同一個 table 到底該不該允許多個服務直接讀寫？以及如果只能透過 API 存取其他服務的資料表，如何解決跨服務一致性的問題。
隨著 LLM 越來越成熟，近半年以來在公司開發業務邏輯幾乎都是用 vibe coding 的方式，下指令叫 AI 寫 code ，而自己只負責 review 及微調的模式進行。
vibe coding 這種開發模式真的又快又好用。以往以前要花三五天寫出來的功能，現在透過 AI 的協助大概半天就可以把功能做出來，然後再花半天 review、小調整，自己驗證測試確保所有細節都沒漏掉，基本上功能就是 production-ready 的 level 了。AI 問世後真的是軟體工程師的一大福音 XD。
本篇想分享這半年 vibe coding 以來，自己常用的一些下 prompt 的技巧，讓 AI 產出來的 code 盡量一次到位，避免品質時好時壞差異過大。
公司的Node.js專案在經過好幾年的需求迭代後多少會出現些bad smells，為了解決這些bad smells於是又誕生了一些偏門的寫法，但卻也換來目前開發上很難確認眾多變數中哪些變數會是undefined(對，我們的專案已經寫到連eslint的一些rule都認不得了)。因此最近在研究如何為專案的eslint增加客製化的rule，補上讓eslint去抓出偏門寫法中的undefined變數。
在做了些研究後，發現eslint在為某個檔案做靜態檢查時，會先將整份檔案的程式碼讀一遍，並且建立抽象語法樹(Abstract Syntax Tree)，然後透過遍歷這棵樹的操作去抓出沒有符合rule的地方。
其實不只是eslint，所有編譯器、直譯器在拿到一份程式碼時第一步也是先建立抽象語法樹，所以今天這篇要來簡單介紹什麼是抽象語法樹(Abstract Syntax Tree)，或簡稱AST。
公司目前的服務有幾隻API會提供用戶上傳檔案(KYC及回傳明細)用。而現有檔案上傳機制是將檔案以BLOB的形式存在資料庫的ATTACHMENT資料表內。
這種做法的好處是上傳檔案並且更改記錄狀態可以包成一包transaction，實現業務邏輯上資料的一致性(要嘛用戶的狀態為等待上傳並且屬於此用戶上傳的檔案還不存在、要嘛用戶的狀態為已上傳並且屬於此用戶上傳的檔案已歸檔)。
但是這樣做的壞處是DB那台機器對於操作下載檔案時會消耗一部分CPU與network io bandwidth，也就等於會拖慢DB處理關聯式資料CRUD的主業。隨著使用量的增加，團隊中最近開始考慮要將檔案上傳的功能拆出至DB以外的solution。
最近在工作上需要寫一隻圖片上傳的API，好讓使用者上傳證明用的圖片供後續人工審核用。身為一隻稱職的圖片上傳API，當收到使用者發過來的請求後第一步肯定要做參數檢查，驗證使用者上傳的檔案是不是真的是圖片檔，並將亂上傳的請求拒於門外。
但是今天使用者傳來的是檔案其實對API來說都是binary的形式，要怎麼檢驗它真的是圖片檔呢？如果用最直覺判斷副檔名的方式的話有可能會遇到使用者故意改副檔名，然後惡意上傳其它非影像的檔案，所以用副檔名擋肯定是不夠的。在survey了一下後，發現其實還有一招是可以從檔案內容中的magic number下手來判斷。
近期迴響