Stories by 文科少女學程式 on Medium

【我就廢之亂亂做】我做了一個房租繳費通知秘書

文科少女學程式 — Tue, 28 Apr 2026 13:31:01 GMT

事情是這樣的～最近因為原本的租屋處房東要賣房子，所以搬離了一個租了六年的地方，近期剛搬到新房子，就腦洞大開，想說做一個自動提醒房租已經繳的小幫手來嚇嚇(?)新房東好了。於是就使用了 AI 之力，無腦做了一個小小的 line 房租提醒小助手。雖然整個流程是在 AI 幫助下，兩小時就完成的小幫手，但是還是想要稍微記錄一下，也許哪天可以拿來複用到其他情境。

我想解決的問題是？

以前繳完房租後，因為 J 人的愛管理毛病以及以前當 PM 的職業病，都會將房租繳交紀錄整理在 google sheet 裡面，另一方面也是要整理給房東看，讓房東知道我真的有繳房租。但是寫完紀錄後，我依然需要在群組裡通知房東，我已經把房租匯款給他了，請他確認。這個流程沒什麼問題，但我就是懶，想要用更懶(ㄈㄟˋ)的方式在寫完房租繳交紀錄後，就自動通知房東我繳房租給他了，這時候就會需要房租繳費通知秘書。

房租繳費通知秘書實作方向

簡單來說，

「我需要把 google sheet 和 line 結合在一起，當我完成 google sheet 的房租繳交紀錄後，就自動提醒房東我繳房租了」。

所以觸發點會在完成 google sheet 的填寫，並且需要串接 line 的 push message API，將我想要自動發送給房東的匯款完成通知訊息送出。

實作步驟

1. 準備好用來記錄匯款完成時間和內容的 google sheet 表格。
2. 進入 https://manager.line.biz/ 建立一個 line 官方帳號，並且開啟 webhook。

3. 透過 webhook.site 產一個 Webhook網址，貼到 line 官方帳號後台的 Messaging API 設定，並儲存。（因為我這個通知工具只是給我自己使用，所以使用 webhook.site 建立 webhook 網址，如果是正式對外使用的情境，通常會自己建立對應的 endpoint 網址）

4. 接著把這個建立好的官方帳號，加到和房東的 line 群組中，加入後就可以從前面進入的 webhook.site 網址中取得 groupId。
5. 有 groupId 後，就可以前往 google sheet 連動的 Apps Script 中寫觸發事件後要進行的動作，並且連動到 line 群組中，發送要發送的訊息到對話群組裡面。
6. 最後！還需要前往 developers.line.biz ，選擇對應的 Bot Channel，進到 Messaging API，將 Auto-reply messages 關閉。

否則會出現有人在聊天室裡講話，bot 就會回覆內容的囧境，如下是我實際使用時，發生的尷尬狀況QQ。

目前只用了一次，房東表示覺得有趣，下個月還會繼續這樣使用，不過這個做法仍然有需要改進的地方，主要需要改進的地方是 App Script 的內容，所以我還會再調整一下，但是以 MVP 概念來說，已經是達到我想要的功能的廢廢小工具了。

隨筆紀錄就到這裡啦～

【我是前端工程師！？】原來我的五年經驗在市場上只被認定為是一個 CRUD 工程師…

文科少女學程式 — Fri, 20 Mar 2026 11:31:00 GMT

今天不寫技術學習文，上來打打字抒發一下這一段期間找工作的悲催心得。

前陣子我收到一個面試結果回信，信中內容大概是說我的技術能力跟他們預想有落差，但覺得我溝通能力不錯，所以想找我試試看一半的時間要去和外包商溝通，一半時間做簡單 CRUD 的職缺。收到這個答覆的我在某種程度的感受上其實比直接收到感謝函還要難受，因為我的能力居然只是被認定為能夠勝任「簡單的 CRUD」。雖然我溝通能力很強這件事被認可，但技術力卻被視為什麼都不是，這真的讓我覺得五味雜陳…。我知道一間公司這樣的答覆不代表所有公司都這麼認定，但這樣的答覆也確實在某種程度點醒了我。

回到簡短地自介紹！我是一個從翻譯相關領域轉職前端工程師五年的小廢廢，偶爾會透過寫寫文章來記錄學習，在開發流程上，基本上也沒有太多的問題，即使進入一個新的公司，碰了一個新的產業，還是都有能力在短時間內熟悉公司內部的專案。但我清楚知道這樣的能力依然還是距離市場上大多公司認定的資深工程師，或者是說有經驗的工程師有一段很大的距離。會有這樣的結果主要的原因我認為是我能夠參與甚至是主導專案架構，以及效能優化的經驗基本上可以說是 0。

