Overview 什麼是提升 (Hoisting) 提升 (Hoisting) 的運作方式 文章中沒解釋的進階知識 什麼是提升 (Hoisting) 變數與函式在程式碼執行之前被『Hoisting』到作用域的頂部，這樣可以確保在執行程式時，所有變數與函式宣告都已經準備好可以使用 Hoisting 的設計主要是為了讓開發者在撰寫程式碼時更有彈性，最常見的是函式之間可以互相呼叫而不會導致錯誤 提升 (Hoisting) 的運作方式 JavaScript 是一個解釋型語言，解釋型語言指的是透過直譯器 (Interpreter) 逐行讀取並執行程式碼的語言，不過現今的 JavaScript 是透過 V8 引擎進行處理，V8 引擎提供『即時編譯(Just-In-Time Compilation, JIT)』，過程並不是逐行解釋程式碼而是先掃描整個程式碼，進行語法解析並生成機器碼(Bytecode)，在程式碼執行過程 (runtime) 會監控執行比較頻繁的程式碼將其編譯成機器碼以提升運行效能 現行的框架多數提供『提前編譯 (Ahead-Of-Time Compilation, AOT)』讓程式碼在部署前就提前編譯成機器碼，透過機器碼提升程式碼”啟動”的速度 JIT 側重於運行時的性能提升：因為會在執行過程中動態針對頻繁執行的程式碼進行深度優化，使長時間運行的應用程式 (Node.js Server) 效能更高 AOT 側重於啟動時的速度提升：因為提前將程式碼轉為機器碼，適合在意載入時間的應用程式 (網頁與行動裝置) Hoisting 發生於 JavaScript 編譯階段，而不是執行階段 當 JavaScript 編譯器掃描程式碼時，會將所有變數宣告和函式宣告『Hoisting』至作用域的頂部，這些宣告都會被記錄到記憶體中，此過程即為『Hoisting』，需注意的是，Hoisting 只 Hoisting 變數的宣告不 Hoisting 賦值，因此程式碼執行前 var 宣告的變數會被初始化為 undefined let 和 const 則會因『暫時性死區 (Temporal Dead Zone, TDZ)』的原因，若在宣告前使用該變數，會觸發 ReferenceError 參考以下實際例子的 Hoisting，主要是傳達概念，實際運作會更複雜 使用 var 的變數在宣告前就呼叫 編譯前

前言 最近想要抓實價登錄的資料來看，但是懶得去找可以免費 setup Server 的服務，但如果沒有一直在跑的 Server 怎麼去跑 Cron Job 來更新資料以及確保資料有被存放呢？ 於是就想說試試 GitHub Workflow 能不能達成這件事 XDD 如何設計 GitHub Workflow 基本上設計流程如下 Trigger Workflow by Schedule Run download-data Script Commit and push changes Trigger Workflow by Schedule 我們可以使用官方提供的 events-that-trigger-workflows#schedule ，來達到這個方式，他的時間結構如下 * * * * * ┬ ┬ ┬ ┬ ┬ │ │ │ │ └─ 星期 (0 - 6) │ │ │ └─── 月份 (1 - 12) │ │ └───── 月中的某天 (1 - 31) │ └─────── 小時 (0 - 23) └───────── 分鐘 (0 - 59) 因為實價登錄是每 10 天更新，但我避免誤差，所以設定成每個月的 02 / 12 / 22 號，因此我們的 Workflow 一開始會長這樣

這是關於整理報表時，遇到兩個模組間邏輯會打架的工作雜記，以下除了處理過程相似，其他模組與表格都是虛構 故事脈絡 最近遇到要把以前的報表新增加權分數(weighted_score)的欄位，而報表資料主要是從使用者評分表 Table 撈取出來整理的，加權分數以前是在其他模組計算但沒有被存放到 Table 中，使用者評分表的 Schema 簡化後大概如下 欄位名稱 資料類型 說明 id INT(PK) 主鍵 user_id INT(FK) 外鍵 value INT 新增/扣除的分數 params JSON 放置分數相關的任意資料 confirmed BOOLEAN 已經評分過的資料為 true 範例資料 id value user_id params confirmed 1 122 12 { “type”: 1, “weighted_score”: 456 } 0 2 19 11 { “type”: 2, “weighted_score”: 314 } 1 處理過程 建立共用的模組 由於以前的程式碼在計算加權分數時是直接計算，而加權分數其實會因為不同類型的type而有不同的加權計算方式，為了在報表也能使用這套邏輯，所以我們需要先抽出一個模組 Calculator ，慶幸的是這套邏輯已經有寫測試，所以我們可以省掉寫測試的時間直接重構即可，這邊我是使用工廠模式來處理，後續直接套用模組跑測試無誤就算是完成這個階段，可以到下一個階段進入資料的處理惹。 將計算完的資料放進 Table 中 這邊介紹一下會用到的兩個模組，模組 D 是負責進行使用者扣分的模組，而模組 DeductPoint 是接收到扣分行為時會去使用者評分表把扣分的資料寫入進去，有個需要注意的地方是，扣分會先從確認過(confirmed = 1)的分數先扣不夠再從未確認(confirmed = 0)的分數扣，所以有可能會一次扣分行為但記錄兩筆資料到使用者評分表…