對！我在就業市場上基本上就是被認定成一個只會 CRUD 的前端工程師！沒錯！就是這麼慘！

這個慘況是我一直有意識到，但卻一直沒有正視的問題，畢竟每天忙著做 CRUD 也是在忙，在還沒要開始找工作之前，就很難被這個殘酷的事實給打醒。當身邊的人感覺都在不斷前進時，被這個殘酷事實打擊到的自己突然有一種「我自己到底在幹麻？」「這條路我還能繼續走下去嗎？」的想法。之前參加 IT 鐵人賽得到的獎項也在這一刻讓我自己覺得格外的諷刺，雖然我自己知道自己不是因為是大大才得獎。這一刻突然又想到前陣子在面試時，面試官問了一句，可以得冠軍的人很多嗎？當時不覺得怎樣，這時候想想該不會是面試官覺得這個人技術力那麼爛怎麼能得獎，是阿貓阿狗都能得獎吧！好啦！不過多揣測對方內心在思考什麼，但結論上的確就是我努力了，但我不夠格！(打字打到這裡突然好想哭，但我把眼淚收住了！)

目前這個狀況的確是我職涯上一個最大的瓶頸，我內心也覺得我大概很難跨過這樣的瓶頸，但是生活還是要過下去，該嘗試的、該努力的我還是會繼續下去，我不知道這樣子算不算硬撐？也不知道是不是這條路對我的智商而言，早就到了盡頭？但不試怎麼會知道？如果我還有在更新，就代表我還活在這條路上，但如果哪天整個部落格都死掉了，我應該已經轉行賣車輪餅了。

不想要等到自己成功跨過這個瓶頸(會有這一天嗎？)才寫一篇文章紀錄此刻的心情，因為會讓人感覺都成功了，才在講好像只是在馬後砲什麼，也搞不好沒有成功跨過的這一天，呵呵！另外，也想透過這種文字的抒發，讓自己得到情緒的宣洩(?)，也許有哪個人路過看到這篇，說不定也可以成為某種慰藉，畢竟大多數的人只會在社群媒體上分享自己好的一面，很少人會在社群媒體上分享自己不好的一面，但當自己已經很糟了，看到別人好的一面可能會更糟，但看到有一個人也是過得滿不好的，就會覺得「看來我不孤單」。

如果你剛好跟我遇到類似的狀況，那你不孤單，但我們也不要消沈太久，繼續往前看，努力自己可以努力的吧！雖然簡少年有說今年是一個「躺平年」，但我想這個躺平應該不是真的字面上的躺平，而是承認自己的不足，正視自己的感受，讓自己去接受自己不好的那一面，並且用積極的態度，或是自己喜歡的方式去慢慢地補強自己。
簡單來說也就是「允許自己不完美，但不停止前進」，這個體悟我送給我自己，也送給剛好路過這篇的各位：）

這篇亂七八糟打的心情紀錄，就到這邊告一段落吧！

【前端新手日記】Tree Shaking 也許沒有真的 shaking 起來

文科少女學程式 — Tue, 30 Dec 2025 15:09:35 GMT

這篇文章是啟發於 JSDC 2025 SerKo 大大分享的「程式碼減重：你的 Tree-Shaking 在偷懶嗎？」，會從 SerKo 分享的內容為起點，補充一些自己本來也是很模糊的地方，以及透過一些實驗來觀察 Tree Shaking 的狀況。

什麼是 Tree Shaking？

從字面上來看就是「搖樹」的意思，但是為什麼要「搖樹」呢？目的就是把樹木上沒用的枯葉搖掉，只保留還有用途的綠葉。延伸到前端開發領域中的話，也就是「在打包的時候，把沒有用到的程式碼移除掉，只保留需要的內容，以縮減打包後檔案的大小，也就不會讓使用者在使用網頁時，因為下載一些不必要的內容，而影響使用體驗。Tree Saking 這個動作，通常都是透過 Webpack、 Rollup 這類的打包工具 (bundler) 來處理。

打包工具怎麼做到 Tree Shaking?

了解完 Tree Shaking 的用途後，我們也來進一步看看打包工具怎麼做到 Tree Shaking 這件事情。
首先，打包工具為避免不小心搖掉不該搖的東西，會以最保守方向來進行 Tree Shaking。也就是說，只要被打包工具認為某些部分「有出現些微可能被使用到徵兆」，就不會被 tree shaking 掉。
在進行 Tree Shaking 時，打包工具會去做靜態分析的動作。所謂的「靜態分析」白話一點來理解的話，也就是打包工具會將所有檔案和關聯檔案 (例如：一個檔案內有 import 哪些東西進來) 之間的關係分析出來，就像是一個樹狀結構一樣，一個檔案的內容可能會有一個分支連結到另一個檔案。當這樣的靜態分析完成後，打包工具在實際上進行檔案的打包時，也就可以知道哪些變數、函式實際上並沒有在整個完整個關係圖裡面，也就可以將沒有關聯的內容給移除掉，不放在打包後的檔案內。

沒用到一定會被 Tree Shaking 掉？

延續前面說的打包工具怎麼做到 Tree Shaking 的部分，是否就可以推論為「沒用到的部分，一定會被 Tree Shaking 掉」呢？其實答案是否定的，這裡可以分為兩個大部分來觀察。

第一個部分、JavaScript 的模組化系統特性

JavaScript 有兩種模組化系統，分別是 CommonJS 和 ES Module，由於兩種模組化系統的特性不同，CommonJS 是動態分析，ES Module 是靜態分析，所以 Tree Shaking 的效果有差異。

這裡直接透過實際的例子來觀察這兩種模組化系統在 Tree Shaking 上的效果，主要會是 JavaScript 搭配 Webpack 這個打包工具來觀察結果。

CommonJS

這是要使用的一些函式

// ✅ 實際會用到的小函式 
function add(a, b) { 
  return a + b; 
}

// 🚫 不會用到的函式 
function random() { 
  return Math.random(); 
} 
module.exports = { add, random };

這是實際使用的地方

const { add } = require("./utils.cjs"); 
console.log(add(1, 2));

雖然 random 實際上沒有被使用到，但是打包後的結果仍然可以觀察到 random 的程式碼存在於打包後的檔案內。

這是因為 CommonJS 的 require() 是在 runtime 進行載入的動作，沒辦法在打包的時候就透過靜態分析明確地知道哪些內容不會被使用到，所以在 CommonJS 的情境下，通常無法做到精準移除未使用的部分，導致未使用的函式仍可能被打包進輸出檔案中。

ES Module

接著來看 ES Module 的情境。
一樣先準備要使用的函式，其中一個函式不會使用到。

// ✅ 實際會用到的小函式 
export function add(a, b) { 
  console.log("addddddd"); return a + b; 
}

// 🚫 不會用到的函式 
export function random() { 
  console.log("ramdooooooo"); 
  return Math.random(); 
}

這是實際使用的地方

import { add } from "./utils.js";
console.log(add(1, 2));

在 ES Module 中，觀察打包後產生的檔案，可以發現到只有出現 add 這個 function，也就是説在這個情境下，有確實地進行 Tree Shaking。

在 ES Module 中，模組的 import / export 結構在build 的階段可以進行靜態分析，因此打包工具可以在打包時明確判斷哪些內容的匯出有被使用、哪些沒有被使用，因此可以更精準地進行 Tree Shaking，移除未使用的程式碼。

由這個情境我們可以觀察到 ES Module 的確比起 CommonJS 能可以更精準地進行 Tree Shaking，但是事實上只要使用 ES Module 就可以百分之百做到完整的 Tree Shaking 嗎？

再來看另一種寫法，這裡改用 default export 的寫法匯出。

// ✅ 實際會用到的小函式 
function add(a, b) { 
  console.log("addddddd"); return a + b; 
}

// 🚫 不會用到的函式 
function random() { 
  console.log("ramdooooooo"); 
  return Math.random(); 
}
export default { add, random };

因為不是使用 named export 的寫法了，所以只能改用以下的寫法 import 和使用。

import utils from "./utils.js"; 
console.log(utils.add(1, 2));

這樣改寫後，再次進行打包看看，可以發現到 random 這個函式沒有被移除，Tree Shaking 失效了！

會有這樣的結果是因為對打包工具來說，等於這個檔案匯入的是 default export 的整個值，而這個值是一個物件，裡面同時包含 add 和 random，因此沒有辦法保證沒有使用到 random ，也就無法安全地把 random 從這個物件移掉。

從目前的觀察的情境可以了解到雖然 ES Module 相較於 CommonJS 能更準確地進行 Tree Shaking，但是還是有可能因為寫法而影響到 Tree Shaking 的準確性。

第二個部分、Side Effect 的影響

除了使用的模組化系統和匯出匯入的寫法會影響到 Tree Shaking 的結果外，Side Effect 也有可能會讓 Tree Shaking 沒有正確地發揮作用。常見會產生 Side Effect 的狀況有寫 console.log、setTimeout/setInterval、throw error 、修改 DOM 等。

這邊也直接透過實際的例子來觀察看看。
我們在原本的 utils 檔案裡建立一個 getValue 的函式，接著將執行這個函式取得的值也建立成一個變數並且匯出。

// 新增一個取得 value 的函式
function getValue(value) { 
  return value; 
}

export const value = getValue(value);

因為沒有使用到這個匯出的 value，最後 build 出來的確沒有出現 getValue 這個函式。

但如果在函式中出現一些會產生 Side Effect 的內容後，會發生什麼事呢？
這裡在函式加上 throw error 的內容。

// 新增一個取得 value 的函式
function getValue(value) {
  if (!value) { 
    throw new Error("key is required");    
  }
  return value; 
}

export const value = getValue(value);

再次 build 之後，會發現這次出現了 getValue 這個函式。

在這個情境下，Tree Shaking 失敗的原因主要就是因為函式內出現了會有 Side Effect 的內容，白話一點也就是出現了會影響外部的內容。再加上這個函式，會在頂層就被執行。也就是說這個函式當整個 utils.js 被執行時，也就會執行到 getValue。

打包工具會以最保險的方式進行 Tree Shaking，所以打包工具會在確保不影響外部狀況、行為的前提下，將不需要的程式碼刪除。當出現會產生 Side Effect 的程式碼，且這段程式碼會在一開始就被執行時，打包工具為了避免影響到其他地方，就不會將其刪除，以避免影響到其他地方。所以並不是使用了 ES Module，且某段程式碼肉眼看到沒有用到，就一定會被打包工具給刪除，還是得注意這段程式碼是否有 Side Effect 的內容。

避開 Tree shaking 失敗的做法

最後也來總結一下避開 Tree Shaking 失敗的方式有哪些：
第一點是盡可能地使用 ES Module 這個模組化系統，並且若是在一個檔案中，有複雜的邏輯及程式碼時，盡可能地避免用 default export 的方式進行匯出。
第二點是避免讓有 Side Effect 的程式碼在最頂層就被執行，這樣會影響打包工具進行 Tree Shaking 的判斷，導致沒有被使用的程式碼還是被保留了下來。
不論是哪一點，核心重點都在於不要讓打包工具有難以判斷刪除時，是否會影響外部的模糊視角。

總結

雖然大多數時候打包工具的確會幫我們做到 Tree Shaking 的動作，但實際上卻有可能出現沒有確實做到 Tree Shaking 的狀況，特別是程式碼中出現 Side Effect 的時候。所以我們都應該要有這個意識去盡量避免寫出會造成打包工具混淆寫法，以避免打包工具因為以最保險的方式進行 Tree Shaking，而讓打包工具沒能完整地進行 Tree Shaking。

【JavaScript 萌新筆記】JavaScript 模組系統 — CommonJS 和 ES Module

文科少女學程式 — Tue, 30 Dec 2025 02:55:52 GMT

【JavaScript 萌新筆記】JavaScript 模組系統 — CommonJS 和 ES Module

今天想來看個基礎到不行，但之前一直沒有好好認識的 JavaScript 常識，也就是 JavaScript 的模組系統 — CommonJS 和 ES Module。

什麼是 JavaScript 的模組系統？

所謂的「JavaScript 模組系統」是指能將程式碼拆分為獨立、可重複使用之模組（module）的機制。透過模組系統，不同檔案之間可以用標準化的方式進行匯入與匯出，使專案在規模變大時仍然可以保持清晰的結構、良好的維護性與重複使用性。JavaScript 的模組系統也就是大家都有聽過的 CommonJS 和 ES Module。

JavaScript 模組系統的歷史背景

接下來讓我們快速來看一下關於 JavaScript 模組系統的歷史。

在 JavaScript 被創造出來的早期，它的用途主要是替網頁加入一些簡單的互動效果，例如按鈕點擊事件或表單驗證。當時的網頁互動仍以整頁重新載入為主，JavaScript 的功能範圍很小，也沒有跨檔案共享邏輯的需求，因此語言本身並沒有內建「模組」的概念。

隨著 Web 應用越來越複雜，JavaScript 在專案中的比重增加，程式也變得難以維護。前端普遍透過多個