竹子日誌

AI 不會痛，所以沒有人重構：Vibe Coding 真正的天花板

竹子日誌（竹子） — Thu, 27 Aug 2026 05:22:00 GMT

上禮拜有個朋友傳訊息給我：「你可以幫我看一下專案嗎，這個 bug 我修三天了。」

他做的是一個接案用的預約系統。純 Vibe Coding，一行程式碼都沒有自己寫過。

兩個月前他還很興奮地跟我說，兩個禮拜就做出來了。有登入、有行事曆、有金流、有後台。他當時傳畫面給我看，老實說做得蠻好的，我還跟他說這樣很不錯。

結果第三個月，他卡住了。

——

三個月、四百多個 commit，刪除行數幾乎是 0

我請他把專案打開給我看。

handleBooking、handleBookingNew、handleBookingV2 三個並存，前面兩個沒人敢刪。

日期格式化有三份實作，分散在三個檔案裡，出來的格式還不太一樣。

到處都是 try/catch 跟 ?.，包到你看不出來原本的邏輯長什麼樣子。if (!data) return 這種防禦大概散在幾十個地方。

我問他這些 V2 是誰加的。

他說：「都是 AI 寫的吧？我也沒有看過程式碼。」

但真正讓我確定他撞牆的，不是這些。

是我打開 git log。

三個月、四百多個 commit，刪除行數幾乎是 0。整包專案從頭到尾只有 +，沒有 -。

——

沒有人痛，就沒有人重構

程式碼會爛，這件事在傳統開發裡也天天發生。

差別在，傳統開發有一個很土但有效的機制在擋：人類看到髒扣會不舒服。

家裡的垃圾之所以有人倒，不是因為誰特別勤勞，是因為放久了會臭，臭到有人受不了。技術債會被還也是同一個道理，很多時候不是誰特別有紀律，是有人被那股味道追到不行。

那段程式碼爛，下一個接手的人會痛。痛到受不了，他就會去重構。

但 Vibe Coding 把痛拿掉了。

AI 不會痛。你叫它在一坨爛程式碼上面再長一個功能，它不會抱怨，不會嘆氣，不會跟你說「這邊要先整理一下」。

它就是加。

而你根本不讀那些程式碼。

於是沒有人痛。沒有人痛，就沒有人重構。沒有人重構，那個 - 就不會出現。

傳統開發與 Vibe Coding 兩種循環的對照：前者因為有人會痛而回到重構，後者因為沒有人痛而不斷疊加傳統開發程式碼變爛有人接手他會痛動手重構有人痛，債就會被還 Vibe Coding 程式碼變爛 AI 接手沒有人痛再加一層沒有人痛，債只會疊上去

兩個循環長得幾乎一樣，差別只在第三格。有人會痛，債就會被還；沒有人痛，程式碼就只會一直往上疊。

——

極限不是行數，是你驗不驗得出來

我一開始也是這樣想的：純 Vibe Coding 到底能撐到幾行、幾個功能、幾個頁面？

後來我覺得這個問法是錯的。

同樣三萬行，一個後台管理系統可以一路 vibe 到底，一個對帳系統早就死了。

差別在你驗不驗得出來。

版面爆掉、按鈕沒反應、資料沒出來——你看一眼就知道。這種錯誤你當場就能驗收。

但權限少判一條、同一筆訂單被扣兩次、快取沒清、資料遷移掉了幾百筆——這些東西不會有畫面跳出來告訴你。

AI 一樣可以改到「看起來好了」。

問題是你已經沒有能力判斷，它到底是真的好了，還是這次剛好沒踩到。

也許有人會說，那我控制一下規模就好了嘛，寫到某個行數就收手。

但行數從來不是那條線。Vibe Coding 在原型階段爽到不行，是因為那個階段的驗證成本趨近於零；一旦專案開始碰到看不見的正確性，天花板就到了。我之前寫過一個人用 Vibe Coding 做到 95 分的字幕產品，那五分缺的也是同一種東西。

——

它不會壞掉，它會變貴

我覺得這件事最需要講清楚的地方在這裡：沒有人會收到一個「已達 Vibe Coding 上限」的錯誤訊息。

不會有一天專案跑不動。

實際發生的是，以前一個下午的功能，現在要三天。以前敢說「這段重寫一下」，現在不敢碰。

專案是慢慢失速，不是崩潰。所以大部分人都是回頭看的時候，才發現自己早就過線了。

那還能不能繼續靠 Vibe Coding 解？能。幾乎永遠都能，這才是麻煩的地方。

AI 讓症狀消失的能力接近無限。你說哪裡壞了，它就讓那裡不壞。

但它解掉的是那一次，不是全部沒事。

所以你會有一種很怪的體感：每一次都修好了，但永遠修不完。同一種 bug 換個位置又冒出來，你也說不出它們哪裡一樣，就是覺得很眼熟。

其實 AI 不會發現哪裡奇怪，它只會聽令於你繼續做。

——

那要怎麼做才撐得住？

講完問題，來講做法。這三件事我覺得順序不能換。

一、系統的核心，要放在檔案裡

整件事可以收斂成一個問題：這個系統的核心放在誰身上？

放在你腦袋裡，上限就是你記得住多少，大概幾週。放在這次對話裡，上限就是這個 session，關掉就沒了。

所以我一再推崇文件、文件、文件。

只有「給人類閱讀的文件」留得下來，有故事、有脈絡、有核心價值，去蕪存菁，不要有太多雜音。

規格要變成檔案，不是變成聊天記錄。

你跟 AI 講過的每一個決定，都會在關掉視窗的那一刻消失。下次它重新猜一遍，猜出來的不見得是同一套。

所以要有一份規格文件，講清楚這個系統有哪些角色、哪些狀態、什麼情況不能發生。每次改動完，順手叫 AI 同步回去。

這份檔案才是你真正的資產。程式碼是最不值錢的，現在最值錢的是你運轉起來的商業模式。

二、測試是把看不見的錯誤變成看得見

寫測試不是為了覆蓋率，是為了讓「壞掉」變成看得見。你也仍然需要一個現在會失敗的測試。

不要以為使用者會照你的預期走。上一頁、重新整理、直接關掉⋯⋯沒有測試，你根本管不到這些奇怪的行為。

Vibe Coding 的天花板是驗證能力，測試就是把不可見的正確性強制變成可見。

這件事本來就很適合交給 AI：你先描述「什麼情況算錯」，讓它寫出一個現在會失敗的測試，再叫它去改到通過。順序反過來，你就永遠只是在看畫面猜。

三、模組要切到你敢整包重寫

Vibe Coding 最強的地方是重生成，不是維護。

所以模組要切到一個程度：這塊爛掉了，你可以連同它的測試整包重寫，不會牽動別人。

判準很簡單——你敢不敢跟 AI 說「這個資料夾整個重做」。不敢，就是切得不夠開。這是我覺得最便宜、也最有效的一個習慣。

至於怎麼看有沒有在整理，你不用真的去讀程式碼，看 diff 的加減行數就夠了。專案只長不縮，代表沒有人在整理。等到累積到十萬行？三十萬行？一百萬行？你才會感覺到真的不對勁。

——

寫到這邊好像變成在勸大家回去寫測試、寫文件、做重構。

但我想講的其實是：這些事現在全部都可以叫 AI 做。

你可以叫它補測試、叫它設計邊界、叫它維護規格、叫它去刪自己上禮拜寫的垃圾。你依然一行程式碼都沒有自己寫。

所以會撞牆的，從來不是 Vibe Coding 這件事，是那種什麼都不留下的做法。

——

但我還是要講一段比較難聽的

我朋友算是運氣好的。

他那個系統還沒有真的收錢，使用者只有他自己跟兩個測試的人。他發現得夠早，重寫一個禮拜就結束了。

比第一次做久了三倍，但他現在敢改了。

「敢改」這兩個字，我覺得就是分水嶺。

真正麻煩的，是那些已經上線、已經在收錢、資料庫裡躺著幾千筆別人資料的專案。你可以承受動不動就改資料庫？動不動就掉幾百筆別人的資料？

因為你看不見的那些錯誤，第一個發現的人通常不是你，是使用者。

他發現的時候，通常已經是「我的錢被扣兩次」「我看到別人的訂單」「我的資料不見了」這種形式。

到那個時候你面對的不是 bug，是要不要退款、要不要公告、要不要通報個資外洩。

我知道講這些很掃興。我一直很鼓勵非工程背景的人玩玩 Vibe Coding，大家在上面得到的快樂是真的，我自己也很享受。

但快樂跟風險從來就不是同一件事。你在兩個禮拜做出一個系統的時候，省下來的不只是時間，還有那些原本會逼你想清楚的環節。功能做出來只是一句話，難的部分本來就不在那一句。

省下來的部分沒有消失，它只是被記在後面。

所以最後我想問的，不是你的專案有多大、有幾行、做了幾個功能。

是這個：如果今天有人跟你說「你們系統有個地方好像會多扣錢」，你有辦法在半天之內確認他到底是不是在唬爛你⋯⋯？

不就一個下拉選單，是能有多難？

竹子日誌（竹子） — Fri, 21 Aug 2026 01:30:00 GMT

「不就一顆下拉選單，是能有多難？」

這句話我真的說過。

然後我就把它重寫了八次。

而且到現在還沒做完。

——

起點不是想造輪子，是一個搬不動的案子

先講清楚，起點不是「我想造輪子」。

公司有一套自己的 UI Library，那套東西已經改不動了。所以我們就想說，那不然遷移到主流的那幾套吧，Element Plus、Naive UI、Ant Design，隨便挑一套都好。

結果一對照就卡住了。

卡在哪？卡在 API 落差太大。

這裡我要特別強調一件事：不是那些現成的 Library 做得爛。它們都做得很好。是我們需求的方向，跟那些 Library 想像的使用方式，差太多了。

那硬要接呢？

硬要接的結果，就是包一層 adapter，再包一層 adapter，最後你把兩邊的壞處全部扛回來——現成 Library 的限制你要吃，自己那層轉接的複雜度你也要養。

那條路走不通。剩下的選項只有一個：自己手刻。

於是真正的問題，就從要用哪一套 UI 框架，變成——要挑哪一顆底層來墊底，才撐得住這些需求？

而要回答這個問題，你得先知道一顆 Select 到底難在哪。

——

我造這顆輪子，是為了什麼

在開始之前我想先把目的講清楚，因為後面每一版的取捨，全部都是靠這幾句話撐著的。

搞懂一顆 Select 到底難在哪。不是聽別人說，是自己知道。

把那些「別人早就幫我處理掉的事」，自己踩一遍。你用現成元件庫的時候，有一大堆東西是免費的，免費到你根本不知道它存在。

還有，逼自己從「會用」走到「敢設計 API」。這兩件事差很遠。

那反過來，它不是為了什麼？

它不是為了取代 Element Plus、Naive UI 或 Ant Design。真的不是，等一下你就會看到我離那個距離有多遠。

它也不是為了證明現成元件庫做得不好。恰恰相反——這趟走完，我對它們的敬意是變多的。

造輪子的產出，從來就不只是那顆輪子。是「看懂別人的輪子」這件事。

——

那叫 AI 生一顆 Select 不就好了？

2026年了，你講這些幹嘛？

可以啊，真的可以。你現在打一句「幫我做一顆 Select」，它真的生得出來，而且跑起來看起來還會動。

所以問題根本不是「做不做得出來」。

問題是你接不接得住。

你得看得出來它缺什麼。鍵盤能不能用、ARIA 有沒有補、被 overflow 切到會怎樣、資料上萬筆會不會爆。這裡少一樣，就是使用者那邊的一個 bug，而且是那種「回報上來你還看不懂他在講什麼」的 bug。

你得判斷這些有沒有必要。不是每個專案都需要虛擬列表。你多做的每一層，之後都是要養的。AI 很樂意幫你多做十層，反正它不用養。

你還得知道怎麼測試。這個最麻煩——當你沒有驗收標準的時候，「看起來會動」就變成唯一的標準了。

這三件事，都不是 prompt 給得出來的。是自己踩過一遍才長出來的。

所以下面這八版，我不貼程式碼。反正 AI 都寫得出來，我只講每一版壞在哪。

——

v1 到 v4：我把原生 select 免費送的東西全丟了

v1 的目標只有一句話：用最少的程式碼，換最穩的行為。

所以我就包一層原生的 select，行為跟無障礙直接白嫖，一行都不用寫。我做的事情就只是把介面補一補——v-model 雙向綁定、用一個 options 陣列餵資料、單一選項可以 disabled、size 三種、placeholder 拿一個 disabled 又 hidden 的 option 撐出來。

就這樣。

這一版是我八版裡面程式碼最少、而且最不會出事的一版。Tab 聚焦、方向鍵移動、打字跳項、Enter 選走、Esc 關掉，全部都有。

我一行都沒寫。

請記住這件事，因為接下來七版，我都在還這一版免費送我的東西。

那為什麼要換掉？

因為 v1 那個原生面板，我一點都動不了。設計師給我一張稿，我只能跟他說「這個不行」。而且各家瀏覽器長得都不一樣，你連截圖驗收都有困難。

所以 v2 我把 trigger 改成一個 div，面板改成 ul 加 li，原生的 select 退場。下拉的長相完全我說了算，跨平台終於一致。

看起來完全沒有退步對吧？外觀還變好看了。

但這一版同時埋了兩顆地雷。一顆 v3 爆，一顆 v4 爆。

第一顆是 overflow。 v2 的面板是 position: absolute，貼著父層定位。聽起來很合理，問題是只要祖先裡面有任何一個人掛了 overflow: hidden、auto 或 scroll，超出容器的那截面板就會被切掉。

而 overflow 這種東西，在真實專案裡多如牛毛。卡片、對話框、表格、側邊欄，隨便一個都有。

結果就是：選項在那裡，但你點不到。

面板貼著父層定位會被 overflow hidden 切掉，Portal 到 body 之後就不會 v2：面板貼著父層卡片 overflow: hidden 選擇縣市這一截被切掉，點不到 v3：Portal 到 body body 卡片選擇縣市浮在最上層，誰都切不到

使用者感受到的是「這個能用、那個不能用」，但真正的差別，只是那個面板的 DOM 節點掛在哪一層。

怎麼爬出來？我做了一個 Portal 元件，其實就是 Teleport 薄薄包一層，預設送去 body。面板改由 Portal 送出去，定位改成 position: fixed 加上 trigger 的 viewport 座標。

但這裡就出現了那個很典型的東西——你解掉一個問題，就領到一個新的責任。面板既然浮在 body 上，你捲動頁面或改變視窗大小，它就會脫節。所以 v3 得監聽 scroll 跟 resize，即時把座標校正回來。

第二顆雷比較痛，因為它是我自己弄丟的。

回頭看一下 v1 免費送我什麼：Tab 聚焦、方向鍵移動、打字跳項、Enter 跟 Esc 開合，還有螢幕閱讀器讀得懂的語意。

然後 v2 我為了搶回外觀的主導權，把 select 換成 div，這些全丟了。

更糟的是，我當下根本沒發現。

因為我是用滑鼠測的。滑鼠測起來一切正常。

你有多久沒有拔掉滑鼠，用 Tab 走一次自己做的表單？我當時的答案是：從來沒有。

所以這筆債欠了兩版才還。v4 把鍵盤（方向鍵、Home、End、Enter、Esc、typeahead）、焦點（Tab 進得來、有 focus ring、關掉要收回來）、ARIA 語意（combobox 加 listbox 加 option）全部補回來。

真正的魔鬼細節在這兩行：鍵盤走的時候要自動跳過 disabled，不然你按方向鍵，高亮停在一個選不到的東西上面，那很怪；高亮跑出可視範圍的時候要自動 scrollIntoView，不然你按到第20項，畫面還停在第5項。

這兩件事，原生 select 都幫你做好了。你根本不會意識到它存在。

還有一個我沒想到的：高亮不能有兩套。v3 的高亮是 CSS 的 hover，v4 得改成一個 activeIndex，鍵盤跟滑鼠共用同一套。不然滑鼠停在 A、鍵盤走到 B，畫面上就兩個亮的，超級錯亂。

繞了一圈，我才把原生本來就有的可及性補回來。而且我補的一定沒有原生完整。

老實說，無障礙這件事最容易被跳過的原因不是「它很難」，是你自己用滑鼠測，永遠測不出來。

它壞掉的時候不會報錯，Console 一片乾淨。只有真的用鍵盤、用螢幕閱讀器的人會知道。

而那些人，通常不會出現在你的 bug 回報單裡。

——

v5 到 v8：先拆開，後面三版才走得動

到 v4 為止，Select.vue 這一個檔案裡面塞了六件事：狀態機、定位、清單導覽、typeahead、選取、渲染。大概500行。

500行其實還好，真正的問題是我每次要改一件事，都得先在腦子裡把另外五件事排開。

所以 v5 我照兩條線下刀：一條是「大腦」跟「臉」，邏輯跟呈現分開；一條是「不會變的邏輯」跟「會變的內容」。邏輯搬進 composables，呈現搬進子元件，Select.vue 就只當那個協調的人，剩下大概100行。

判斷標準我是拆完之後才想清楚的：會各自變、能重用、自己帶著不簡單的狀態，中一個才拆。純呈現的葉節點，像那個小箭頭，就別拆了。

拆過頭跟不拆一樣痛，差別只在痛的地方不一樣。

v5 同時做了第二件事：面板會自己翻面。v3 跟 v4 一律往下開，所以只要你的 Select 靠近視窗底部，一展開就溢出去了。v5 會先量一下：下面還剩多少空間？不夠而且上面比較寬，那就往上翻，然後照剩下的空間把 max-height 夾住。

這兩件事其實是同一件事。

因為 flip 那段邏輯，就住在我剛剛拆出來的 useFloatingPosition 裡面。如果沒有先拆，這段定位算式就會變成 Select.vue 裡的第501到第560行。

然後 v6、v7、v8 都在領這次重構的紅利。

v6 打字就過濾。 長清單一定要能打字過濾，縣市、使用者、商品，只要超過二三十筆，你叫使用者用捲的，那就是折磨。中文情境還多一件事，得能打拼音才找得快——你要選「高雄」，很多人習慣先打 gx。

爽的地方在這裡：還記得 v5 我特地拆出一個 SelectValue，專門負責顯示值嗎？v6 我就是把那一塊換成搜尋 input。當時我只是覺得「這塊會變」，結果一版之後就真的變了。

而且我想講一個觀念：v5 打字是 typeahead 跳項，v6 打字是過濾清單。同一個動作，兩種語意。所以這不是「加功能」，是換了一種互動模型。這種時候用一個 filterable prop 切開，而不是硬要合成同一套行為，通常會活得比較久。

v7 多選。 原生的 select multiple 那個體驗，算了吧，要按住 Ctrl 才能複選，手滑一下全部選取消失。所以 modelValue 變成陣列，選取行為從「蓋掉」變成 toggle，而且面板不關——因為你要連續選，每選一個就關掉那很煩。

多選的差異幾乎只落在 useSelect 的選取邏輯裡。定位、清單導覽、過濾、typeahead，全部都不用動。

但我最想講的是這個小細節——多選加搜尋的時候，在空的搜尋框按 Backspace，會直接拔掉最後一個 chip。

這個行為沒有人會寫在需求裡。

但所有人都預期它要有，因為 Gmail 收件人就是這樣。

這種「沒人講但大家都預期」的東西，就是元件庫最花時間的部分。

v8 遠端、無限滾動、虛擬列表。 v6 的搜尋只能過濾「已經在前端」的資料，但真實資料動不動就上千上萬筆，一萬個 li 光是掛上去就卡住了。所以虛擬列表開 virtual，5000筆只渲染大概15列；捲到底送一個 load-more 事件；開 remote 就不在本地過濾，把 query 直接送出一個 search 事件。

這裡有一個設計上的取捨我想特別講：這三塊我全部走事件，由外部控制。Select 自己不發請求、不管分頁、不知道你的 API 長什麼樣。

為什麼？

因為只要我在元件裡面決定「怎麼打 API」，我就等於決定了所有使用者的資料層長什麼樣。

而那件事，我沒有資格幫他們決定。

另外，加了遠端之後多出來的只有功能嗎？不只，是「狀態」。v7 只有「沒選項」跟「沒結果」兩種，v8 要再加上載入中、請先輸入、底部載入中。而狀態這種東西每多一種，你的 UI 就多一個要處理的分支。

——

八版之間唯一沒變的，是那一行 import

Select 八個版本各自解掉什麼問題，又順便欠下什麼債 v1 v2 v3 v4 v5 v6 v7 v8 包一層原生 select，行為全白嫖改成 div，長相終於我說了算 Portal 到 body，不再被切掉鍵盤、焦點、ARIA 補回來拆成 composables，面板會翻面打字就過濾，支援拼音多選、chips、Backspace 拔標籤遠端搜尋、無限滾動、虛擬列表 ↳ 外觀完全動不了 ↳ 埋了 overflow 跟鍵盤兩顆雷 ↳ 捲動與縮放要自己追座標 ↳ 單一檔案膨脹到500行 ↳ 這一版是在還債，沒欠新的 ↳ 拼音字典 1MB，所有人一起揹 ↳ 狀態組合開始變多 ↳ 載入中／空／錯誤，分支爆增

上排是這一版解掉的問題，下排是它順手欠下的債。八個版本裡沒有一版是純粹「加功能」——每一版都在還前一版留下的帳。

回頭看一次，然後是那一行小字：

每一版對前一版都相容。import 從 @vN 改成 @vN+1，就這樣而已。

八版裡面，我把底層從原生 select 換成 div、把面板搬去 body、把單一檔案拆成九個。內部幾乎沒有一塊是原封不動的。

但對使用者來說，八版之間換版本，就是改一行 import。

這件事不是自然發生的，是我每一版都刻意守住的規矩。

難在哪？難在每次想抄近路的時候忍住——反正只有我在用，改一下 prop 名稱又不會怎樣。

會怎樣。那就是破壞性變更，只是暫時沒人來跟你收帳而已。

內部怎麼長，是我的自由；外部看到什麼，是我的承諾。

——

「能用」跟「能給別人用」，中間隔著出口設計

v8 跑得起來，是因為它跑在我自己的 dev server 裡。我手上有原始碼，還有我的建置環境。

使用者只拿得到產物。

所以差別在哪？

不是「多打一個 build 指令」，是整包責任移到我這邊來了。編譯原本是他家的事，現在變成我的事。樣式沒有模組邊界，它就是會跟他的專案攪在一起。我裝的每一個東西，最後都變成他的負擔。

依賴這一刀要最先砍，判斷標準我後來想出一句話：這東西有沒有「身分」。

只要同時存在兩份就會出事的，一律交給宿主提供。框架本身、狀態容器、任何有全域註冊表的東西，都算這一類。Vue 是最典型的，provide 跟 inject 靠的是模組層級的識別、響應式代理不互通、元件實例對不上。

這不是體積問題，是正確性問題。兩份 Vue 不會報錯給你看，它只會行為很詭異——inject 拿不到、watch 不觸發、明明你看程式碼就是對的，但它就是不動。

而且超難查。

純工具是另一種性質，它可以跟著走，但代價要自己算。這顆 Select 為了中文搜尋用了 pinyin-pro，它揹著一份拼音字典，安裝體積大概1MB，而且字典這種資料，tree-shaking 幾乎搖不掉。

所以現在的狀況是：一個「打拼音也能搜」的方便功能，讓所有人一起付這個成本。包含那個只想要一顆單選下拉、根本沒開 filterable 的人。

那做成可選依賴不就好了？可以啊，路其實有好幾條——開放讓使用者自己注入比對函式，或者拆成獨立入口都行。但真正要決定的問題是：預設要不要幫使用者做主。

然後是出口設計，這個我覺得是整段最重要的觀念。

出口設計不是「讓人 import 得到」，是「決定哪些東西以後不能亂改」。

沒開的路徑，使用者進不去。這條限制聽起來像是在限制別人，但其實它是在保護我，保護我以後還敢重構。

反過來也一樣，而且這句更重要：只要有人深入 import 到你的內部檔案，而且真的能用，那條路徑就變成事實上的公開 API。你以後改它，就是破壞性變更。就算你從來沒承諾過。

這顆 Select 實際上的切法是，v8 對外只開一個 Select 元件跟四個型別，六個 composables 全部關在裡面。

沒有標準答案。但要在發佈前決定。

不是等別人用了才決定——那時候就不是你決定了。

至於樣式，那是元件庫最難交出去的一塊，原因很簡單：JS 有模組邊界，CSS 沒有。這顆 Select 八個子元件全部 scoped，樣式不外洩，很好，但這也代表使用者的覆寫進不來，他只能靠權重硬壓。

scoped 是「防止外洩」，不是「提供客製化」。這兩件事很容易被混為一談，但使用者最後一定會想改樣式。一定會。

而且更麻煩的是，哪些東西一被覆寫，就變成 API。class 命名，只要有人拿去覆寫，它就跟 props 一樣是公開介面。DOM 巢狀結構也一樣，人家的選擇器就是照著它寫的，你把一層 div 拿掉，他的樣式就爛了。

也許有人會說，那把可以調的收斂成 CSS 變數不就好了？對，那確實是比較可控的做法——把它當成一個明確、有限、而且可以承諾的樣式介面。但這件事也得在發佈前決定，設計一套 UI 元件庫裡講的那些取捨，最後全部會回到同一個問題：你到底承諾了什麼。

老實說，誠實版是這樣的：這顆 Select 對外入口只開到 v1，Vue 還掛在一般依賴、應該宣告成 peer，pinyin-pro 無條件跟著走，樣式沒有對外的 CSS 變數介面，沒有測試也沒有 CI。

而且，根本還沒真的發佈過。

把還沒做的講出來，比假裝做完有用得多。

——

所以路還有多長？我排完自己嚇一跳

八版只是把「一顆能用的下拉選單」做出來而已。

我後來把還沒做的東西排了一次，一樣照原本的規矩，一版只解一件當時最痛的事。

排完是從 v9 到 v19。

後面這一排，比前面八版加起來還多。

下面這些我一版都還沒動，所以請當成路線圖看，不是成果。

v9 到 v19 的路線圖，依主題分成四組，全部都還沒開始動把「能用」補成「好用」 v9 選項開 slots、要能分組 v10 清空、全選、上限、拖曳排序 v11 重試、請求打架、id 回填 v12 name、FormData、required 我預設的那個使用者不存在 v13 輸入法組字中不能送出去查 v14 手機該換成 bottom sheet 同一份程式碼，長得不一樣 v15 Safari／Firefox 各有各的坑 v16 捲軸、字型、修飾鍵、報讀器 v17 深色、高對比、動效、RTL 交出去之前 v18 SSR：何時才能碰 DOM v19 測試、CI，然後真的發佈

v9 到 v19 我一版都還沒動，所以這是路線圖，不是成果。中間那兩組——輸入法、手機、瀏覽器、作業系統、無障礙偏好——講的都是同一件事：我前面十二版預設的那個使用者，其實不存在。

——

v9 到 v12：把「能用」補成「好用」

v9，選項長什麼樣不該由我決定。 v1 到 v8，一個 option 就是一行字。但真實需求要放 icon、頭像、次要說明、價格、標籤。

那全部開成 prop 不就好了？iconField、avatarField、descField 一個一個加，加到最後那個 API 會醜到我自己都不想看。

所以要開 slots，把選項的長相交出去，順便做分組。

這一版真正的難點不是 slots，是開了 slots 之後，useVirtualList 就不能再假設每一列等高。

v10，輸入的手感。 一鍵清空、打什麼就建什麼、全選反選、選取上限、chips 拖曳排序。這些每一條聽起來都很簡單，但它們全部都會回頭去動 useSelect 的選取邏輯，而那是整顆元件最核心的那塊。

改核心的小功能，比加一個新功能危險得多。

v11，狀態要撐得住。 v8 只證明了「遠端資料接得進來」，沒證明「遠端出事的時候會怎樣」。失敗要能重試。然後是請求打架——你打字很快的時候，前一個請求可能比後一個晚回來，畫面上顯示的就是舊的結果。這個 bug 超級難重現，因為它只在網路慢的時候發生，而你開發的時候網路很快。

怎麼解？每次查詢帶一個序號，回來的時候對不上就丟掉，或者直接 abort 掉前一個。

還有一個很實際的：表單編輯的時候後端只給你 id，你要顯示「王小明」，但手上只有 1024。這一條沒做，所有的編輯頁面都會顯示一串 id。

v12，接回原生表單。 這一版是我最容易忘記的，因為我從頭到尾都活在 Vue 的世界裡，v-model 綁一綁就結束了。但很多專案的表單就是一個 <form>，送出的時候靠瀏覽器自己收集。那我這顆 Select 會被收進去嗎？

不會。它是一堆 div，FormData 完全看不到它。

所以要補 name 屬性、隱藏的原生欄位、required 驗證。還有瀏覽器的自動填入——這個大概是補不回來的，因為 Chrome 的 autofill 只認得原生控制項。

這裡就出現一個很尷尬的事實：v1 那個「最慫」的版本，這一整排全部都是免費的。

——

v13、v14：我預設的那個使用者，根本不存在

從這裡開始，是我最想加進路線圖的那幾版。

因為前面十二版，我都預設使用者是「打英文、用滑鼠、坐在桌機前面、瀏覽器是 Chrome」。

那個人不存在。

v13 是輸入法。 v6 的過濾綁的是 input 事件，每按一個鍵就過濾一次。英文沒問題，中文就爛了。

為什麼？你打「高雄」，注音要按ㄍ、ㄠ、聲調、選字。在你還沒選字之前，input 裡面已經有一串組字中的東西了，而我每一下都拿去查。畫面一直閃，遠端還多送了四五次請求。日文更慘，平假名轉漢字之前那一整段，全部是垃圾 query。

那單純 debounce 不行嗎？畫面閃可以壓下去，但下面那件更嚴重的擋不掉。

所以要接 compositionstart 跟 compositionend，組字中先把過濾停掉。但這裡有個坑——Safari 跟 Chrome 的 compositionend 跟 input 事件順序不一樣，Android 上有些輸入法根本不丟 composition 事件，所以你還是得加一層 debounce 兜底。

還有一件更嚴重的事：組字中不能吃掉 Enter 跟方向鍵。你在選字的時候按 Enter，那是「確認選字」，不是「選走這個選項」。你在候選字之間按方向鍵，那是「換一個候選字」，不是「移動高亮」。

這個沒處理，中文使用者每選一次字就誤選一個選項。

老實說這是整趟裡我覺得最能代表問題的一版——這個 bug，你用英文測一輩子都測不出來。

v14 是手機。 本來我以為就是 RWD，把寬度調一調。

不是。那差在哪？

沒有 hover。手機沒有滑鼠指標，但 :hover 在觸控之後會黏在那一項上，你點完一個選項，它就一直亮著。所以 hover 樣式要包在 @media (hover: hover) and (pointer: fine) 裡面。點擊區也太小，桌機一列32px 很合理，手指要40px 以上——這不是好看不好看，是點不點得到。

然後是虛擬鍵盤，這個最麻煩。搜尋框一 focus，鍵盤彈出來，可視範圍剩下一半。那面板會自己讓開嗎？不會——window.innerHeight 在 iOS 上不會變，所以我算出來的面板位置，正好在鍵盤底下。要改用 visualViewport 的高度跟位移重算。

還有 iOS 的自動放大，input 的字級小於16px，一 focus 整頁就會被 Safari 放大。捲動鎖定也是，overflow: hidden 在 iOS Safari 擋不住橡皮筋。

寫到這裡我得誠實講一句：手機上其實不該用同一顆浮層，應該整個換成從底部升上來的 bottom sheet。

那已經不是 RWD 了，是兩種互動模型。

——

v15 到 v17：同一份程式碼，在不同的機器上長得不一樣

v15，瀏覽器差異。 這一版之前，我對「跨瀏覽器」的印象還停在「加個 prefix 就好」。

實際排下來不是這樣。Safari 有一批東西的時程跟別人不一樣，:focus-visible、inert、popover、anchor positioning，每一個支援的時間點都不同，所以你得 feature detect，而且兩條路都要維護。

Firefox 完全不吃 ::-webkit-scrollbar，你在 Chrome 調好的細捲軸到 Firefox 是粗的，面板的內容寬度就差了一截，文字提早斷行。Firefox 還有一個 scroll anchoring，它會在你 append 新選項的時候「好心」幫你維持視覺位置，而我的無限滾動自己也在算捲動位置，兩邊打架，畫面就跳。怎麼擋？overflow-anchor: none 關掉。

Chrome 在 Windows 125% 縮放下，getBoundingClientRect 回傳的是小數，你直接拿去設 left，面板會抖1px。要不要四捨五入？round 了，在某些縮放比例下又會差1px 對不齊。

這一整版沒有一個「聰明的解法」。就是一條一條列出來，一條一條測。

v16，作業系統差異。 Windows 是佔位捲軸，Mac 預設是浮在上面的 overlay 捲軸，所以同一個面板，Windows 上的內容區就是窄一截。字型也是，同一份 label，Windows 上是微軟正黑，Mac 上是蘋方，寬度不一樣——你在 Mac 上量好的「最長選項寬度」，到 Windows 就爆行。

這件事設計師通常不會知道，因為他的 Figma 只有一種字型。

那面板寬度寫死不就好了？不行，只能跟 trigger 對齊，或者當場量。

修飾鍵也是。Mac 沒有獨立的 Home 跟 End，我 v4 只綁了 Home 跟 End，Mac 使用者根本按不到。而且 Mac 的原生 select 是 Option 加上下開合的，你要不要跟？跟了 Windows 使用者不懂，不跟 Mac 使用者覺得怪。

然後是螢幕閱讀器，這個最難。VoiceOver 配 Safari、NVDA 配 Firefox、JAWS 配 Chrome，是三組不同的組合，同一份 ARIA 三邊讀出來的東西不一樣。aria-activedescendant 的支援一直很微妙，所以有人乾脆改用 roving tabindex，真的把焦點移到 option 上——但那又跟 combobox 的 pattern 打架。

這一版我得先講清楚：它做不完。因為驗收條件不是 CI 綠燈，是三種螢幕閱讀器實際聽過一遍，而我手上只有一台 Mac。

v17，使用者的偏好，不是你的偏好。 深色模式要收在變數層，一次換完，不該讓每個子元件自己判斷。Windows 高對比模式我以前完全不知道——forced-colors 一開，你的背景色、陰影全部被系統蓋掉，所以「靠背景色表示選中」這種設計，在高對比模式下是完全看不出來的。prefers-reduced-motion 要能關掉展開動畫，這不是體貼，是有人看了會頭暈。RTL 的時候面板要靠右、箭頭要翻邊。

這四條有一個共同點：它們都不會出現在你的 bug 回報單裡。

因為需要它們的人，通常一開始就放棄用你的產品了。

——

v18、v19：SSR、測試，然後真的發佈出去

SSR 這件事本身不難。面板走 Portal 送到 body，但 server 上根本沒有 body，所以 teleport 得等到 onMounted 之後，不然 hydration 直接對不起來。元件的 id 要穩定，不然 server 產一組、client 產一組，aria-controls 就指到空氣去了。所有的量測——座標、剩餘空間、字寬——全部只能在 client 做。

那難在哪？難在它逼你把「什麼時候可以碰 DOM」這條線，重新畫一次。

到 v19 才輪到測試。composables 各自寫單元測試，互動測試全程走鍵盤，視覺回歸靠 Storybook 截圖比對——而且要跨瀏覽器截，不然 v15 那一版白做。無障礙掛 axe 做自動檢測。然後 CI 擋住型別、lint、測試、產物大小，最後才是發佈。

但我想講的是——CI 全綠就代表沒問題了嗎？

只代表「我沒改壞」。

擋不住「我從來沒想到」。

v13 那個輸入法的坑，沒有任何一條 CI 規則會提醒你。它只會在某一天，被一個用注音的使用者回報成「搜尋很怪」。

——

走完這一趟，我才看懂別人為什麼那樣寫

以前我看到面板 teleport 到 body，心裡想「幹嘛這麼麻煩」。自己做過才知道，不然一定被 overflow: hidden 切掉。

以前我看到一整排 aria 屬性，心裡想「這有人在用嗎」。自己做過才知道，那是原生 select 免費送的，你自己做就得全補。

以前我看到定位算式又臭又長，心裡想「過度工程吧」。自己做過才知道，面板貼底要翻面，還要把高度夾住。

還有幾條，我連做都還沒做，光是把它排進待辦就懂了。

以前我看到一堆 compositionstart、compositionend，心裡想「這是在防什麼」。防的是中文使用者每選一次字，就誤選一個選項。

以前我看到 hover 樣式被包在 @media (hover: hover) 裡面，心裡想「有必要嗎」。有必要，不然手機上點完一個選項，它就一直亮在那裡。

以前我看到樣式檔裡有 forced-colors 那一段，心裡想「這誰在用」。用的是開高對比模式的人，而你「靠背景色表示選中」的設計，他完全看不出來。

所以每一版的複雜度，都不是設計者愛炫技。

是被真實情境逼出來的。

那些「看起來很囉嗦」的設計，其實每一行都在還債。

那 Element Plus 那些憑什麼敢說自己做完了？

這就是我對現成元件庫改觀最大的地方——它們不是多做了什麼炫技的東西，它們是把這一整排，全部做完了。而且不是因為它們比較聰明，是因為那些問題早就有人回報過了。

我以前寫過元件真的別亂自己刻，當時列的坑我以為自己夠清楚了。排完 v19 才知道，那篇還算客氣的。

也許有人會說，那你幹嘛不直接用 Headless UI、Radix Vue 或 Floating UI？如果是要出貨，我一定用。這趟的目的就是要自己踩，所以刻意不用。而且踩完之後我才真的看得懂 Floating UI 的 API 為什麼長那樣——middleware、flip、shift、size，每一個都對應到我 v5 那版在解的問題。

——

那八版的前提，你上班的時候一個都沒有

寫到這裡其實可以結束了。

但還沒。

因為上面那八版，是重構最爽的狀況。而後面那十一版能不能排得那麼乾淨，也是同一個原因。

不是因為我做得好，是因為條件全部被我調到最寬鬆。

只有我一個人，不用溝通，也不用排隊等 review。沒有使用者，想改就改。沒有期限，不跟任何需求搶排程。範圍我自己畫，就一顆 Select。舊版可以留著，八份並存，誰也不礙著誰。

那真實專案裡的條件呢？

幾十個人同時在改同一份程式碼。有人正在線上用，壞掉那叫事故，不叫 bug。重構要跟功能需求搶同一批人。範圍不是你畫的，是耦合關係替你決定的。舊的不能留，留著就是兩套都要養。

所以難的從來不是「怎麼寫比較好」。

那部分我上面已經講完了。

——

重構的成本，從來不在程式碼

改動本身可能兩天就好。但那兩天根本不是瓶頸。

認知成本：沒有人握有全貌。寫的人早就走了，文件停在兩年前，真正的規格躲在某一段 if 裡面。所以你得先花好幾週搞懂「現在是什麼」，才有資格決定「應該變成什麼」。

協調成本：你動的每一個介面，後面都掛著別人的排程。改一個共用元件的 props，牽動的不是幾個檔案，是好幾個團隊這一季的計畫。而技術決策只要得跨組同意，速度就由最慢的那組決定。

信任成本：上一次重構做到一半就沒下文了，所以這次沒人相信你會做完。這一項最貴，而且是繼承來的——你什麼都還沒做錯，就已經先欠著。

不公平嗎？非常不公平。但那就是你要處理的現實。

還有一個我覺得是一個人重構跟一群人重構最本質的差別：你在打一個會動的靶。

你在搬舊架構的同時，另外二十個人正在繼續往舊架構加東西。於是你的分支越開越久，而 merge 的代價是隨著時間非線性成長的。到後來，你改 code 的時間，還比不上解衝突的時間。

那怎麼辦？為了閃衝突，你改成「新的寫旁邊」。

好，現在專案裡有兩套。

然後中途被更急的需求打斷，這兩套就此定居。下一個人來了，看不懂這兩套哪個是對的。

他開第三套。

所以重構最大的風險，不是做壞。

是做不完。

而且半套架構比原本更糟，因為現在你要同時懂兩套，還要知道哪個檔案屬於哪一套。

——

聽起來超對、但一定會失敗的四句話

這四句我自己都說過。

「先做一個新版，做好再切過去。」為什麼失敗？因為平行世界永遠追不上，舊的還在長新功能。

「以後大家都用新寫法就好。」口頭約定沒有強制力，新人只會照旁邊的檔案抄。

「等這波需求忙完就來重構。」那一波不會結束，它只會換一個名字。

「一次全部換掉，長痛不如短痛。」只有成功跟 rollback 兩種結局，中間沒有地方可以喘。

它們的共同點是什麼？

都假設「有一段完整的時間」可以用。

而大型專案不會給你那段時間。

——

換一種形狀：假設你隨時會被打斷

我要先講清楚，這不是叫你更努力。是換一種形狀，讓它被打斷了也還是有價值。

什麼叫被打斷也還是有價值？兩件事。

一邊是讓它可以隨時停。先立邊界，再搬東西——新的介面先立起來，舊實作留在後面，再一塊一塊換掉，每一步都能上線、能回滾，不要養長命分支。先補特徵測試把現況的行為鎖住，再改結構，注意，不是為了品質，是為了讓你敢動。還有，把重構掛在需求上，碰到哪裡就改哪裡，不要另外去要排程。

另一邊是讓它不會退回去。「不要再往舊的加」，這句話要變成機器規則，lint、codemod、CI 擋著，不能只是嘴上說說。新舊共存一定要寫下到期日跟刪除條件，不然「暫時」就是永久。決策要留字，因為做到一半人一定會換。

最後，進度要看得見。還剩幾個呼叫點沒搬，貼在牆上——這是唯一能對非工程師交代的東西，也是怎麼把一次重構賣出去的關鍵。

核心就一句：假設你隨時會被打斷，然後設計一個被打斷也不虧的走法。

——

所以回到最前面。

一顆下拉選單重寫八次，後面還排著十一版沒動，聽起來像是一個很閒的人在做的事。

但我真正想講的是這個：選型錯誤的代價，在一個人身上是一個週末，在大型團隊，是以年計算。

我的建議不是「別造輪子」，是換個順序造：先去讀別人的輪子，再自己做一次，而且不用做完，做到痛點冒出來就夠了。我做八版是因為我想講一場簡報，你做到 v4 大概就夠痛了。然後回頭再讀一次。

造輪子最大的收穫，從來不是那顆輪子。

是下次選型的時候，你問得出來的問題不一樣了。面板 Portal 出去了嗎、鍵盤跟 ARIA 補到什麼程度、幾千筆會不會爆、樣式要怎麼覆寫、它把哪些東西當成公開 API。

輸入法擋了嗎、手機上是浮層還是 bottom sheet、Windows 上捲軸會不會把面板擠窄、高對比模式下看不看得出哪一項被選中。

我覺得會問這幾個問題，比知道答案更有價值。

一個人的重構，難在技術。一群人的重構，難在讓所有人同時往同一個方向走一小步。

那你們家那個「等忙完就來重構」的東西，忙完了嗎？

（實驗性，本篇文章是 AI 產生）

Vibe Coding 做得出 95 分的產品，缺的 5 分全是最貴的

竹子日誌（竹子） — Fri, 21 Aug 2026 01:10:00 GMT

最近「壹加壹」做的字幕服務 What’Sub 在社群上吵了好幾天。

一個瀏覽器端的 AI 字幕工具，聽打、斷句、對時間、上樣式、匯出全包，主打「影片留在你的電腦」。

老實說，我對評判他對還是錯完全沒興趣，甚至有點看笑話的心情在看整件事。我本來以為這種話題燒個兩天就差不多了，結果一波接一波，到現在還沒停。

想想，那我也來蹭一下好了。

但我不打算蹭立場，我打算蹭原始碼。因為這東西的核心引擎，做的事情比我看過的很多「正規團隊產品」都還要底層。稱讚的、貶低的，各路人馬都想插一句，那我就用一個前端工程師的身分，把它整個掀開來看。

前端沒有秘密。你送到瀏覽器的東西，我全部看得到。

——

它不是 demo，是真的在賣東西

很多 Vibe Coding 出來的東西，都停在「你看我做得出來」。

這個不是。

它有串金流、有訂閱制、有月繳年繳、有加購包、有推薦碼、有電子發票、有統編查詢、有自動續訂、有錢包、有訂單、有重寄發票。金流那條線是完整跑通的，不是接個 Stripe demo 就自以為收工。它甚至有後台、有管理者中心，一整套系統都在。

SEO 那邊，八個行銷頁全部靜態預渲染，每一頁的 title、description、canonical 都是手寫的，不是模板套出來的。七個內容頁每頁三組 JSON-LD。長尾意圖頁也分得很清楚——/fcpxml/ 打「SRT 轉 FCPXML」，/compare/ 直接打競品比較。

還有 llms.txt。會在 2026 年主動放 llms.txt 的台灣 SaaS，我一隻手數得完。

這已經不是「工程師做了個 side project」，這是有人在認真經營一門生意。

這就是我一直在講的，功能做出來只是一句話，難的從來是做出來之後的那些事。而這個人把「之後」也做了。

產品先落地再說。我覺得這才是 AI 時代該有的態度。

——

UI/UX 的細節意識，高到不像一個人做的

prefers-reduced-motion 在 CSS 裡出現 26 個區塊。

26 個。

多語系文字用 <bdi> 包起來，避免雙向文字排版爆掉。實驗性 CSS 全部包在 @supports 裡，不支援的瀏覽器不會把內容留在 opacity: 0 變成一片空白。

圖片是教科書等級：<picture> 配 WebP／JPG 雙格式、四種 aspect-ratio 斷點、srcset 跟 sizes 都給好，裝飾圖 alt=""，loading="lazy" 跟 fetchpriority="high" 分工正確。

錯誤訊息全部是中文口語。不是「Error: decode failed」，是「抽出聲音太久沒有進度（檔案可能太大或格式太特殊）」。

還有這種：

這支瀏覽器沒辦法邊燒邊存進硬碟，用 Chrome 或 Edge 開同一個專案輸出，成品直接落地、不受大小限制

這句話寫得比很多產品的 PM 都好。它告訴你發生什麼事、為什麼、然後怎麼辦。三件事一句講完。

——

三個自製引擎，一個 byte 都沒解碼

這是我最熟悉的一塊，也是我看得最久的一塊。

它用 React 19。沒有 router、沒有 state manager、沒有 UI Library、沒有 CSS framework，幾乎你想得到的，都沒有。

Router 是 popstate 加 regex 手刻的。Store 是三個手寫的 external store 配 useSyncExternalStore。Tooltip、Toast、Modal 全部手刻。編輯器的文字覆蓋層甚至直接繞過 React，用 replaceChildren() 加 getBoundingClientRect() 手算絕對定位硬畫。

React 在這裡只是一個渲染層。真正的重量壓在瀏覽器原生能力上。

然後是三個自製引擎。這三個我拆開講，也順便把可以自己去查的原始文件附上——因為這些東西根本不是什麼黑魔法，只是很少人願意去讀規格書而已。

抽離音訊：手刻 MP4 Parser，只讀那幾段 byte

先講一般人會怎麼做：整支影片丟進 ffmpeg.wasm，解碼、抽音軌、重新編碼，然後等它跑完。10 GB 就是 10 GB 全部讀進來。

它不是這樣做的。

你可以把 MP4 想成一個櫃子。櫃子裡有很多抽屜（規格書叫 box 或 atom），每個抽屜有名字、有大小。ftyp 抽屜寫著「我是什麼格式」，mdat 抽屜裝著真正的影音資料，而 moov 抽屜裝的是一份目錄——哪一段聲音、哪一格畫面，分別放在檔案的第幾個 byte、長度多少，全部寫在裡面。

想知道這個櫃子長什麼樣，MDN 的 Media container formats 是最好讀的入門；要看正式定義，就翻 W3C 的 ISO BMFF Byte Stream Format。

所以它做的事情是這樣：

先用 File.slice() 只切出檔案開頭那一小段，手刻 parser 走 moov > trak > mdia > minf > stbl，把目錄讀出來。有了目錄，它就知道每一個 AAC packet 躺在第幾個 byte。接著它量測這台機器的 I/O latency 跟 throughput，用一個成本模型算「跳著讀划不划算」——因為硬碟每跳一次都有成本，兩段離很近的資料，一次讀完反而比跳兩次快。算完之後只讀那幾段 byte range，最後手工組一個合法的 .m4a 出來。

File.slice() 這件事本身一點都不神祕，MDN 上就一頁，它還是 lazy 的——你切了不代表你讀了，真的要讀還得去 arrayBuffer()。神祕的是有人願意為了它去讀 MP4 規格書。

先讀 moov 取得樣本索引，再依索引只讀取 mdat 裡的少數幾段位元組一支 10 GB 的 MP4 檔案 ftyp moov mdat ① 只讀開頭，拿到樣本索引 ② 依索引跳著讀那幾段 byte 每個 packet 在第幾個 byte、多長再手工組成一個合法的 .m4a，實際讀不到 100 MB 全程沒有解碼任何一個 byte

綠色那五小段就是實際被讀進來的資料。先讀 moov 拿到「東西放在哪」的目錄，剩下的就只是精準取件——10 GB 的影片，讀不到 100 MB 就生得出音檔。

一支 10 GB 的影片，可能只讀了 80 MB 就生出音檔。

然後是 PCM 分支，這段我看了兩次才看懂。

AAC 這個格式有一個很討厭的特性：編碼器會在開頭偷偷塞幾幀靜音進去，這叫 encoder delay，也叫 priming。所以你把一段聲音編碼再解碼回來，它會比原本晚一點點。晚多少？看編碼器的實作，每台機器可能都不一樣。

它的解法是：用 LCG 產生 0.3 秒的確定性白噪音（確定性的意思是同一個種子每次都長一模一樣，才能拿來當比對基準），丟去 AAC 編碼再解碼，然後對這兩段訊號做互相關，掃描 lag 0 到 4600，看往後推幾格會最像。推幾格最像，就代表這台電腦的編碼器 priming 了幾幀。

量出來之後，把這個值寫進 MP4 的 edit list，播放的時候就會自動把前面那段多出來的靜音切掉。

AAC 編碼在開頭多出一段靜音，量出 lag 後用 edit list 對齊回原位時間 0 原始訊號編碼再解碼靜音 ← priming 幾幀，就是 lag 幾幀互相關掃描 lag 0～4600，量出偏移量後寫進 edit list，播放時自動切掉前面那段靜音

編碼器在開頭塞了一段誰也沒要求的靜音，聲音就整條往後挪。互相關的工作就是量出「挪了多少」，edit list 再把它挪回來——字幕跟聲音對不對得上，差別就在這幾十毫秒。

priming 這件事不是它發明的。Apple 的 QuickTime File Format 文件裡有一整個附錄在講 AAC audio priming 跟 edit list 怎麼配合，這份文件躺在那裡很多年了。

差別在於：大部分人選擇假裝沒這回事，然後字幕跟聲音差個幾十毫秒。

分鏡偵測：把 32 格畫成一張拼圖，只讀一次

白話版：要偵測分鏡，就是把畫面一格一格拿出來比，看哪一格跟前一格差很多。

問題在「拿出來」這個動作。

它用 VideoDecoder 硬解，這是 WebCodecs 的 API，等於直接把瀏覽器底層的解碼器開給你用，規格在 W3C。它也不是每一格都解，是從關鍵幀 seek——關鍵幀就是 EncodedVideoChunk 的 type 為 key 的那些，它們不依賴前後幀，可以獨立解出來。

解出來的畫面在 GPU 上。但你要比對像素，就得把它搬回 CPU，這個動作叫 getImageData。

這一搬就是一次 readback stall——GPU 手上正在跑的東西要先停下來，等資料交接完才能繼續。搬一次不貴，搬 32 次就很貴。

所以它每格縮成 64×36，畫進一張 8×4 的拼圖，湊滿 32 格才呼叫一次 getImageData。

32 次停頓，變成 1 次。

每幀各讀一次會造成 32 次 GPU 停頓，先畫進 8×4 拼圖則只需讀一次每一幀各讀一次 ⋯⋯ 32 次 GPU→CPU 停頓每讀一次，GPU 就要停下來等資料交接先畫進 8×4 拼圖 getImageData × 1 32 幀縮成一張圖，只停 1 次

上面那排短豎線每一根都是一次 GPU 停頓。把 32 格縮小拼成一張圖再一次讀回來，停頓次數從 32 降到 1。同樣的資料量，差別只在來回跑了幾趟。

還有一個細節我很喜歡。

這種一直在跑的迴圈會把主執行緒佔滿，畫面就會卡。一般人會用 setTimeout(0) 讓出控制權，但 setTimeout 有最小 4 毫秒的 clamping，讓一次就白白浪費 4 毫秒。它改用 MessageChannel 當 macrotask yield，postMessage 一發一收就換到下一個 task，沒有那 4 毫秒。

這是老前端的偏方，但現在有更正規的做法了。web.dev 的 Optimize long tasks 把各種讓出控制權的手法整理得很清楚，包含新的 scheduler.yield()。

音訊切割：把工作丟到音訊執行緒

第三個引擎最短，但概念最值得初階工程師學起來。

瀏覽器的 JS 預設全部擠在主執行緒上。你的 React 在跑、使用者在捲動、順便還要切音檔——主執行緒一卡，畫面掉幀，聲音也會爆音。

AudioWorklet 就是為了這件事存在的。它讓你把一小段處理程式碼丟到音訊執行緒上跑，那條執行緒每 128 個 frame 就準時呼叫你一次，完全不管主執行緒在忙什麼。

它自己寫了一個 AudioWorklet processor，然後用 Blob URL 動態 addModule() 注入——不用另外開一支實體檔案，字串直接變成模組。

主執行緒被長任務卡住，音訊執行緒上的 AudioWorklet 仍然準時執行主執行緒（UI／React）中間那塊長任務一卡住，UI 就掉幀音訊執行緒（AudioWorklet）每 128 個 frame 準時被呼叫一次，主執行緒再忙也影響不到它

上面那條時而擁擠時而空白的是主執行緒，下面那排整齊的方塊是音訊執行緒。同一份工作放錯執行緒，使用者聽到的就是爆音。

Chrome 團隊的 Audio Worklet is now available by default 那篇是我看過講得最白話的，想入門就從那篇開始。

到處都是成本模型、能力探測、斷言檢查、多層 fallback。裝置還會分級——用 hardwareConcurrency 跟 deviceMemory 分成 strong／ok／weak，ETA 係數各給 0.8／1.5／3。

這種東西不是「叫 AI 弄一弄」弄得出來的。這是有人清楚知道自己要什麼，然後用 AI 把它敲出來。這叫 Domain Knowledge，作者對這個領域很熟。

順帶一提，前端沒有任何一個自己寫的 dangerouslySetInnerHTML 或 innerHTML=，掃到的 12 個全部是 React 內部的，沒有可利用的 XSS sink。這點意外做得蠻結實。

後端能看到的有限，但也很有趣。24 個 /api/* 端點，每支一個 handler，內部用 ?op= 分流，不帶 op 就回 404 unknown op。授權邊界一致：匿名打過去全部 401 請先登入，拿合法但非管理員的 token 打 /api/admin 是 403 沒有管理權限。權限分級是真的落在後端，不是靠前端不顯示按鈕。

錯誤訊息很克制，沒有 stack trace、沒有框架版本、沒有 DB 錯誤、沒有內部路徑。外部 host 只有 6 個：Google 登入、藍新金流、gtag、Google Fonts、YouTube。沒有 Sentry、沒有 LogRocket、沒有一堆第三方追蹤。

蠻乾淨的⋯⋯？

——

但這個站沒有架構，這是暴力

好，說好用前端工程師的立場看，我當然要講講另一半。

整個站是「手刻靜態 HTML」硬接上「一顆 1.1 MB 的 React SPA」。就是這麼簡單。

行銷頁零框架、inline CSS、inline JS，全部寫死在 HTML 裡。/studio 則是一個 SPA 大禮包。兩邊為了共用一張價格表，寫了一個 Web Component，然後同一份 code 打包兩次，一份給靜態頁，一份內嵌進去給 SPA。

手刻靜態行銷頁與 1.1 MB SPA 兩套世界，中間只共用一個價格表元件 8 個手刻靜態行銷頁 /studio：1.1 MB SPA 零框架 inline CSS + inline JS meta 與 JSON-LD 手寫手刻 Router 3 個手寫 Store 3 個自製引擎全手刻 UI 元件全部塞在同一顆檔案價格表 Web Component 同一份 code，打包兩次

左右是兩個世界，中間唯一共用的只有一張價格表——同一份 code 打包兩次，兩邊各拿一份。

聰明嗎？聰明。

但這是「解決方案」還是「繞過問題」？

沒有 Router Library，所以自己刻。沒有 State Manager，所以自己刻。沒有 UI Library，所以眼睛看到的 UI 全部自己刻。

每一個都刻得很好。

但刻的是輪子，特大號的輪子。Edge Case 覆蓋不全，認真去抓一定抓得到問題。UI 元件的成熟度是時間淬煉出來的，不是 AI 小抄一下就能補足。

一顆 1.1 MB 的大禮包，三個自製引擎、一個手刻 Router、三個手刻 Store，全部塞在同一顆檔案裡。沒有模組化、沒有分層、沒有切分的規劃。

它能動。它動得很好。但它真的就是一整塊。

——

`body { min-width: 1024px }`，手機直接放棄

這一點我原本以為是我誤會。

直到我在 app.css 裡看到這一行：

body {
  min-width: 1024px;
}

<meta name="viewport" content="width=device-width"> 是有寫的。

然後 body 給了一個 1024px 的硬地板。

意思是任何小於 1024px 的視窗，整頁橫向捲，直接放棄手機。

再多拉扯一下還可以找到噴掉的版面，原因也很單純：Layout 規劃跟元件設計本身有問題，最基本的 Flex 那些要處理的小東西未必有處理好。當然我也沒什麼資格說，這些東西連人類前端也常常沒好好處理就是了，RWD 從來就不是靠腦補。

——

全押新潮 API，但你的終端不一定買單

VideoDecoder、VideoEncoder、AudioEncoder、AudioWorklet、OffscreenCanvas、OPFS、showOpenFilePicker、Intl.Segmenter、Web Components、CSS Houdini 的 CSS.registerProperty、animation-timeline: view()⋯⋯

每一個我都很喜歡。

但你把整個產品壓在上面，就要面對現實。

程式碼自己就承認了：

if (/^((?!chrome|crios|android).)*safari/i.test(ua)) useOpfs = false;

Safari 直接 UA sniffing 踢掉，不給用 OPFS。

旁邊明明就有一整套 isConfigSupported() 的能力偵測機制，這裡卻用了最原始的 User Agent 判斷。意思是哪天 Safari 修好了，這個站也不會自動受惠，因為它根本沒在問。

showOpenFilePicker 是 Chromium 限定，Firefox 跟 Safari 都沒有。所以才會有那句「用 Chrome 或 Edge 開同一個專案輸出」。說白了就是不考慮 polyfill，我就是 Chromium Only，我就是放棄那些不用 Chromium 的所有客戶。

還有一顆 31 MB 的 ffmpeg.wasm。在能跑的機器上，它什麼都解得動。在不能跑的機器上，使用者要先下載 31 MB，然後慢慢磨。

它的能力檢查做得很完整（WebAssembly、Worker、AudioContext、fetch + ReadableStream 都是必要，codec 探測還加 6 秒 race timeout），這點我給分。

但最後的結果，往往就是「你這台電腦我跑不動喔～」。

還有字體。游標滑過去換一個字重，就跟 Google Fonts 要一次，光是把首頁滑完，字體請求就沒停過。

——

桌子擺好、椅子排好，然後沒有菜

它主打支援很多語言的字幕辨識，這是真的。但那是辨識模型的能力，跟前端一點關係都沒有。

多語系是一個天坑，我接過 28 種語系的專案，非常多細節可以講。

沒有語系檔、沒有翻譯層、沒有 key、沒有 fallback locale。全部寫死。1,534 條硬寫字串散在各處。

最有趣的是 CSS 裡有這個：

:root:lang(en), :root:lang(de), :root:lang(fr),
:root:lang(es), :root:lang(pt), :root:lang(id) {
  --fs-scale: .94;
  --lh-scale: .9;
}

它連英文、德文、法文、西文、葡文、印尼文的字級跟行高縮放都調好了，排版準備好了。

但沒有任何一個字會變成那些語言。

這就很像⋯⋯桌子擺好、椅子排好、餐具都上了，然後沒有菜。

一個支援 87 種語言辨識、能匯出 FCPXML 的產品，只打算做台灣市場，死釘釘的。

——

前面省 80 MB，後面全部吐回記憶體

它主打「影片留在你的電腦」。留是真的留了，但檔案的生命週期呢？

OPFS 裡有 subtitle-extract.m4a、scenecut/。IndexedDB 開了四個：whatsub-fs-v2、whatsub-fonts-v1、audiocache、draftstore。

然後我去找清除機制。

deleteDatabase 0 次。evict 0 次。cleanup 0 次。removeEntry 5 次，零星的，不是策略。

沒有 TTL、沒有 LRU、沒有容量上限驅逐，登出也不清。

意思是共用電腦的話，下一個人打開 DevTools，就能看到前一個人的草稿跟音檔。

這直接打到「影片留在你的電腦」這個賣點的臉上。「留在我的電腦」，然後「永遠留著」——這是隱私還是負債？

大檔更直接。它的錯誤訊息自己列出了天花板：超過 2 GB 的聲音檔不行，超過 8 小時不行，成品太大「超過瀏覽器記憶體能組裝的上限」，畫面太大「超出這台電腦能處理的範圍」。

最後兩句才是重點。輸出的成品，要在瀏覽器記憶體裡組裝。

抽音只讀取影片的一小段位元組，輸出卻要把整包成品放進記憶體抽音輸出 10 GB 影片，實際只讀約 80 MB 成品整包在記憶體裡組裝，直接撞上天花板記憶體天花板

抽音那端聰明到只讀 80 MB，輸出那端卻要把整包成品塞進記憶體——前面省下來的，後面全部吐回去。

一個做影片工具的產品，處理不了大的影片檔。影音工作者的毛片隨隨便便都是好幾個 G，完全沒辦法處理。

這不是效能問題，這是天花板。

——

沒有架構規劃，未來只能繼續靠 AI

前面幾點其實都指向這一件事。

沒有模組邊界、沒有分層、沒有語系層、沒有響應式策略、沒有清理策略。它的擴充方式就是「再繼續刻下去」，新功能繼續往裡面塞，反正 AI 現場讀現場改。

現在能運作，是因為「寫的人記得所有事情」。因為這是一個一人專案。

那如果哪天要找工程師維護？

他要接手的是：一顆 1.1 MB 的單檔 SPA、1,534 條散在各處的硬寫字串、三個沒有文件的自製 parser、一個手刻 Router、三個手寫 store，還有一個放棄手機的 1024px 無 RWD 架構。

這種東西，人接不了。

只有 AI 接得動——因為 AI 可以一次讀完整份程式碼，不會累，也不會問「這段為什麼要這樣寫」。問題是，你就再也離不開 AI 了。也很難快速增長，更不可能協作配合。

UI Library 手刻，就不要講 Design System 了，它甚至無法規範自己的視覺標準。做到哪、刻到哪，沒有治理跟統一。更別提哪天要上 Dark Mode 的成本，UI 設計師大概只會說「你可以請 AI 調整就好」。

後端也不用說。宣傳影片當下已經 20 萬瀏覽量，轉化率算 1% 就好，2000 人跑去註冊然後上傳？這種程度的流量可以直接搞垮沒有擴張設計的網站。不用故意攻擊，光粉絲進去逛一圈，效果就跟一次 DDoS 差不多。

——

Vibe Coding 缺的那 5 分，剛好全是不好玩的東西

我不是要酸這個站。

相反，我覺得它很了不起。一個人（或極小團隊）用 Vibe Coding 做到這個程度，我看到的是可能性，不是笑話。從商業面到領域知識，從使用者體驗到打磨，一個人能做到這樣，我給 95 分。

但缺的那 5 分，剛好全部是「不好玩但重要」的東西。

工程化、文件化、資訊安全、效能優化⋯⋯

AI 很擅長幫你做爽的那些，但這些看不到商業價值的無聊東西，很理所當然被拋棄。

因為你會去要。你會說「幫我做一個能偵測分鏡的東西」，然後它就給你一個好用、舒服又漂亮的東西。

但你不會半夜三點跳起來說「幫我規劃一下未來三年的模組邊界」，也不會說「幫我檢查這網站資訊安全有沒有遺漏」。

那些事情，要有人「記得要做」才會發生。這也是我之前寫過的解決方案比寫 code 重要——AI 讓「做出來」變得非常便宜，但「做得扎實」還是一樣昂貴。

如果你是個人小創作者，我誠摯推薦你去訂閱使用。它懂你的痛、懂你需要什麼，讓你輕鬆享受剪片最快樂的部分，解決最痛苦的上字幕。

但你說要長期訂閱半年一年？甚至給專業創作者用？我覺得還是要多評估一下，不要一頭熱就訂一年下去。

抱歉，褒貶我各敲五十大板，了解的都知道我講話就是這麼直。

i18n 難的從來不是翻譯，是沒有人擁有那份語系檔

竹子日誌（竹子） — Thu, 20 Aug 2026 02:30:00 GMT

每次講到多語系，大家的第一反應都是「就裝個 i18n 套件，把字串抽出來包成 key，然後丟給翻譯就好了嘛」。

技術上確實是這樣沒錯。

但你只要把團隊規模乘上五倍、語系乘上十倍、專案跑上三到五年，你就會發現這件事從來就不是技術問題。

語系檔最後會變成公司走廊上那張公佈欄：每個人都往上貼，沒有人負責撕。

我大概兩年前寫過一篇最誇張的多語系，那個專案 28 種語系，最要命的是還分成 24 個子 Repo，我當時只覺得噁心。現在回頭看，可怕的其實不是 28 這個數字，是那 28 份檔案背後沒有任何人負責。在 AI Agent 還不那麼好用的年代，改一個詞就是一個下午。

——

多語系的痛，是一層一層往下挖的

先給一張全景，後面五節就照這個順序走。

多語系問題的五層結構，從命名、擁有權、流程、在地化到組織政治，越往下工程能自己解決的比例越低淺深 ① ② ③ ④ ⑤ 命名：key 怎麼取擁有權：這個字是誰的流程：翻譯跟不上 sprint 在地化：複數、長度、語序政治：誰決定、誰執行、誰買單開會、上個 lint 就壓得下來共用要保守，key 要有 owner 功能上線與語系上線解耦每個語系要有當地 reviewer 要有人被指定，而不是順便

第一層開個會、上個 lint 就壓得下來，第五層要動到四個部門的工作習慣。越往下挖，工程能自己解決的比例越低。

——

第一層：key 怎麼取，其實是誰來取

最淺的問題，是 key 要怎麼取。

有人寫 login.button.submit，有人寫 btn_login，有人直接 t('登入') 拿中文當 key，也有人 t('Login') 拿英文當 key。一個人一種流派，幾個人就幾種，全部進到同一個 zh-TW.json。

然後某天你要找「登入」這兩個字在哪裡，全域搜尋出來十四個 key，你不知道哪一個是活的。

直接拿一個語系的值當 key 這件事特別值得講。它一開始爽到不行，不用命名、不用查表、看 code 就知道畫面長怎樣，PM 也看得懂。

但它有兩個必爆的地雷。

第一，文案一改，key 就要跟著改，所有語系檔全部要跟著搬。你只是把「登入」改成「立即登入」，結果 28 份檔案一起動。

第二，同一個詞在不同語境會翻成不同的字。中文的「確定」，在英文可能是 OK、Confirm、Submit、Done。你拿中文當 key，等於在原文層就把語境壓扁了，後面救不回來。

那 nested 還是 flat？其實都可以活，重點不在深度，在切法。

我看過最多人犯的錯，是照「畫面」切 namespace。checkout.step2.dialog.title 這種，看起來很整齊，但畫面會改版，改版之後這棵樹就整個歪掉，然後沒有人願意去搬。

也不少人照前端的檔案結構命名。可是要溝通的時候，PM 看不懂、不是負責那個模組的前端也看不懂，最後只好把原本開發的人拖回來問。檔案一搬遷，名字又要大汰換，動一下改一堆。

比較能撐的切法，是照「誰會改它」切。namespace 的邊界應該對齊團隊邊界、對齊功能的擁有者，UI 結構只拿來輔助命名。

因為語系檔最後就是一個共同編輯的檔案，而共同編輯的檔案，唯一能救它的就是邊界清楚。

這個階段的痛還算便宜，開個會、寫個規範、上個 lint，大概就壓得下來。

——

第二層：多語系的共用，比程式碼的共用更危險

再往下一層，問題變成「這個詞是誰的」。

A 團隊改了 common.confirm，因為他們那頁的語境要更禮貌一點。結果 B 團隊的刪除確認框跟著一起變得很客氣，使用者按下去就把資料刪光了。

common 這個 namespace，是多語系裡面最危險的地方。它看起來很 DRY，實際上是一個沒有主人的公共廁所。

它還會自己長大。一開始只放「確定」「取消」，半年後裡面出現 common.dialog.button.confirm.1，你就知道完蛋了。

我的看法是，i18n 的共用要比程式碼的共用保守很多。

程式碼抽共用，錯了頂多重構；文案抽共用，錯了是使用者直接看到怪東西，而且不會有 compile error 提醒你。

字串重複三次，其實沒關係。真的沒關係。那點重複的成本，遠比一個共用詞誤傷三個團隊便宜。最不需要為了共用而共用的就是 i18n key，能不共用就不要共用。

再來是孤兒 key。

功能下架了，但沒人敢刪那幾行，因為不確定還有沒有人在用。三年後，en.json 裡面有四成是死的，但沒有人有膽子動它。

也許有人會說，這件事可以掃描啊，跑個 static analysis 把沒被引用的 key 撈出來就好了嘛。

問題是動態組 key。

t(`order.status.${statusCode}`)

只要專案裡有這種寫法，你的靜態掃描就直接失效，而且是全域失效。你永遠不知道 order.status.PENDING_REFUND 是不是還有人在用。

這是我心中多語系的天坑。它讓「刪除」這個動作永遠帶著風險，於是所有人選擇不刪，於是檔案只會長不會縮。

真的要治，只有兩條路：要嘛禁掉動態 key，要嘛強制動態的部分集中在一個地方、明確列出所有可能值。

還有一個很少人做、但我覺得很值得的東西：key 的生命週期。

新增要有人 review，廢棄要標記而不是直接砍，標記之後放一個 release 的寬限期，過了再刪。跟 API 的 deprecation 是同一套思路。

只是大家都覺得「不過就是文字嘛」，所以沒人這樣做。

——

第三層：工程的節奏跟翻譯的節奏對不上

這一層開始真的是團隊的苦痛。

工程的節奏是 sprint，兩週一次；翻譯社的節奏是報價、排程、交件，來回可能兩週。設計還在調文案，PM 還在跟法務確認用詞。

於是你會遇到經典場景：功能上線了，但 ja.json 裡面那三個 key 還是英文。

然後就開始有人在 code 裡面寫 fallback，寫著寫著整個專案就變成「中文一定對、英文大概對、其他語系隨緣」。

這裡有一個很多團隊沒想清楚的決策：翻譯缺漏的時候，到底要顯示什麼？

顯示 key？使用者會看到 order.status.pending，很醜，但至少大家一眼就知道壞了。

fallback 到英文？畫面看起來正常，但問題會被藏起來，藏到某天客戶截圖來罵人才被發現。

我自己傾向 production fallback 到英文，但 CI 要擋、staging 要顯示成醒目的樣子。讓問題在使用者看到之前就吵一次。

再往上一步，是 string freeze。

這在遊戲業和大型軟體公司是標準動作：某個時間點之後文案不准改，送翻譯，翻完回來驗，然後才發版。

但現在大家都在跑持續交付，你要一個團隊「這週開始文案凍結」，會被當成瘋子。

所以更實際的做法，是把「功能上線」跟「語系上線」解耦。功能先用 feature flag 藏著，語系到齊了才對那個地區開。

這樣工程節奏跟翻譯節奏就不用硬綁在一起，各自跑各自的。

還有一個成本超低但幾乎沒人做的事：pseudo-localization。

就是在開發階段把所有字串自動變成 [!!! Ĺöĝĩñ !!!] 這種——加長三成、換成帶重音的字元、前後加標記。

你會在第一天就發現哪個按鈕的寬度是寫死的、哪段文字沒有被 t() 包到、哪個版面德文一定爆。

不用等到翻譯回來，不用等到當地同事回報。

真的很便宜，而且真的很有效。

最後是 source of truth。

到底是 Figma 上的文案？是 Google Sheet？是 repo 裡的 JSON？還是翻譯平台？

我看過一個團隊，這四個地方全部都有一份，而且四份都不一樣。🙄

這種狀況沒有工具能救，因為問題不是同步，是根本沒有人被授權說「以我這份為準」。

只能有一個地方是真的，其他都只能是它的投影。這句話講起來很簡單，做起來要動到四個部門的工作習慣。

——

第四層：在地化不等於翻譯

到這一層就不是工程能自己解決的了。

日期格式、貨幣、數字的千分位、姓名的順序、敬語階級、複數規則、文字長度、RTL 的版面、法規要求的揭露文字⋯⋯

先講複數。英文兩種形態（one / other），你以為包一下就好，結果阿拉伯文有六種，俄文有四種，日文一種。

這不是「加個 if」能解的，這是 CLDR 定義的語言學規則。你的 i18n 套件有沒有正確支援，決定了你要不要在半年後大改一次。

再講長度。同一句話，德文大概比英文長 30%，芬蘭文還會再長，中日韓則短很多。

同一顆按鈕在中文、英文、德文下的文字寬度對照，德文超出照中文刻死的固定寬度中文 English Deutsch 登入 Log in Anmelden 虛線是照中文刻死的寬度，德文就從這裡溢出去

按鈕寬度如果是照中文刻的，德文上線那天，你會在同一頁看到好幾顆按鈕的字被切掉。

再講語序。{name} 已將 {count} 個項目移到 {folder} 這種句子，在有些語言裡面順序會完全不一樣，而且會因為 count 是 1 還是 5 而改變動詞形態。

所以字串串接絕對不行。你只要在程式碼裡面寫 t('moved') + count + t('items') 這類組合，想靠重複利用來少管幾個 key，就等於保證某些語言永遠翻不好。

然後是那些工程完全無權決定的部分。

行銷會說「這句話在馬來西亞不能這樣講」，業務會說「這個客戶要求把這個詞改掉」，法務會說「這段免責聲明一個字都不能動」。

你以為在做 i18n，其實你在做 l10n，而 l10n 背後站著的是法務、行銷、當地業務。

這時候你才發現，那個 JSON 檔不是設定檔，它是一份對外的法律文件。

那怎麼辦？只能建 reviewer 制度。

每個語系要有一個名字，一個真的會用那個語言的人，最好是當地的同事或代理商。他不用懂 code，但他要有權說「這句不行」。

沒有這個人，你的翻譯就是 Google 翻譯等級，而且沒有人知道到底翻得對還是錯。

——

第五層：說白了，是政治

最深的一層，是沒有人想扛這件事。

多語系很像基礎建設，做得好沒人稱讚，做不好全公司都罵你。它不會出現在任何一份 OKR 上，也沒有哪個 PM 的績效是「語系品質」。

所以它永遠是「順便做一下」。

但你想想，一個 28 種語系的產品，每加一個詞彙就要動 28 個檔案、跑 28 次翻譯、驗 28 次版面。這種量級的事情，你要一個人「順便」？

我覺得要讓這件事被正視，唯一的辦法是把成本算給老闆看。

一個新詞彙，從設計定稿、開 key、送翻譯、回稿、驗版面、修爆版，乘上 28 個語系，你把工時攤出來，老闆才會知道那個「順便」到底是幾個人天。

成本沒有被算出來之前，它就是免費的。免費的東西不會有人管，也不會有人給資源。

然後是衡量。

治理沒有指標就是空話。至少要有三個數字：各語系的翻譯覆蓋率、死 key 的比例、從文案定稿到翻譯上線的 lead time。

這三個數字如果沒有人看，那就代表沒有人在治理，只是在救火。

治理的本質其實只有三件事：誰決定、誰執行、誰買單。

誰決定文案的最終版本，誰負責把它送進去，出錯的時候誰要處理。這三個問題只要有一個沒答案，你的多語系就會慢慢腐爛，而且腐爛得非常安靜。

至於要不要成立一個專門的團隊——如果你有五個以上的語系、三個以上的產品團隊，我覺得該有。不一定是一整個團隊，但至少要有一個明確的 owner，他的工作內容裡面白紙黑字寫著這件事。

不然它就會一直是那個「大家都覺得很重要，但誰都不想碰」的東西。

——

所以我後來的想法變了。

以前我會想「怎麼設計一個好的 i18n 架構」，現在我會先問「這家公司有沒有人真的擁有這件事」。

多語系破版這件事，我在關於前端架構裡面就列過，那時候我還當它是個架構關注點。前陣子看一個一人開發的字幕產品，語系是寫死在程式碼裡的，一個人做反而沒這個問題——因為擁有者只有一個，就是他自己。

如果沒有那個人，架構寫得再漂亮，兩年後一樣是一坨。

工具永遠救不了流程，流程也救不了沒有人負責的組織。

那你們家的語系檔，現在是誰在維護的？

都用 Tailwind 就好了，寫什麼 CSS？十年演進都在解同一題

竹子日誌（竹子） — Tue, 18 Aug 2026 15:50:00 GMT

「現在誰還在寫 CSS 檔案啊？」

我真的聽過這句話。而且不只一次。

現在開新專案，起手式就是 npm create vite 一波，Tailwind 裝好，然後從此不再思考。

「大家都用啊」

「這是現在的標準吧」

「寫 CSS 都過時了」

但你問他為什麼用 Tailwind，得到的通常是「不知道」，不然就是一些似是而非的答案。

新的不等於好的，舊的也不等於爛的。每個方案都是在解決當下那個時代最痛的問題，你不知道它痛在哪，就不會知道你手上這個工具到底幫你擋掉了什麼、又幫你製造了什麼。

這件事我在技術選型是要找合適的講過一次——技術選型是「優劣評估」，不是「高低比較」。

——

十幾年的演進，其實只有三件事

說白了，這十幾年來 CSS 方案的演進就三件事：

作用域、複用性、可維護性。

為什麼是這三件事？因為只有它們會隨著專案變大、人變多、時間拉長而越來越痛，其他的都是附加價值，我從來不把「方便」當成優先因素。

這條路走起來比較像是一直在搬家。每搬一次，舊房子的漏水補好了，新房子又冒出新的裂縫——然後下一代方案再來補這個裂縫。

作用域、複用性、可維護性三條線各自在哪一代被解掉作用域複用性可維護性全域 CSS BEM 預處理器 CSS-in-JS CSS Modules Atomic CSS 每一代換一種形式，沒有一次真的解完

實心是被工具真的解掉的，空心是只能靠紀律撐著。作用域一路到 CSS Modules 才交給編譯期，複用性從預處理器就開始補、到 Atomic CSS 補得最漂亮，而可維護性從來沒有哪一代一次解完——它只是每一代換一種形式重新出現。

——

全域 CSS：簡單到不行，也髒到不行

最早期就是一支 style.css，寫到爆。

好處是簡單到不行，沒有 build，打開就能改，瀏覽器直接吃。到今天做小活動頁我還是這樣寫，快得很。

壞處也很直接：全域污染。你在 A 頁面改個 .title，B 頁面就炸了。權重打架就開始 !important 疊上去，最後變成沒人敢刪的一坨。

我真的看過那種三千行、註解寫「不要動這段」的 CSS 檔。

你敢刪嗎？我不敢⋯⋯

——

預處理器：讓你寫得舒服，但沒讓你變安全

Sass、Less 進來，變數、巢狀、mixin 一次補齊，最早的 Design Token 就是在這個時候誕生的。

那時候真的覺得爽，終於可以寫 $primary-color，終於不用一直重複打選擇器。函式、迴圈、@extend 都有，複用問題算是解掉一半。

那作用域呢？

一樣沒解決。巢狀寫太深，編譯出來就是 .a .b .c .d .e，權重高到後面誰都蓋不掉。而且多了編譯步驟，改個變數要等重新編譯，開發體驗其實有變差的時候。

它讓你寫得更舒服，但沒讓你的 CSS 變得更安全。

這也是為什麼我在關於 SASS/SCSS 裡會說它的使用率一路往下掉——它解的那一半，後面的工具解得更乾淨。

——

命名方法論：沒有工具強制的規範，都會被時間打敗

BEM、OOCSS、SMACSS，用「約定」來換秩序。

.card__title--active 這種寫法，一眼就知道誰是誰、層級在哪，不用工具、不用 build，純靠紀律就能做到弱作用域。

那為什麼一堆人說 BEM 難用？

我想說的是，很多人根本沒在寫 BEM。

我看過太多這種：

.card {
  &__list {
    &__item {
      &__sub {
        &__text { }
      }
    }
  }
}

編譯出來是 .card__list__item__sub__text。

Block、Element、Modifier，Element 只有一層，這是 BEM 最基本的規則。你把 Sass 的巢狀能力拿來當資料夾用，一路 &__ 疊下去，疊出一個沒人看得懂的名字，然後回頭說「BEM 好難用喔」。

不是 BEM 難用，是你在用 Sass 的語法糖假裝自己在寫 BEM。

這就是方法論最尷尬的地方：它只是約定。新人進來不懂規則，同事趕上線隨手加個 .title2，一個月後就走鐘了。

沒有工具強制的規範，最後都會被時間打敗。

——

CSS Modules：我覺得性價比最高的一步

編譯期把 class 名 hash 掉，.title 變成 .title_x8f2k。

作用域問題直接被工具解決，你還是在寫純 CSS，學習成本幾乎是零，也沒有 runtime 成本。

補充一個很多人沒意識到的事：Vue SFC 的 <style scoped> 其實就是同一套思路的延伸。

它不是 hash class 名，而是編譯期幫每個元素加上 data-v-xxxxxx 屬性，選擇器再自動補上對應的 attribute selector。做法不同，但目的一模一樣——編譯期產生唯一識別，讓樣式關在元件裡。

所以你如果是 Vue 的人，其實你早就在用 CSS Modules 的概念了，只是它幫你包得太順，順到你不覺得那是一個「方案」。

缺點也一樣。動態樣式很尷尬，要根據 props 換顏色？只能先定義好一堆 class 再用 JS 拼字串。跨元件共用、傳 class 進去覆蓋也很不直覺（Vue 這邊就得靠 :deep() 打洞）。

它解了作用域，但沒解「樣式跟狀態要連動」這件事。

——

CSS-in-JS：樣式跟元件同生共死，代價是 runtime

styled-components、emotion 這時代，直接把樣式塞進 JS 裡。

真正的元件化，樣式跟元件同生共死，刪元件就等於刪樣式，不會有死 CSS 留下來。動態樣式更是它的主場，props 直接進 template，主題切換、條件樣式都超順。

那為什麼後來大家又跑掉了？

代價是 runtime。每次 render 都要算樣式、插 style tag，量一大就吃效能。SSR 要處理 hydration、要抽 critical CSS，設定一堆。加上 bundle size 也不是零。

那幾年大家嘴上說爽，實際 profiling 一開就知道痛在哪。

也許有人會說 styled-components 停更就代表這條路死了。我不這樣看，這件事我在 CSS In JS 講過——它只是退回它原本就該待的位置而已。

——

Atomic CSS：你的 Tailwind 跟我的 Tailwind 不是同一個東西

從 windicss 開始，到現在 tailwind 幾乎壟斷市場了。

每個 class 一個屬性，樣式不會膨脹，掃描原始碼只產出你用到的，檔案小、複用高、零 runtime。設計系統的約束直接寫進 config，團隊內的一致性也好維持。

但 HTML 會變得非常之長，那種一行三十個 class 的畫面，第一次看都會皺眉。它也需要 build 才能掃描、動態拆分 CSS chunk 很難做、CSS 變數架構隱晦。

還有一個更根本的問題，大家好像都不太提——

因為 config 太自由，你的 Tailwind 跟我的 Tailwind，很可能根本不是同一個東西。

你的 p-4 是 16px，我的專案改過 spacing scale，p-4 可能是 20px。你的 text-primary 是藍的，我的是黑的。你習慣 rem，我全改 px。再加上一堆自訂的 plugin、任意值 [13px]、preset 疊 preset⋯⋯

大家都說「我會 Tailwind」，但走進一個新專案，你還是得先去翻 tailwind.config。所謂的通用語言，其實只通用了語法，沒通用語意。

做 UI Library 的時候特別有感——你的樣式要被別人的 Tailwind 掃到、別人的 config 又跟你完全不一樣，這件事本身就很彆扭，我在關於我與前端無關緊要的分享 Day 49 抱怨過一次。

我不覺得它是唯一解，但它確實把「複用」這題解得最漂亮。

——

Zero Runtime：不是新發明，是把老方案縫在一起

vanilla-extract、Panda CSS、StyleX 這幾個，想兩全其美。

用 TypeScript 寫樣式，有型別、有補全，編譯期就把 CSS 抽出來變成靜態檔案，runtime 成本歸零。你寫的時候感覺像 CSS-in-JS，跑起來卻是純 CSS。

但講白一點，它其實沒有發明什麼新東西。

Zero Runtime 不過就是靜態打包後的結果——CSS Modules 的「編譯期產生唯一 class」加上 Atomic CSS 的「屬性層級複用」，兩個老方案組起來的新包裝。

StyleX 特別明顯，Meta 拿它撐 Facebook 和 Instagram 那種量級，編譯出來就是一堆原子 class，再用一套明確的合併規則決定誰蓋誰——直接把 CSS 權重這件事從執行期挪到編譯期解掉。

所以與其說它是「下一代」，不如說它是把前面幾代的優點縫在一起。

代價是生態還小，踩到坑常常沒人回答。編譯設定也複雜，跟框架、跟 bundler 綁得緊，換一次就要重弄。真正的動態值還是有限制，該用 CSS 變數的地方一樣得用。

它很美，但還沒到隨便丟給團隊就能跑的成熟度。

——

原生 CSS：現在瀏覽器自己都有了

經過時空演化，CSS 真的越來越好用。

CSS 變數、@layer、原生巢狀、@container、:has()、@scope，這幾年一口氣全進來了。

當年我們拿 Sass 解變數、拿 BEM 解權重、拿 Modules 解作用域、拿 media query 硬幹 RWD——現在瀏覽器自己都有了。

所以我最近的想法反而是往回走一點。

那還需不需要工具？需要，但能用原生解的，就別再多疊一層。

剩下的問題是⋯⋯客戶的瀏覽器還沒支援。

——

那到底該用哪個？

我自己的判斷大概是這樣。

做行銷頁、活動頁、一次性的東西，原生 CSS 或是 Tailwind 就好。這種東西活不過三個月，你上一套完整的 Design Token 只是在自嗨。

做後台、內部工具、要快的專案，Tailwind 真的無敵。不用命名、不用開檔案、改完就看到，這種開發速度沒什麼能打。反正 UI 沒那麼多客製，一致性又剛好是你要的。

做產品的主要應用、要長期維護、五個人以上的團隊，我會選 CSS Modules 或 Vue 的 scoped style。作用域交給工具，寫的是純 CSS，新人第一天就能上手，五年後回來看也還讀得懂。

做 UI Library、Design System、要給別人共用的東西，Zero Runtime、原生 CSS 加變數、SCSS 配合 CSS Modules，都非常合適。你不能假設使用者的環境跟你一樣，也不能逼別人裝你那套 build，樣式必須要能被覆蓋、能被 tree-shake、盡量不帶 runtime。像 antd 反其道而行，依然做得不錯，但最糟糕的莫過於拿 Tailwind 來做，根本難以維護。

主題會頻繁切換、樣式高度跟狀態綁定、微前端這類動態模組載入，那 CSS-in-JS 的 runtime 成本可能就是值得付的，runtime 反而是最好的應用策略。

沒有哪個方案是最好的，只有適不適合。

你的專案型態、團隊有幾個人、專案要活幾年、將來誰接手——這些才是真正該問的問題，而不是「大家都用什麼」。

每一代方案都在解上一代的痛，然後製造新的痛。

那你現在痛的是哪一個？

Vue Taiwan 小聚：用一個下拉選單的輪子，講不好當標題的事

竹子日誌（竹子） — Mon, 17 Aug 2026 13:30:00 GMT

講稿改到最後一版，我做了一個決定：把程式碼全部刪掉。

一行都不留。

這次很榮幸被邀請到 Vue Taiwan 小聚分享，主題是「來造一個下拉選單的輪子」。四十分鐘，聽起來很長，實際上能塞進去的資訊真的太有限了。

那要塞什麼？

實作細節丟上去，台下抄不完也記不住，回家自己看文件比我講得清楚。所以我乾脆整段拿掉，全程用輕鬆自然的方式講，像是真的在跟朋友聊天那樣。雖然還是講到舌頭打架，自己在台上尷尬了好幾次⋯⋯

——

有來的都知道，這個主題其實醉翁之意不在酒。

我是拿「下拉選單」在講另一個技術觀念，表達一段不適合當演講標題的主軸。中間也埋了不少橋段，只是我的表現方式可能還有很多需要淬煉的地方。

會挑下拉選單，是因為它剛好是那種「看起來最簡單、做起來最深」的元件。這件事我在元件真的別亂自己刻跟造一個 UI 輪子 ep1都寫過——你以為在做一顆按鈕、一個選單，實際上你在做的是一整套狀態、無障礙、鍵盤操作跟樣式覆蓋的取捨。

用一個大家都覺得簡單的東西，去講一件其實不簡單的事，這種落差本身就是最好的講法。

那台下的人到底有沒有接收到？老實說我也不確定，這種東西沒辦法當場驗收。

——

這次一起來的「Luciano」和「一隻狐狸」都是舊識，想不到剛好都被邀請，能聽到他們分享我覺得很開心。

Luciano 選了一個非常硬核的主題，我自己都沒有信心可以講好，他敢挑這種題目，真的是有足夠的底蘊。

一隻狐狸的台風很穩健，慢慢講、正確表達，咬字取詞都很精準。內容也是照著當下的時間，適當挑出大家最需要的知識點。

比起上次在 JSDC 小聚全程飆車，這次我學會的事情是：講得少一點，反而留得多一點。

如果你當天有去，希望可以給我一點反饋。

下一次見面的時候，我想帶更多的經驗跟知識過去。那你會想聽哪一種？

Refresh Token 到底有什麼難的？三個上線才會炸的地方

竹子日誌（竹子） — Thu, 13 Aug 2026 01:30:00 GMT

上一篇寫 Refresh Token，反應意外地熱烈。

而回應大概可以歸成三句話：

「有什麼難的？」

「用套件就好啦～」

「我怎麼都沒遇過？」

老實說，這三句我這幾年聽了不下十次。

而且我完全能理解為什麼有人會這樣講——因為在單人、單分頁、開發環境的世界裡，Refresh Token 真的沒什麼難的。

難的是它上線之後。

就算做了這麼多年前端，就算現在有 AI 幫忙寫，我還是覺得它難做。

——

難的從來不是流程，是流程跑起來之後

AccessToken 過期了，拿 RefreshToken 去換一組新的，換完繼續用。

就這樣啊，到底有什麼難的？

這句話沒有錯。它描述的是「流程」，而流程本來就簡單，一張圖三個箭頭就畫完了。

但流程從來不是難點。

難的是那些你在自己電腦上永遠測不出來、一上線就開始有人回報的鬼故事。

我把這些鬼故事濃縮成三塊：token 要放哪、各種時序問題怎麼收、還有——只要你用了 SSR，前面兩塊會全部重來一次。

——

先講存放位置。

大部分人的直覺是 localStorage。存進去、要用的時候讀出來，簡單直接，誰不會。

但只要稍微碰過資安你就知道，localStorage 根本是 XSS 的提款機。頁面上隨便一段被注入的 JS，一行 localStorage.getItem 就把你的 token 整包端走。這件事的前提我在資安漏洞遠比你想像的還要多講過：前端沒有秘密，只要東西在前端，就有辦法被拿走。

於是進階一點的答案是：放 httpOnly cookie。

JS 讀不到，XSS 偷不走，聽起來很完美吧？

很多文章講到這裡就收工了，說這是「最佳方案」。

但事實上，這句話藏了一個很深的前提——cookie 送得到後端。

而 cookie 送不送得到，取決於一件你可能從來沒把它當成資安問題的事：你的 API 跟你的網站，是不是同一個網域。

如果是 app.example.com 配 api.example.com，那沒事，同一個家族，cookie 隨便送。

但如果是 myapp.com 配 api.某某廠商.io，這就變成跨域，你的 cookie 成了第三方 cookie。

Safari 直接封鎖。Firefox 預設封鎖。Chrome 也讓使用者可以自己關掉。

也就是說，就算你今天設定成功、測起來也正常，這仍然是一個「現在就有一部分使用者是壞的」的地基。

那個被講到爛的「最佳方案」，其實有一半的前提你根本控制不了。

——

併發不是一個點，是一整排堵不完的洞

再來是併發，以及它底下一整家親戚。

這是最經典、也最壞心的坑。

想像一個畫面。使用者打開儀表板，畫面同時發出五個請求。剛好這一刻 AccessToken 過期了，五個請求整整齊齊回你 401。

你的攔截器很盡責，五個各自去觸發一次 refresh。

如果後端有做輪替（每換一次就把舊的作廢），那第一個換成功了，剩下四個手上拿的全是已經失效的舊 token。

後端一看：同一張票被用第二次？這是攻擊。整組作廢，強制重新登入。

使用者：我只是重新整理一下，為什麼被登出了？

五個請求同時遇到 Token 過期，各自觸發 refresh，後端判定是重放攻擊而作廢整組憑證 ① ② ③ ④ 打開儀表板五個請求一起飛 Token 剛好過期五個都拿到 401 攔截器各自補救同一秒換五次舊票被用第二次整組作廢使用者：我只是重新整理一下，為什麼被登出了？

併發不是理論上的邊界情況。只要頁面同時發多個請求，而 token 剛好在那一刻過期，五次 refresh 就會撞在一起——後端看到舊票被重用，判定是攻擊，直接作廢整組憑證。

也許有人會說：那我在攔截器裡做一把鎖，同一時間只准一個 refresh 在飛，其他人共用同一個 Promise，不就好了？

對，這確實是標準解法，程式碼也不長：

let inflight: Promise<string> | null = null;

function refreshToken(): Promise<string> {
  if (!inflight) {
    inflight = doRefresh().finally(() => {
      inflight = null;
    });
  }
  return inflight;
}

但這把鎖只鎖得住「這一個頁面」。

——

一把鎖鎖不住五個分頁

使用者開了五個分頁。

每個分頁都是獨立的執行環境，你頁面裡那個 inflight 變數，隔壁分頁根本看不到，也管不到。

於是五個分頁同時 refresh，你剛剛解掉的併發，換個維度又整組回來了。

這題要往上一層解。想像五個人同時想講話，但現場只有一支麥克風——總得有人先搶到，搶到的那個負責講，其他人負責聽。

在瀏覽器裡，那支麥克風叫做 Web Locks API（navigator.locks），或者用 BroadcastChannel 自己兜一套。所有分頁去搶同一把鎖，搶到的那個負責換，換完把新 token 廣播給其他人。

多個分頁搶同一把瀏覽器層級的鎖，只有搶到的分頁去換 token，換完再廣播給其他分頁分頁 A 分頁 B 分頁 C 搶同一把鎖只有一個分頁真的去換 token 換到的新 token 廣播給其他人 navigator.locks 廣播回每個分頁，沒搶到的人直接用新的

頁面裡的鎖只管得到自己，跨分頁要往瀏覽器層級搬：所有分頁搶同一把鎖，只有搶到的那個真的去換，換完把新 token 廣播回去。

還有一個很多人完全想不到的觸發點：瀏覽器甦醒。

筆電闔上、分頁擺著沒動，或是手機切到背景，過了一陣子你回來——

那一瞬間，所有背景分頁同時被喚醒，同時發現 token 過期，同時打 refresh。

跟前面一模一樣的併發風暴，只是這次的觸發者是「使用者回來了」這個再正常不過的動作。

你會發現，併發根本不是一個點，而是一整排你堵不完的洞。

——

長連線不走攔截器，它就默默掛在那

還有一個平常不會想到、但一定會中的：長連線。

WebSocket、SSE 這種，連上去就是一條長長的水管，一開始拿當下有效的 token 握手，之後就一直開著。

但 token 是會過期的。

握手那一刻它有效，開著開著它就失效了。

HTTP 請求還好，下一個請求吃到 401，攔截器會接手去 refresh。

但長連線不走攔截器啊。

它就這樣默默掛在那，帶著一張早就過期的票。你以為還連著，其實伺服器那端可能已經不認你了——像你拿一張過期的識別證卡在門禁前面，機器不會吭聲，它只是不再幫你開門。

最靠北的地方是：頁面看起來一切正常，就是即時通知莫名其妙停了、資料不再更新。你 debug 半天，因為它根本沒報錯，沒有 401，什麼都沒有。

解法是 refresh 成功之後，要主動拿新 token 把長連線重新建立一次。

這件事很容易在實作時被整個漏掉，因為它跟 HTTP 那套完全是兩個世界。

——

登出的順序反了，你就會養出殭屍

再講一個更陰的時序問題：登出。

你可能覺得登出有什麼難的，清掉 token、導去登入頁，結束。

但登出從來不是一個瞬間，它是一串動作：取消請求、清記憶體、打後端撤銷、清快取、導頁。

問題來了。假設在你按下登出的同一刻，背景剛好有一個 refresh 正在飛。

你這邊已經清掉 token、跳到登入頁了——結果那個背景的 refresh 慢了半拍，成功回來了，然後很盡責地把新的 AccessToken 寫回記憶體。

恭喜，畫面上你登出了，憑證卻還活著。

一個活生生的殭屍登入狀態。

登出流程的兩種順序對照：先清 token 會被慢一拍的 refresh 寫回憑證，先 abort 才不會順序反了按下登出清掉 token 導到登入頁 refresh 回來了憑證又活了畫面登出了，憑證還在——殭屍登入狀態先斷後路按下登出 abort 進行中的 refresh 清 token 與快取撤銷後導頁沒有東西再寫回來

登出的第一件事不是清 token，是先把還在飛的 refresh 中斷掉。順序反過來，慢半拍回來的 refresh 就會把新憑證寫回一個已經登出的畫面。

所以登出的第一件事，不是清 token，是先把進行中的那個 refresh 給中斷掉——AbortController 這時候就是拿來幹這個的：

async function logout() {
  authAbort.abort(); // 先斷後路,讓還在飛的 refresh 直接死掉
  clearMemoryToken();
  await revokeOnServer().catch(() => {});
  redirectToLogin();
}

順序反了，你就會養出殭屍。

——

用了 SSR，前面那些要全部重來一次

如果你的專案是純 CSR，上面那些做好，大概就能收工。

但只要你用了 SSR——Next、Nuxt 那一票——整套邏輯要重寫，而且會直接撞到框架本身的限制。

我去年噴 Next，噴的就是這一段。

而這其實也是我在你可能不需要 SSR 裡想講的同一件事：SSR 帶來的每一個好處，背後都有一張帳單。認證這張，開得特別大。

伺服器一旦開始把 HTML 吐給瀏覽器，header 就定型了。

你在 render 到一半的時候發現 token 過期、想順手 refresh、想把新 cookie 寫回去——抱歉，寫不回去。

於是 refresh 這件事被迫搬到 middleware 或 route handler，render 階段只能讀、不能寫。

光是這個切割，就讓整個資料流變得很扭曲。

第二個限制：你根本不一定拿得到判斷的依據

理想上，middleware 想知道 token 過期了沒，很簡單嘛，看一下到期時間就好。

但後端不一定會把到期時間吐給你。也不一定給你一支「驗證這個 token 還有沒有效」的 endpoint。

那 middleware 到底要怎麼判斷？

猜。

要嘛每次都賭它還有效、錯了再補救；要嘛每次都打一趟後端問，多一次往返。

無論哪一種，你在 server 端做的判斷，都不是「知道」，而是「猜測」。

一個要在每個請求都跑、卻只能用猜的守門員，你說可靠嗎？

第三個限制：你會被迫維護兩套

同一支 API，在 server 端呼叫和在 browser 端呼叫，拿 cookie 的方式、帶 header 的方式、能不能改 cookie，全都不一樣。

server 端要從進來的 request 裡把 cookie 撈出來，browser 端瀏覽器會自動幫你帶；server 端不能亂改 header，browser 端沒這個限制。

很多人想省事，寫一個 client 用 typeof window 判斷現在在哪一邊。

聽起來很聰明，但這種東西在 edge runtime 上特別容易出事，型別提示也整個糊掉。

最後你會發現，乖乖拆成兩個 client 反而最省事。

同一件事、兩套邏輯，這就是 SSR 的稅。

——

所以 Refresh Token 到底難在哪

難的從來不是「怎麼發一個 token」。

難的是它同時牽扯到瀏覽器怎麼存東西、分頁之間怎麼協調、長連線怎麼跟上、登出的時序怎麼排、跨網域政策怎麼擋你，還有 SSR 框架逼你維護兩套。

而最壞心的地方是：任何一環理解錯了，症狀都長一模一樣——

使用者偶爾莫名其妙被登出。

一個你抓破頭都重現不出來的問題。

說白了，這整件事的心態跟零信任是同一套：與其賭那些狀況不會同時發生，不如假設它們一定會發生，然後把爆炸半徑縮到最小。

所以下次再有人跟你說「Refresh Token 有什麼難的、用套件就好」——

那大概只代表一件事：他做出來的機制有 bug，只是他還沒踩到而已⋯⋯

不要再創造沒意義的名詞，別再拿 AI 名詞製造焦慮

竹子日誌（竹子） — Sun, 19 Jul 2026 01:39:00 GMT

最近滑社群，每隔幾週就會冒出一個新名詞。

Prompt Engineer。

Context Engineer。

Harness Engineer。

Loop Engineer。

Graph Engineer。

各大 KOL 輪流上場，好像不談 AI 就會落後一樣。

但說白了，這些話題之所以熱，是因為它是流量密碼。

——

我反感的不是新名詞，是拿它當焦慮的原料

其實我不反對新名詞。

技術演進本來就會長出新的詞彙，有些詞確實幫我們描述了以前說不清楚的東西。

我反感的是，這些名詞被拿來當焦慮的原料。

「你還不懂 Loop Engineering？」

「不會用 AI 的工程師會被淘汰。」

每一個名詞背後，都掛著同一句潛台詞：不掌握它，你就要被 AI 取代了。

拜託，冷靜一點。這種「不學就被淘汰」的說法，跟當年吵工程師會不會被 No Code 取代是一模一樣的套路。

——

把包裝拆開，講的還是同一件事

先問一個最基本的問題：

這些名詞，到底定義了什麼？

把包裝拆開來看，很多所謂的新職位、新學科，講的其實還是同一件事——怎麼把需求描述清楚、怎麼把系統設計好、怎麼讓工具在對的位置發揮作用、你的基礎建設穩固了嗎、你到底要解決什麼商業問題？

這些能力以前就存在，只是換了一件 AI 的外衣。

名詞可以一直換，本質沒有變過。

——

玩具和產品之間，隔著使用者與責任

之前在功能做出來只是一句話裡我提過，AI 讓「做出功能」變得很快，但架構、安全、資料庫效率、商業價值的驗證，這些從來沒有變快過。

回歸原點，產品的本質、商業模型、技術應用、基礎建設，這些才是核心。

那些嚷嚷著「AI 都能做」的人，如果完全不懂這些底層的東西，做出來的東西再炫，也很難稱得上是產品。

頂多，是自己手邊的玩具。

玩具沒有不好，我自己也很愛玩。

但玩具和產品之間，隔著的是使用者、是責任、是那些名詞從來不會告訴你的細節。

——

名詞會過期，焦慮會退燒

所有跟技術掛鉤的東西，說到底都是良心事業。

你可以把它包裝得很華麗，靠著新名詞和焦慮賺一波。

但這個東西對使用者到底是好是壞？

很多時候，連做的人自己都不知道⋯⋯

同樣的道理，你可以拿名詞去嚇唬別人，但不要去貶低別人的專業，也不要用名詞去綁架還在認真做事的人。

名詞會過期，焦慮會退燒。

真正留下來的，永遠是那些把基本功做扎實的人。

解決方案比畫圖寫 Code 還重要：AI 時代工程師的價值在哪

竹子日誌（竹子） — Wed, 15 Jul 2026 16:45:00 GMT

最近我一直在想一件事：在小公司待久了，會慢慢發現很多在大公司被奉為圭臬的東西，在這裡其實⋯⋯沒那麼重要。

不是說那些東西不好，而是環境不一樣，答案就不一樣。

——

環境不一樣，答案就不一樣

比如說，一人分飾多角的時候，跨職能的溝通工具就不重要了。你自己就是 PM、就是設計師、就是工程師，要溝通什麼？跟自己開會嗎XD

比如說，系統承載量很低的時候，複雜的系統架構就不需要了。沒有那個流量，就沒有那個煩惱。

又比如說，流程簡單到 AI 一鍵就能跑完的時候，花大把時間建自動化系統，好像也沒那麼划算。

看到這裡，也許有人會想：那小公司是不是什麼都可以隨便做？

欸！不是啦。

——

每一個「好」的背後，都有一張帳單

反過來看，好東西從來都不是免費的。

想要效能好的架構？那需要很多錢去買服務。想要極致的高效？那可能要在使用者端做出取捨。每一個「好」的背後，都有一張帳單，或是一個犧牲。

這也是為什麼，你沒辦法跟 AI 說一句「幫我設計一個使用者體驗良好的系統」，然後就憑空得到一個好用的東西。

AI 給出來的方案肯定很常見、很合理，但常見不等於適合你，合理也不等於真的好用。這件事我在AI 能解決的問題深度裡也提過，它給的是平均解，不是你的解。

——

系統設計，是六個維度之間的取捨

設計一個系統，其實是在「方便」、「易用」、「安全」、「高效率」、「易於擴充」、「維持便宜」這麼多維度之間，不斷地取捨。

因為很多方案，本身就是相斥的。

系統設計的六個維度，彼此相斥，只能在中間取捨方便安全易於擴充維持便宜高效率易用相斥相斥

要安全，可能就犧牲了方便；要便宜，可能就犧牲了效率。系統設計不是把每個維度都拉到滿，而是在相斥的維度之間，選一個剛剛好的位置。

要安全，可能就犧牲了方便。要便宜，可能就犧牲了效率。魚與熊掌，本來就難以兼得。

你可能注意到了，我沒有提「好開發」、「好維護」、「好溝通」。

老實說，在 AI 時代，這幾件事的份量真的變輕了。Code 寫得漂不漂亮、文件齊不齊全，AI 都能幫你補上一大截。但「該取捨什麼」這件事，AI 幫不了你。

——

剛剛好的解決方案，AI 觸及不到

所以繞了一圈，我想說的是：

能在有限資源、有限時間、有限環境之下，找到那個「剛剛好」的解決方案——這件事的價值，遠遠超越畫圖，也超越寫 Code。

為什麼這件事 AI 難以達成？

因為它背後依賴的是「真實世界」的變數。你的預算、你的團隊、你的客戶、你的時程，這些都不在 prompt 裡，而在你每天面對的現實裡。

如果你想再往下追一層「架構到底要解決什麼」，我之前寫過架構要解決什麼問題，講的也是同一件事：先搞清楚問題，方案才有意義。而在這之前，功能做出來只是一句話——真正難的，從來都不是把它做出來。

這是 AI 無法觸及的地方，也是我們還站得住腳的地方⋯⋯

功能做出來只是一句話，難的部分 AI 沒讓它變快

竹子日誌（竹子） — Mon, 13 Jul 2026 13:00:00 GMT

現在做功能，真的只要一句話。

打開對話框，描述你想要什麼，AI 分分秒秒就把東西生出來。想要就有，功能像自來水一樣，水龍頭轉開就流出來。

老實說，這種爽感是真的。

但最近，我開始感覺到不對勁。

——

疊床架屋，改一處震十處

事情是這樣的。

隨著系統慢慢長大，我發現「加功能」這件事，沒有想像中那麼簡單了。

疊床架屋之下，隨便加一個小功能，專案體積就暴漲一波。改動的影響範圍動不動牽涉數十個地方，改一處、震十處。

我不禁懷疑：這真的正常嗎？

——

AI 沒改變這件事，只是讓人更快跳過思考

後來我想通了一件事。

工具再強，願意好好規劃架構的，還是那些人。願意關注軟體長期維護的，也還是那些人。

AI 沒有改變這件事，它只是讓不想思考的人，更快地跳過思考。

一個功能上線之前，有人想過改動會衝擊到哪些測試範圍嗎？有人看過它偷偷塞進去的那些無效率資料庫查詢嗎？有人檢查過它會不會多開一扇資安的後門嗎？

甚至更根本的——這個功能的商業價值，有人驗證過嗎？

這些其實都不是新問題。我之前寫過什麼才算是好 Code，也聊過架構到底要解決什麼問題，那些判斷從來沒有因為工具變強而消失，只是更容易被跳過而已。

——

功能做出來了，然後呢？

你有想過使用者真的覺得好用嗎？

還是覺得 UI 流程和介面都想好了，就不需要重新規劃設計？功能跟整個系統的整合性，又是誰在把關？

這也是為什麼我一直覺得，AI 的成果其實取決於你的管理能力。它做得多快不是重點，重點是你有沒有能力去接住它做完之後的那一堆問題。

——

一個只有「聽話員工」的團隊，是你要的嗎？

這些問題，在 AI 不斷變強之後，只會越來越明顯。

因為 AI 終究只負責執行。它不會跟你吵架，不會質疑你的需求，就算拿到的資訊缺了一角，它也照做不誤。

它是一個絕對「聽話的員工」。

但一個只有聽話員工的團隊⋯⋯

這是你要的嗎？

零信任

竹子日誌（竹子） — Fri, 03 Jul 2026 08:40:00 GMT

最近在研究一個東西，越挖越覺得有趣，想先寫一篇科普當鋪陳。

主題是「零信任」。

朋友聽到的第一反應是：「這是什麼？聽起來很邊緣人欸，誰都不信任？」

欸！不是啦，但⋯⋯其實你也沒說錯XD

邊界防禦：把系統當成一座城堡

先講傳統的資安思維。

以前我們保護系統，就像蓋一座城堡。

外面挖護城河、架高牆、城門派士兵站崗。只要你通過城門的檢查，進到城裡，恭喜，你就是自己人了。

城裡的酒館、糧倉、金庫，你想去哪就去哪，沒人再攔你。

這就是所謂的「邊界防禦」。VPN 就是那道城門，內網就是城裡。

聽起來很合理吧？

但問題來了。

城牆早就不存在了，你還在守城門

現在的系統早就不是一座城堡了。

微服務架構下，一個產品背後可能是幾十個、上百個服務，散落在不同的雲、不同的 cluster，彼此瘋狂通訊。

人在咖啡廳、在家裡、在高鐵上，用自己的手機、公司的筆電輪流連線。

城牆早就不存在了，你還在守城門，守個寂寞。

更慘的是，只要有一個壞人混進城門——偷了通行證也好、內部叛變也好——整座城對他來說就是吃到飽。

他可以在「可信任」的內網裡自由掃描，一台打穿再打下一台，這招叫「橫向移動」。

這幾年一堆重大資安事件，都不是城牆被轟破，而是有人拿著合法的鑰匙走進來，然後在裡面橫著走。

內網 ≠ 安全，這件事大家終於痛過才學會。

零信任的核心：Never trust, always verify

零信任（Zero Trust）的核心就一句話：

Never trust, always verify.

永不信任，持續驗證。

我不管你人在城裡還是城外，我不管你昨天有沒有驗證過，你每一次要拿東西，都給我重新證明你是誰、你有沒有資格。

飯店房卡：每一道門都是一次驗證

我覺得最貼切的比喻是飯店房卡。

你入住的時候，櫃檯驗你的證件，給你一張房卡。

這張房卡只能開你自己的房間，只能搭到你住的樓層，只能在退房日之前使用。

你想去頂樓行政酒廊？抱歉，你的卡刷不進去。

每一道門，都是一次驗證。這就是最小權限：你的工作只需要碰 A 服務，那就只給你 A 服務的門禁，多一分都不給。沒被明確允許的，一律拒絕。

更狂的一招：讓整棟飯店直接隱形

但零信任玩到極致，還有更狂的一招。

不只是每道門都要刷卡——

是讓整棟飯店直接隱形。

——

什麼意思？

傳統的服務要對外提供功能，就得在網路上開一個 port，像是在路邊開一扇門。

門開在那裡，路過的人都看得到。壞人拿著掃描工具在網路上晃一圈，馬上知道你家有幾扇門、哪扇門看起來比較舊、哪扇門的鎖有已知漏洞。

而零信任的進階做法是：服務不開任何門。

對，一個 port 都不開。

所有連線都是由服務自己「從裡面往外撥出去」的，外面沒有任何入口可以敲。

沒有憑證的人來掃描，得到的結果是——什麼都沒有。不是「拒絕連線」，是連這個服務存在的痕跡都找不到。

你不能攻擊一個你看不見的東西。

判斷依據從「你從哪裡來」換成「你是誰」

那授權的人怎麼連？

關鍵在於，判斷依據從「你從哪裡來」變成「你是誰」。

以前的網路世界，IP 位置就是你的身份證。但 IP 會變、會被偽造、會共用，拿地址當身份，本來就很荒謬。

零信任改用密碼學的身份：每個服務、每台裝置、每個使用者，都有自己的憑證。連線的兩端互相亮出憑證驗明正身，中間再由一套規則決定「這個身份能不能碰這個服務」。

你要連的不再是某個 IP 加 port，而是一個「有名字的服務」。整段路徑端對端加密，中間經過誰都拆不開。

爆炸半徑：就算他進來了，也走不了多遠

這樣設計最爽的地方在哪？

爆炸半徑。

假設最壞的狀況真的發生了，某台服務被打穿。攻擊者興奮地環顧四周，準備開始橫向移動——

然後發現，什麼都看不到。

他能碰的，只有這台服務原本被授權存取的那幾扇門。其他服務對他來說根本不存在。

與其賭壞人進不來，不如設計成「就算他進來了，也走不了多遠」。

這才是成熟的資安態度。

導入零信任，最難的其實是心智模型

也許有人會說，這樣不是很麻煩嗎？

老實說，導入確實是一場長期抗戰。

最難的不是技術，是心智模型的轉換——整個團隊要從「IP 思維」轉到「身份思維」，一堆老系統等著你去踩坑，開防火牆 port 的工單文化也要跟著改。

但體感上反而常常更順：使用者不用再連那個慢到懷疑人生的 VPN，工程師不用再為了開一個 port 跑流程，權限用宣告式的規則管理，誰能連誰，一目瞭然。

——

寫到這裡先收個尾。

最近和朋友把上面講的這一整套——隱形服務、憑證身份、細粒度授權、端對端加密——全部包好了，甚至可以直接嵌進應用程式裡，讓你的服務天生就活在這個看不見的網路上。

我最近就在玩這個，踩了一些坑，也挖到一些寶。

這篇先當個鋪陳，到底實際故事發生什麼，之後找時間再寫吧

Code to Figma

竹子日誌（竹子） — Tue, 19 May 2026 06:30:00 GMT

當 AI 可以直接產出 prototype 來溝通需求，Figma 還有存在的必要嗎？

我的答案是這樣：只要設計師跟工程師不是同一個人，就不可能不需要溝通工具。

那你相信你們家工程師的 UI/UX 設計能力嗎？答案應該很明顯了吧。

身為設計師，這就是我們的價值所在——把規格、流程、細節用設計師看得懂的語言講清楚，這件事 AI 還沒辦法取代設計師。

——

為什麼是 Code to Figma，不是反過來？

很多人聽到 Figma 跟 AI，第一直覺都是 Figma to Code——把設計稿丟給工程師變成程式碼。

但現實是，越來越多時候設計師會遇到的場景是：工程師早就把畫面刻出來了，設計檔卻是空的。

可能是工程師自己 vibe 出來的，可能是 PM 急著要 demo，也可能是 side project 一路長到產品化，總之我們打開 Figma 的時候，程式碼比設計檔還新。

這時候要做的不是從頭重畫，而是把現有的程式碼「回灌」到 Figma，讓我們有東西可以接著做、可以接著改、可以接著建設計系統。這就是 Code to Figma 在解的問題。

——

話說回來，不管是 Code to Figma 還是 Figma to Code，我覺得核心道理是一樣的。

不要再講什麼「設計系統已死」這種不負責任的話，越是 AI 時代，設計系統的價值反而被拉得更高。

我也經常分享，設計系統不是丟出幾個顏色跟元件就自稱有設計系統，而是你要把畫面的表現、流程、準則講清楚，那才叫「設計系統」。

UI/UX 不應該是憑美感、憑經驗、憑直覺，UI/UX 是一套自成體系的「工程學」。這套工程學不是叫設計師去寫程式，而是把 PO 嘴巴裡那些「商業邏輯」轉化成可以被軟體實作的「規格說明書」。

這正是設計師的專業，也是 AI 學不走的部分。

——

來講講實務操作。

並不是丟一句「把 HTML 畫到 Figma」就好，其實還有很多東西要交代。

要先認知到，AI 是一個很聰明但什麼都不會的新人，而且跟人類一樣很愛偷懶，所以交派工作必須很明確。

第一，先把設計系統建起來

初期一定要先把 Variables、Styles、Components 建好，這是一切的基礎，不然 AI 會毫無節制地用 Frame 從頭刻到尾，你後面看了會想哭。

你一定心想「好麻煩」，建立 Design System 真的很花時間。

但你可以選擇用開源的 MUI、Antd、Vuetify 這些別人建好的，或是打造一個屬於自己風格的系統。

對設計師來說，這也是練功的最好時機——你越早搞懂 Token、Component、Variant 的邏輯，未來跟工程師對話就越順。

（關於用 AI 建 Component，這又可以另外寫一篇了）

第二，要 AI 爬網站，不如要他爬檔案

對 AI 來說，用 Figma plugin 去爬網站資訊是很累的事情。

要先請他把設計系統的資訊全部爬下來存成檔案，後面再請他閱讀。

這些檔案資訊量非常龐大，你才會知道——如果不先讓他爬下來，過程會多費力。如果是用別人的 Library，特別要注意 Component Name 不要跟自己的撞名。

第三，制定自己的繪畫習慣準則

我會逐步寫一套自己畫 Figma 的準則告訴他，包含：

「預設使用 Auto Layout」
「預設不勾選 Clip Content」
「使用 icon 請從 material-symbols 選用」
⋯⋯各種你在意的細節

AI 是不會知道你在想什麼的，你必須講出來。

設計師最在意的「畫得乾不乾淨」「圖層整不整齊」「命名規不規範」，AI 全部都不會主動做，你不講他就不做。

甚至如果你想叫他「設計」，那你就得提供一份風格的詳細資訊。因為「工程學」不講感覺，只談「規範和準則」。

可以是參考網站、可以是描述文字、可以是你的設計系統，但絕對不是叫他無中生有，那叫抽卡，不叫設計。

第四，驗證成果

AI 做出來的東西常常會偷懶，你需要去驗證執行成果。

這時候開一個 Subagent，重新讀取規則跟目標成果，讓 Subagent 擔任 QA 去驗證實作對不對。

很多沒做好、沒做到的問題，都會在這個階段被揪出來！

——

AI 會偷懶的常見坑

順便分享一下我實際遇過的「災情」，每一個都會讓設計師看了血壓飆高：

Auto Layout 該用 Hug 卻全部給你 Fixed，畫面一改就爆炸
顏色不去抓 Variables，直接 hardcode 一個 #3B82F6 給你
明明 Library 裡就有 Button，他自己用 Frame + Text 假裝一個
Icon 不去 material-symbols 找，自己畫一個歪七扭八的向量
同一個元件切了 N 個 Variant，但其實只是顏色不一樣

每一個坑，都是在你以為「AI 終於幫我做完了」之後，打開 Figma 才發現的驚喜。

所以第四步驟的 QA 驗證，真的不能省。

——

什麼時候「不要」用 Code to Figma？

也不是每個場景都適合，講幾個我覺得別硬上的情況：

純探索性設計：還在發想期，連方向都不確定，自己畫草稿比較快
沒有設計系統的新專案：你連 Token 都還沒有，AI 畫出來只會是一坨亂七八糟的 Frame
品牌視覺、Marketing 頁：那種要靠美感跟氛圍的東西，工程學救不了你，這時候才是設計師真正發光的地方

Code to Figma 解的是「同步」的問題，不是「創造」的問題。搞清楚這件事，才不會用錯地方。

——

再額外分享一些小技巧：

讀取 Browser 時，明定「HTML 結構」跟「Computed Style」這些關鍵字，會讓結果更精準。
如果開一個 Session 一直來回調整，Context 會越滾越大，讀取 MCP 也很浪費 Token，打 API 又會消耗請求額度。可以先產出中間產物的 Markdown 檔案，把你真正需要的資料整理成文字，再開一個新對話視窗，AI 才不會失憶要重新讀龐大的 Context。
目前 Figma 對於 Slot 的支援很差，需要另外寫 SKILL 強化 AI 的使用。(聽說 Q3 時，Figma Plugin 會發佈支援)

——

最後一句送給大家：

設計工具不會死，會死的是不講規範的設計師、跟不信規範的工程師。

而我們，就是那個把規範立起來的人。

#Figma #codetofigma #AI #htmltofigma #uidesign #aidesign

AI 時代的 UI 設計師

竹子日誌（竹子） — Sun, 17 May 2026 06:30:00 GMT

最近自己嘗試了一輪，也跟身邊幾個設計師朋友聊過，想分享一下「AI 時代的設計師到底怎麼工作」。

——

先講畫 Figma 這件事。

以前我們都是手工規劃需求、手工拉框、手工畫圖，慢得令人髮指。但 AI 時代開始不一樣了。

現在的流程可以是這樣：先依照 PRD 產出一份「專屬於自己畫圖用的 Spec」，把畫面風格、畫面邏輯、使用者流程先規劃清楚；接著一段 prompt 丟給 AI Agent，直接生成一個前端專案。

這個前端專案不需要交代任何技術細節，能跑、能 Demo prototype 就夠了。比起過去曠日費時的 Figma prototype，效率根本不是同一個量級。

更妙的是接下來這一步：拿著這個有原始碼的 prototype，反過來讓 AI 讀取瀏覽器 DOM 與樣式參數，再把 Figma 設計稿畫出來。

這個速度，是過去難以想像的高速。從發想需求到定稿開發，可能不用一週，甚至可以多線並行。

——

不要再覺得 AI Agent 是很遙遠的東西。

身邊已經有不少設計師、產品經理開始大量使用 codex、claude code 這類工具。剛開始當然會撞牆——突然要會開終端機、學語法、看一堆看不懂的腳本、搞複雜的插件和工具串接——但這個門檻過去之後，生產力提升絕對不是 50% 到 100%，而是 200% 到 400% 的恐怖加速。

當然速度不是沒有代價，相對換來的是大腦的高度轟炸與疲勞，會比過去更容易覺得工作累。

——

剛開始你一定覺得 AI 都在亂做：畫歪、做錯、跟你想的完全不一樣。

但這些「不一樣」正是 AI 取代不了你的原因。

你要逐步教 AI 怎麼規劃 Spec、怎麼畫 Figma，反正也沒什麼慣例可遵守，就是一步一步打造屬於自己的專屬 AI 團隊。

Token 很貴？AI 要錢？

叫公司出個 100 美金換來高度生產力，不過分吧？

如果連這點 AI 經費都要被說三道四，那就不配享有 AI 帶來的成果。

非常推薦每一個在電腦前工作的人，現在就開始入門。

——

但我還是要說一句老實話：工作上最大的瓶頸，從來都不是「製作的速度」。

真正卡住速度的關鍵是「需求對焦」。

設計需要花海量的時間確認需求細節。過去有些細節是工程師那邊在把關的，現在反而被往設計這側推；只要沒對焦清楚，prototype 就會缺三落四、邏輯不完整。

所以說白了，設計師跟工程師相比，AI 提速帶來的效益其實不如工程師。這點，只有真的在現場操作過的人才會懂。

溝通的渠道

竹子日誌（竹子） — Thu, 14 May 2026 05:26:25 GMT

過往的軟體開發之中，不同的職務溝通都依靠某個特定的文件或規範的窗口。但上下文理解其實常常有許多問題，甚至跨工具、跨協定、跨團隊模式等等也充滿變數。近期在個人的 Side Project 我和團隊導入了一個獨特的模式，符合 AI 時代的做法。

團隊中會有不同工作部位，每個工作部位互相溝通都會利用不同工具，Jira, Figma, API Doc… 各種，但成堆成山要學習的工具、看不懂的各種文件、戰國時代般的溝通接口、難以遷移的技術債，這些都是困難。

但有沒有一套溝通的接口是歷經年代遷移都不容易變化？又沒有一套工具可以基於這套通用的協定去滿足溝通上下文的滿足？

有，這套通訊協定就是自然語言的文件。而現在風行的 AI Agent 就可以基於這套些協定滿足各團隊的工具與技術差異，彌補實作上的誤差。看得懂的定義來自 AI 的驗證，當 AI 認為不再有模糊空間，那就是客觀的「清楚」，這就更容易被管理。

所以最近我開始用 Skill 作為需求傳遞的根基，從 Product => Design => Frontend => Backend => QA 整條溝通的 Bridge 由 AI 交管，文件等於通訊協定，還不用自己寫，減少思考與用詞的落差。

雖然不一定適合每個人，但我覺得這是很有趣的方法，分享出來。

關於環境變數

竹子日誌（竹子） — Sun, 03 May 2026 09:03:19 GMT

我在做前端的這段時間，遇過不少 Backend 和 SRE 對於一件事不太熟悉：前端在打包完成之後，環境變數其實就已經被固定，不會再改變。

因此，有時候會看到一些設計，要求前端在執行時去「動態介接環境變數」。

這種情況我並不是不能理解，但實務上往往需要反覆溝通，甚至要把整個機制從頭講清楚，才能釐清問題。

從前端的運作原理來看，環境變數通常是在 build 階段被注入。一旦打包完成，這些值就會被寫死在產出的檔案中。

也就是說，前端應用不像後端服務那樣，可以透過重啟來重新載入或切換環境變數——總不可能每次調整設定，就重新花幾十分鐘打包整個前端專案。

當然，並不是完全沒有解法。

其中一種做法是提供一份在 runtime 載入的設定檔（例如在 application 初始化前先抓取 config），再將設定注入到應用中。

但這種方式也會帶來額外的成本與風險，例如：

初始化流程變複雜
需要額外的設定管理機制
若處理不當，可能會暴露敏感資訊

先不討論框架或是否採用 SSR，不同技術棧會有各自的實作方式，但整體來說，這些都是前端在設計上既有且需要考量的限制。

AI 選擇性閱讀

竹子日誌（竹子） — Sun, 03 May 2026 09:03:17 GMT

前兩天說要分享一些 AI 使用的小 Tip 第一個我就要分享「我的 AI 讀 Skill 會漏內容」

AI Agent 其實並不會說你餵給他 1000 行他就乖乖讀 1000 行，而是選擇性大概讀一下，然後謊稱讀完了（怎麼聽起來人也會幹這種事⋯⋯）。但事實上他可能才讀 200 行，所以並沒有完全理解你完整上下文。

這種漏讀的行為，其實也是一種節省 Token 的機制，也不說完全不好。但到底怎做可以確保他都去讀取完整呢？

其實只要多利用「自動觸發」這件事，可以針對需求上需要對大模型 Tool Call 的節點進行拆分切分，不但可以有效降低 Token 消耗，還可以避免忽視部分訊息導致內容遺失。撰寫 Prompt 遵循「條件引導 Submodule」的模式，逐步讀取內容，這樣不但避免資訊過長導致遺失，更能讓運行更加穩定。

初期基本上還踩不到「切太細」，沒切其實是常態。一個 prompt 背後發生 tool call 次數其實比你想像的多非常多，所以切細帶來的好處是相當明顯的。

關於 AI 幫我做了什麼

竹子日誌（竹子） — Sun, 03 May 2026 09:03:14 GMT

最近上了 Claude Max 之後，完全改變我對於很多東西的使用習慣和使用態度，它帶來的便利真的是無以倫比。最重要的我覺得是把 AI 跟生活掛勾，只有這樣才會開始用 AI 來思考事情。

我覺得最近可以分享一些有趣的生活生產力用法。

故事一：把十年份的 iOS 備忘錄搬出來

我一直是使用 IOS 備忘錄，非常喜歡它的雲端同步功能，我一用用了快要十年。裡面累積的文章數量非常之龐大，總文字量高達 1GB。隨著我成為軟體開發者，我發現 git, markdonw, claude code 這些工具，這個備忘錄沒辦法成為我管理文章和資料的群集，開始想轉移，但文章數實在太多了，手動轉移真的很不現實。 AI 時代，我呼叫了 Claude Code 幫我搜尋與分析，我發現 IOS 備忘錄其實存在電腦的一個 SQL Lite 之中，我請 Claude 幫我寫一份腳本處理。我直接把資料撈取出來，再轉換成 Markdonw，改用 Obsidian 來同步，然後用 Claude 直接幫我分類與處理無用資料，敏感資料撈出來另外存放，最後用 git 版本控制。原本巨困難的任務突然變的非常簡單，這是非常方便的生產力工作。

故事二：對龐大的筆記做語意搜尋

因為我個人蒐藏的文字量實在過於龐大，不管是要搜尋還是批量修改都會無比麻煩，又不能單純用腳本處理，因為有時候有很多模糊地帶，它沒有精準的做法。這時候一樣呼叫 Claude Code ，給一個模糊的大綱做法，它能高速掃描龐大的文字，並且不是使用單純的文字搜尋，可以採用語意化的搜尋。甚至可以批量加上特定的文字或標記，管理龐大的文字。自己也可以追加一些結構化的搜尋樹和標籤，提高可被搜尋到的特徵。如此一來，很多筆記其實不用記得太過於詳細複雜，只要曾經筆記起來，就能有豐富的文字去分析和追尋，徹底做到大腦記憶外包。筆記也不需要煩惱怎麼寫，可以請 AI 當小助手，協助分析怎麼做筆記，開出好的架構，以利下次回想。

故事三：有 API 或 MCP，就交給 AI 管

只要有公開 API 或 MCP 的工具，就可以考慮讓 AI 介入處理，成為你個人的管理工具。可以處理的非常漂亮。當然，只要是 MCP 都需要有自己的 Review 機制，以免 AI 失誤或是執行出格的行為。但實際上可以節約的時間實在很嚇人，這種體感真的太爽了！

長頭髮

竹子日誌（竹子） — Sun, 03 May 2026 09:03:10 GMT

身邊有一些男生朋友都會說：「留長頭髮是懶得剪頭髮嗎？」我真的是只能翻白眼🙄 留長髮要花費的金錢和心力非常之大！

留長髮到底好在哪

留長頭髮最有趣的是變化，可以綁起來、可以放下、可以加上髮飾。還可以剪很多有趣不同的髮型，搭配帽子也有很多變化。無聊時還可以揉捏把玩(???)

進浴室的那一刻就是保養的開始

保養頭髮可能對女生來說是家常便飯，這邊就是寫給男的，進去浴室的那一刻開始就是保養的重點。

洗頭一定是洗兩次，第一次是洗掉髒東西和頭髮上的皮脂，第二次是把頭皮洗乾淨，我會特別用洗頭皮的洗髮乳。

接著是每日的護髮保養，每天都會上護髮。擠乾頭髮上的水之後把護髮平均擦拭在髮絲，不要碰到頭皮，然後還要放置2～3分鐘（可以做別的事，洗臉、洗身體、去角質之類的）。每週還要上1～2次的髮膜，流程跟上護髮一樣，每次也是要放置5分鐘。

出浴室之後：擦乾、吹整、上髮油

洗完澡要擦乾頭髮不能用搓揉的，要用毛巾擠壓把水給擠出來，出浴室要儘早吹頭髮。吹頭髮前可以可慮上髮乳，但我覺得效果還好。我現在的頭髮長度大概也要吹12～15分鐘，熱風吹完建議用冷風邊吹邊梳，這樣會更順。吹完可以上一點髮油去維持，但不能上太多，不然會更油膩。

踩過的雷：先搞懂自己的頭皮和髮質

我本身頭髮粗硬一點（普通而已），頭皮偏乾燥，有脂漏性皮膚炎問題。剛開始有點踩到很多雷，因為不清楚自己的頭皮和頭髮的個性，很容易買錯產品。如果使用了覺得狀態變差，代表著項產品不適合自己。

頭髮就是會打結，不要硬梳開。吹完頭可以放一下等待冷卻再從髮尾梳開，不然就會慘烈斷髮。

漂髮、染髮、燙髮一定程度都會傷到髮質，傷到了要救回來就非常困難了。所以即時想燙頭髮，要注意頻率，經常燙燙燙真的很傷。

每天要洗頭，我知道很麻煩很麻煩，但不堅持這件事，少洗一天要多三天救髮質。如果真的很累很累不想洗，那建議隔天早上一定要洗，才不會炸掉⋯⋯

男生天生比女生會掉頭髮，那是賀爾蒙的問題。不要聽什麼女生比男生會掉頭髮這種鬼話，當男女生都是長髮時，男生比女生掉的更嚴重！

幾年下來，總算找到合適的產品

經過這幾年的努力，嘗試過不同的洗髮護髮品牌，慢慢找到自己合適的產品。目前的頭髮雖然不比那些藝人或是常常跑髮廊的人，但也比很多人的頭髮都好很多了。目前的髮質是很多人認證，真的保養的不錯！

希望想留長頭髮的男生可以參考參考。

Vibe Drawing

竹子日誌（竹子） — Sun, 03 May 2026 06:30:47 GMT

現在大家都鼓吹 Vibe Coding，但隨著工程師使用 AI 的比例提高、模型的聰明度增加、更多的 Skill 技巧，似乎嘴砲造一個產品不再是難事。

但為了對齊溝通的橫溝，Figma 這類工具仍然佔據非常重要的角色。除非你完全信任工程師產出的流程和美感，否則 Figma 仍然是當今地表最強的溝通工具。

AI 當道的今天，寫程式完全嘴砲了。設計師想快速產出 Prototype 也可以完全靠嘴砲，分分鐘鐘東西就可以被產出，快速對齊想法和可行性。

但設計稿怎麼嘴砲寫呢？為了做到這件事我洋洋灑灑寫了很多 Skill Rule 去解決 AI 產生不順利的問題⋯⋯

我的 Side Project

竹子日誌（竹子） — Sun, 03 May 2026 06:30:47 GMT

經歷無數風風雨雨，終於完成一個高完成度的 Side Project ，目前已經走到 MVP 完成的雛形。

過程包含理解商業邏輯和網路架構，跨度各項領域的知識。從商業模式、產品規劃、使用者介面設計、服務體驗設計、網頁前端工程、桌面應用工程⋯⋯各項領域技術應用。也整合各種 AI 工作流、產品人性化、技術產品整合等等軟技能整合。

其實真的太多很有價值的東西可以分享，但有些東西很難三言兩語說清楚，有些東西因為想要商業化不能透露太多，我未來可能酌量分享。

老朋友有興趣可以直接找我聊，網路上我就針對技術面和經驗值做討論分享。

Claude Channel 很酷，但也就這樣

竹子日誌（竹子） — Wed, 25 Mar 2026 16:00:00 GMT

我真的很喜歡 Claude，上了 Max 之後整個工作流被改造了一輪，這點我不否認。

但最近出的 Channel 功能，我玩了一陣子之後，老實說⋯⋯蠻雞肋的。

概念很酷啦，可以透過 Telegram 之類的通道跟 Claude 對話，感覺像是隨時有一個 AI 助手掛在線上等你。聽起來超棒對吧？

實際用起來，問題一堆。

電腦睡眠，斷了。閒置太久，斷了。訊息漏掉了，沒有任何補救機制。沒有重試、沒有 queue、沒有持久化。本質上它還是靠你本機跑著一個 process，然後透過 API 觸發回應⋯⋯

說白了，這不就是一個沒有 uptime 保證的本地服務嗎？

如果要讓它真的可靠，你得自己處理斷線重連、訊息持久化、背景常駐⋯⋯但等等，如果我都做到這些了，我幹嘛不直接架一個正經的服務？自己開一台 server，掛一個 bot，接 Claude API，穩穩地跑，不是更踏實？

這就是這個功能最矛盾的地方。

要讓它好用，你需要補足的東西太多，多到你補完之後會發現：「欸，我已經不需要這個功能了。」

我知道每次有新功能出來，一堆 AI 相關的文章就開始吹。什麼「改變工作流」「生產力翻倍」「未來已來」⋯⋯

拜託，冷靜一點。

玩過才知道能不能用，用過才知道好不好用。不是每個新功能都值得寫一篇「我靠這個功能提升了 300% 效率」的文章。有些東西就是還沒到位，講出來不丟臉。

我覺得 Claude 團隊的方向是對的，讓 AI 更貼近日常生活的使用場景，這個願景很好。但現階段 Channel 的體驗，離真正好用還有一段距離。

與其吹捧，不如誠實地說：這東西還早，等它成熟再來也不遲。

不然到時候一堆人照著那些文章設定完，發現根本不穩定，又是一波「AI 不過如此」的反彈。這種來回，對誰都沒有好處。

（實驗性，本篇文章是 AI 產生）

自我的發掘

竹子日誌（竹子） — Mon, 09 Feb 2026 10:41:18 GMT

如果你是做技術的相關領域，那你大概率也有這樣的症頭。大腦不自覺想凸顯優越感，你下意識會不斷搜尋缺點和問題。這不是一個缺陷，而是養成的結果，自然而然的「專業舉動」。

但隨著時間堆疊，你會遇到方方面面的各種問題，這樣的思考模型會讓你阻礙不前，也會讓你在人際關係受傷。當你拿著一把武器四處開殺，那麼大家總是防著你，深怕你那一刀剛好砸在心頭肉上面。

面對企業的生存戰場，發現問題的洞察能力和解決問題的能力可以說是一套好用的裝備。然而在人際相處、人員管理、溝通協調這種充滿人性的世界中，這套裝備顯得不太管用。

最近遇到一些人事物，覺得讚美是人與人之間的潤滑劑、發現優點是一個掘金的探測器、正向思考可以好運的吸引機。工程師的我跌跌撞撞，總是用工程腦袋思考的我時常常遇到很多問題，但其實這都是被過去經歷教育的，因為這套是「生存武裝」。然而隨著面對的社會更多了，我感受到這套武裝力不從心，沒辦法處理那些人與人之間的問題，因而我開始探索其他出口。我慢下腳步，其實人比起那些事重要多了，但怎麼做才可以兩者顧及？這才是困難的。

開發登入系統

竹子日誌（竹子） — Tue, 27 Jan 2026 05:19:55 GMT

我想很多人開發過線上系統時肯定都開發過「登入系統」，除了帳號密碼登入、帳號註冊、二次驗證、忘記密碼、第三方登入各種方案的組合拳。

這是關係使用者對於系統的第一印象，關係甚遠。

使用者未來會開始使用？

使用者註冊後帳號是否安全？

未來系統漸進式拓展功能是否有空間？

有沒有辦法第一眼呈現出產品調性？

會不會跟其他類似系統搞混？

相信身為一個產品設計一定很在乎這些事。

然而，登入系統可大可小，每個系統在乎的細節有所不同，每個公司期待的業務邏輯也有所不同。

但是，我今天想講的是。

無論是當工程師的時候還是當產品設計師的時候都有遇到這件事。

工程是開發登入系統多少會想要用，不管是 Auth0, AWS Cognito, Firebase, Keycloak 等等，都是很好用的工具，省時省力。但問題在，要客製化時就會感覺到不方便。

比如説要細緻化 UI Flow 時，受到各種 API 的限制和架構的綁定，要改變它的流程時就會感受到不便利。

比如説要做自己品牌調性的系統 UI 時，還是得轉成純 API 溝通的架構。

身為工程師當然覺得難道不能照著 Library 的基礎走嗎？

身為產品設計當然覺得我都投資成本規劃了，難道不能完全做到一樣嗎？

不同位置有不同的視角，每個位置看到的資訊都是有道理的，最後對於整個產品帶來最高的貢獻決策很重要。

不管你是產品設計還是工程師，我真覺得站在不同的角色上才能看到更全面的資訊，挺身做出最有商業價值的決策。

我的故事

竹子日誌（竹子） — Sun, 28 Dec 2025 10:38:22 GMT

學校畢業後我第一份工作是去當職業軍人，其實就是海軍官校畢業去服役職業海軍。當時在就是在諾克斯驅逐艦服役，任務大部分就是出航巡防。當時做輪機相關的工作，所以其實也是一身技能。看似不錯的工作，但其實壓力很大，真的是很不愉快的工作，我也是咬牙苦撐期滿離開。也經過六年的軍旅生涯退伍後，當然最大的煩惱就是未來該做些什麼。

一開始時退伍幹的是保全相關職務，利用在軍中的一部分電機維修的技能，我去找相關工作。因為人住在高雄，為了更豐富的工作機會，我就都在前往台北找工作。最後在朋友介紹下我找到了機電值班的工作，也因為表現優良被提拔去豪宅擔任社區幹事處理大樓管理的工作內容。我也經常用自己私人時間去接一些水電維修的案子，慢慢去累積不同的技能方向。

從傳直銷繞進 Wordpress

我一直告訴自己，我必須要證明自己退伍後可以活得更好，一面工作努力養活自己不要揮霍退伍金，一面玩著傳直銷希望能透過它賺到些錢。既然要賣些什麼，我會去思考一個推銷產品的流程隨著，思考並推演可行的做法。隨著思考和嘗試，我理解到必須要學會網路行銷推廣產品。

最後我在這過程中認識了 Wordpress ，這是我打開這條路的契機。

因為傳直銷，我研究怎麼曝光自己，意圖想要用網路行銷的手法。

我規劃了一套屬於自己的產品推銷的漏斗，用 Wordpress 建了一個屬於自己的部落格，弄了一個一頁式的產品行銷網頁，搞得有一個起頭的樣子。包含設計了簡報、影片、自動寄信…很多東西。然而只是做出來是不夠的，接著會想，我應該讓頁面更漂亮，想要更多功能，下一步就是要學 HTML 和 CSS 了。但是網路上的資源之凌亂，這學習的過程真的是坑坑疤疤，簡單調整一個顏色讓我搞了好幾個小時，這時我想要有一點系統的學習。

花錢去巨匠學 float 切版

我花了錢去巨匠學習如何切版，其實真的花不少錢。當時根本不知道有什麼網路學習資源，而且還是學「float」這種古早味的切版模式。不過還是「入門」這領域，一些基本的學習資源，如何去搜尋知識。有了這些關鍵技能後，我覺得對我自學能力又多了一分突破，某種層面也是一種開始，就著樣栽入網頁開發的世界。

在補習班上完了3個月的套課，其實我仍然什麼都不會，最多也只是能切出粗糙的版型和用 jQuery 做出基本的互動，連什麼 RWD 都是懂非懂。學習沒有捷徑，我也只能開始我的瘋狂的練習之路。下班後其實已經超級超級疲累了，要能堅持學習是一件極難的事，每一天我只能拖著疲憊又有點想打瞌睡的狀態持續學習，日復一日下班都在練習。除了下班，假日或其他各種休息時間一面堅持要寫文章，一面還得練習網頁撰寫，研究各種想達成的功能，我只心想「我要賺錢」。

自學一年半，還不知道有「前端工程師」這個職務

就這樣輾轉過了1年半，中間換了幾次工作，也放棄了原本開始寫網頁動機的直銷，甚至跑去和朋友創業搞有的沒的，但我仍然持續這件事。經歷在職學習的漫長路程，一步步熬過跨領域困難，甚至當時我跟本不知道有一個職務叫「前端工程師」。我抱持著對於這門技術學習的堅持，我用盡當時會的技術嘗試去寫一個網站，自己租了一個伺服器和網域，把資料上傳到cPanel，我連什麼是 github 都不知道。

我就是在這種懵懵懂懂的環境下學習，也不知道自己是學的對還是錯，身邊也沒有相關產業的朋友，更沒有任何資源，從頭開始自學。

直到，終於到了某一天我知道了原來這是一門工作，我可以投履歷找「前端工程師」⋯⋯

破釜沈舟的海投，薪水鎖在 30k

在那個時間點上，當時我創業失敗、投資失敗，導致資金和債務問題接踵而來，我只需要一份工作要先維持收入。我當時根本沒考慮過公司的好與壞，我只知道，我要找到工作，抱持這樣的決心海投履歷。帶著破破爛爛的作品，當時我css只會 float，js只會簡單操作 jQuery，不要談什麼物件陣列我根本不懂，薪水鎖定在大台北30k~35k這樣的低水平，抱持破釜沈舟的心告訴自己一定要找到一份前端工作。我借了一台大學生用的破爛筆電，免強能讓我DEMO作品，履歷粗糙的寫了一份，一次次的面試就這樣衝了。

當時我面試了很多間公司，每個都因為我沒有團隊合作經驗和能力不足甚至不會框架打槍我，也犯了許多現在想起來很糟糕的求職大忌，但我依然堅持去嘗試。我從台北中心投到內湖，東從汐止投到西邊的林口，北從士林投到南邊樹林。反正無一不投，只要有機會我就去面試，薪水什麼我根本不在意，公司說要加班要砍價我根本無所謂，我只知道我要轉職成功，先拿這張門票。

最後發我offer 的是在土城的一間小接案公司，公司組成是後端＋企劃＋老闆(會寫code那種)這樣的簡單組成。我找了一間在板橋河堤附近的小套房，一間環境不是很好但便宜勉強尚能居住地方，又離捷運算近。我當時最後核下來的薪資是32k，真的已經超開心了，也開始我的前端之路。

第一份工作：32k、冷門框架、什麼都學

第一份工作拿了 32k 薪水的 offer ，我開始了前端工程師的道路。實際上了工，依照我的能力工作內容是設計做圖和前端切版，慢慢從我能做到的工作去執行工作。後來又有了PM和設計加入團隊，他們們可以說是專案的核心，所以只要是他們兩個開口我都要想辦法，沒有所謂做不出來這件事，極力要求自己的切版能力和程式能力。甚至後期我要學後端，當時是使用 C# ，不時也要幫客戶去資料庫查詢改資料，什麼都學。最特殊的是，公司是有導入前端框架，但並非大家熟悉的三大框架，而是一門冷門框架，我依照公司的要求學習並且使用。

我當時的生活大概就是上班工作，下班吃飽了一直在學習，不管是找 youtube 的影片還是讀文章，不然就是去看原始碼和練習寫輪子，放假也是泡在寫程式上面，平均一週扣掉上班也花上超過30小時在學習上，就這樣堅持到快一年。當我第一份工作越來越感到艱難，不止越學越多，薪水還卡在超低的水平，公司沒有更充足的資源讓我學習前端。我知道我要前進必須轉換環境。我發現我根本不懂 JS ，我也發現我用的技術和現在主流的前端界脫節，我必須自己獨立學習。但是，找下一份工作勢在必行。

我又再一次去海投履歷，我需要換工作。

用冷門框架的人，在面試裡等於什麼都不會

我發現我遇上另一個困難。我依然被判定完全不會框架，因為我使用的是冷門框架，等於什麼都不會的新手被看待。我知道我必須去學習框架，經過多方爬文，我大概知道我要去學 React ，但根本沒人教我應該學什麼 hook API 我硬著頭皮爬官方文件學 Class Component ，我真的覺得好難好難。可能有人覺得我可以去買課程，但是我根本沒有錢，要還債務和台北的房租，我32k 的薪水根本就吃不消。

我就知道我必須去尋找其他學習資源，哪裡有好的 code 讓我學習？我第一個想到的是 node module。成千上萬的 code 讓我學習，我死嗑每一行，爬到最內層依賴耦合的函式，看不懂的 native function 去 MDN 上找，再看不懂就打開 js 檔跟白痴一樣 try error ，直到弄懂為止。

很幸運找到第二間，也很不幸找到一間很雷的

很幸運的，我找到第二間公司。

也很不幸的，我找到一間很雷的公司。

我到了一間10人左右的小公司，薪水台北是 40k。

上工第一天，我的任務是一天切出整個後台的 html 版，瞬間心想…怎麼可能？後面甚至有一週串完整個前台api 這種瞎扯淡的需求。無論是什麼要求，我都照單全收，加班完成工作弄到半夜都不是稀奇事。第二份工作就順利嗎？我當時連個 api 都不會接，http request 的 header & body 我根本搞不清楚，git commend line 我也是下班後惡補，什麼 gitlab 和 slack 這種工具我根本不會用。最重要的是框架，公司使用 vue ，我完全不會，每天下班都還是死嗑文檔，想辦法讓自己在最短的時間學會框架。

大家心想，沒有前輩教嗎？

還真的沒有，當時有3個前端，我最菜。但其他人不要說 vue ，連 js 都有問題。不要說 vue-cli，都還在寫「義大利麵」(意指將前後端 code 混寫在同一支檔案)。不要說 gitflow，有大半專案還在 ftp 和 zip。但爛歸爛，但我確實成長很多，慢慢懂得團隊協作，我努力讓自己成長。我也加入了前端社群，開始覺得自己是前端圈的一份子。就在一切都還在前進，我甚至覺得稍稍有點起色的同時，我發生了人生一個大轉折……

我車禍了，左腿斷了三節

我車禍了，左腿閉鎖粉碎骨折斷了三節，進醫院躺了整整一個月難以動彈，我接下來該怎麼辦？

發生車禍後當下可能還不知道自己會那麼嚴重，昏昏沈沈的過了當晚，隔天才知道自己左腳骨折。手術後在醫院躺了一個月，動彈不得，連翻身都有問題。出院後真的沒辦法工作，好不容易找到的新工作就沒了，只能靠著存款和保險餘額先撐著。好不容易一切看似都改變，卻又因為車禍導致什麼都失去，覺得這世界好過份。

我告訴自己，我現在能做的就是繼續強化自己的技術能力，我把除了復健養傷以外的時間都放在寫程式。剛開始幾個月，每天大概只能寫 4個小時左右的程式，我身體根本支撐不了更久。這種過程，有種重心失去的感覺，不知道自己究竟是為了什麼在努力，不清楚自己是在追求什麼。為尋求內心的慰藉，我把大部分休息的時間放在社群上，解答網友問題和瞎聊天。

躺著也要寫程式，然後接到了遠端工作

過了好一段時間，我接到了網路的零散案子，我終於接到受傷後的第一個案子。我跟客戶來來回回釐清需求，我目標只是想把案子處理好，其實需求本身並不困難，但我卯足全力想把它給做好。但很意外的地方是，我的公司隨著時間發生人力不足的問題，提出要讓我可以遠端工作的想法，當時沒工作的我當然是沒問題囉！

當我自己開始工作後，剛開始是很開心，我終於有一份工作，但這也是疲憊的開始。我住院後，老闆尋找前端工程師一直不順利，所以在極缺乏人員資源的情況下我用遠端的方式回到工作崗位上。

重新開始工作的感覺很踏實，極盡所能去追趕去努力，想把工作做好。隨著人員一個個離職，工作壓力逐漸上升，加班的情形越來越嚴重，我意識到，我沒辦法繼續在這個工作上。我開始每一次休假就拼命練習程式，做一些未來要求職的作品。

從無聲卡到國外遠端的 offer

重新求職其實多多少少也挫折滿滿，因為我受傷的緣故，我必須找遠端工作性質的，或是從可以暫時遠端的選擇，從剛開始各種無聲卡到有了 offer 逐漸找到信心。就在最無意間某個國外遠端的工作，一路從一面一直到三面到錄取，對它抱持半信半疑的加入這份工作。

之後的一段時間，我過著自由自在的遠端生活，很開心能來到這份工作。理想的薪水，自由的遠端，壓力不大的工作，我非常開心！

我學習程式的啟蒙

竹子日誌（竹子） — Fri, 19 Dec 2025 14:25:58 GMT

你是怎麼樣開始學習程式的呢？

我雖然是近年才開始轉職然後轉職軟體工程師，但啟蒙我學程式的概念其實是「魔獸爭霸3」的地圖製作編輯器。

眾所皆知，魔獸三國、信長等等經典大作是由魔獸爭霸強大的地圖編輯器做到的，有一些超乎常人的奇才用創意做到，超乎水準的遊戲設計、美術建模設計、程式觸發器設計等等能力組合才能夠完成這個曠世巨作。

當時，我花了很多時間研究那些花裡胡哨的技能是怎麼被研究出來的。

「跳斬」這招是怎麼被做出來的

舉例来說，很多遊戲都有的「跳斬」技能。你可能以為都有魔獸內部技能可以套用，事實上根本沒有這種東西，那它是怎麼被做出來的呢？

首先遊戲內有所謂的「空技能」，你可以自由定義那一招施展的距離、顯示技能範圍 UI、消耗、詠唱等等設定，但事實上沒有任何實質效果。所以我必須要在技能施展當下去播放我們常見的「大劍師」角色的「爆擊動畫」，並且精準計算動畫播放完的時間長度去移動角色到指定的攻擊目標。但如果你直接移動角色，角色是會「瞬間移動」的。在當時哪有什麼「移動過渡動畫」，那你只能採用「動畫原理」去播放它，每 0.16秒去移動一點點距離，連貫起來就變成移動的動畫，並且暫時賦予「飛行」並調整高度去產生出跳躍的錯覺感。最終，角色在到達目標點結束一連串的動畫，這時才會計算角色周圍的敵人碰撞值是否在範圍內，給予技能的打擊傷害。

做得出來還不是最難的，優化才是

只能做出炫泡的技能就好？其實實際做出來還不是最難的，還有優化問題。

當我完成各種酷炫的技能後，戰場的英雄打的非常精彩，正當你沉浸在成功的喜悅中，慢慢問題就產生了。遊戲運行了 1~2 小時後，慢慢會顯現出效能不良問題，所以是因為什麼呢？

一樣拿跳斬動畫來舉例，我每一次「移動角色」都需要建立一個 class 叫做「Point」，它有「 x 」、「 y 」兩個屬性可以把作戰單位放上去。我次施展跳斬時，每 0.16 秒都得建立一個 Point。如果場上有10 個會跳斬的英雄，平均每分鐘會施展 6 次，每次施展會建立90 個 Point，那一個小時會有 324,000 個 Point。對，聰明的你已經知道，要把它「Free」。但當時身為非相關科系的高中生怎會知道呢？這又不知道花多少時間研究了…

還有一堆眉角：存檔編碼、劇情演出、3D 建模

其實還有好多好多眉角…

包含存檔功能有編碼知識，還有各種程式計算和應用…

劇情動畫牽扯動畫演出，編劇、節奏…

角色美術還有 3D 建模問題，還要沿用既有角色的 Rig 去活動…

那真是一段有趣的回憶，當時朋友以為我設計遊戲只是打打嘴砲，但當我真的做出來看到他下巴掉下來的表情多有成就感！！！

你也玩過魔獸爭霸的地圖編輯器嗎？希望你也可以跟我分享一些回憶～～

資安漏洞遠比你想像的還要多

竹子日誌（竹子） — Sat, 22 Nov 2025 09:59:38 GMT

日前我和一位滲透工程師聊天，我才知道，原來資安漏洞的問題可以那麼多。原來，不是你的系統資安嚴密不可突破，而是你的系統不夠有價值讓人去盜竊。多數情況的各種軟體其實資安充滿漏洞，先說結論，其實只要使用主流的開發框架，並且遵守許多開發常規，其實資安沒有那可怕。但就是很多人自以為自己懂而任性妄為，導致資安漏洞百出。但也確實有很多小細節是做那麼久都不知道，但也是別人說了才知道。

資安就跟保險一樣，說到底是預算問題

資安其實就跟保險一樣，沒事都沒事，有事很大條。到底要花多少成本在這種東西上？就跟「保全要請多少人？」、「保險要買多大額度？」都一樣是一個沒有正確答案，單純是預算問題。能做就做，做越細越好。其實單純是成本問題。

雖然不會很全面，但可以參考一下。內文我就針對幾個，一定要分享的高價值資安觀念。

五個一定要知道的資安觀念

前端沒有秘密，只要是在前端的東西，都存在各種辦法被反編譯和盜取。所以前端程式碼要經過壓縮再編碼，如果把具備可讀性的原始碼完整曝露，等於無成本拱手把弱點捧給滲透人員。
只要有 I/O 就有破口，程式運行操作之中，最容易被攻陷的地方都是 I/O 口。包含向後端打請求、操作外接設備、讀取二進位的實體檔案等等，這些都存在弱點。舉個例子：雖然 Https 有加密，但只要在 Application 就是曝露出來的，可以輕易被任何外掛或惡意程式操作。包含請求送出前或收到後，都有可能存在漏洞。敏感資料盡量先加密後再過 I/O 。舉凡密碼、信用卡、驗證碼⋯⋯各種極其機密的資訊，通通有機會在這個階段被盜取。
不要輕易使用來路不明的第三方程式，包含瀏覽器外掛、外部連結（不同 Host 之下的來源）。這些都是有機會被攻擊的破口，輕易交出一個可以被操作的漏洞。
理論上 Client 只能看到屬於自己的資料，但確實有可能某些狀況看到別人的資訊。只要是任何人都可以操作的輸入框都可以是被攻擊的弱點之一，如果輸入的內容又是任何人都可以任意進行輸入，等同於開了一個讓別人可以跨站攻擊的破口。只要是來自前端任何請求，後端應該要做的是「零信任原則」，一定要做資料安全性驗證。
所有可以寫入 HTML 的字串無論前後端都應該檢查，因為 html 本身就具備各種執行邏輯，所以只要掛上指定的字串本身就有一定的危險性。如果掛上的字串本身又是後端提供的字串，而這段字串又是透過使用者輸入，這就可以構成攻擊破口。最常見的就是在 link 和 src 等等地方注入 JavaScript 攻擊腳本。

Frontend 和 UI/UX 整合

竹子日誌（竹子） — Thu, 20 Nov 2025 15:36:29 GMT

既然開始寫 Spec，也要開始畫 UI。工程師背景的我就想要找找有沒有 Open Source 的資源，也想找各種整合資源。

原本在想 Material Design 和 MUI 本身就是高度整合的組合，理所當然認為有豐富的開源資源可以用，可以快速幫助開發。身為工程師背景的我，原本想要用熟悉開發生態這件事，用最少量的設計去快速完成基礎的介面。

但似乎沒那麼簡單⋯⋯

因為實際上在「UI 設計」的領域中，並沒有那麼多免費資源，資源與前端的整合度和同步速度有非常大的落差，在整個設計資源中對於開源這個角度並沒有像是工程師圈這麼蓬勃。所以我大概能理解「造輪子」的現象似乎有點普遍，因為免費資源的匱乏和與工程對齊等等都有頗大的誤差，最後不免要在設計稿和工程師所使用的 UI 兩者不斷對校。

雖然 Figma 已經努力用各種方法消弭「開發」和「設計」的距離，但真要說對齊恐怕還有一段路。實作過程中還是各種綁手綁腳的感覺，也或許是我帶入太多開發思維，也或許是我還沒找到方法⋯⋯

光是權限管理系統就很複雜

竹子日誌（竹子） — Thu, 20 Nov 2025 15:35:45 GMT

其實不管什麼網站，只要有營運需求，管他是 B2B 還是 B2B2C，都會有建「後台」的需要，這個後台是用來營運管理前台的。

但通常後台都會需要一個權限管理的功能，而軟體業界都會習慣用「RBAC」的權限管理架構。設計上普遍會包含 User, Role, Permission 三大區塊，並且包含登入功能。

初步是這樣規劃沒錯，但其實比想像中複雜⋯⋯

但一個 RBAC 有多重解釋，並不是標準答案。因為問題不是原本想的那麼簡單，在管理架構中不只如此。

角色權限賦予只要有權限就可以任意賦予嗎？答案顯然是不行的，所以需要檢查它自身角色與所屬的權限大小來決定他真正可以賦予給別人的權限大小，正是權力下放的概念。

即使你擁有各種權限設定的能力，仍然不能任意賦予各種權限給跨部門的人，所以還需要組織管理的邏輯，去限制不同部門之間的權限控制，這就是組織管理功能。

權限本身也有層級關係，比方說你必須有「閱讀權限」才能有「編輯權限」，也必須有「編輯權限」才能有「刪除權限」。權限本身是有一定程度的關聯性和綁定，並不是完全平行關係。甚至有時候依照業務邏輯還有可能出現各種獨特的行為。

雖然前面提出了各種規劃中發現的問題，但終究是鳳毛麟角，有的甚至難以文字表達。當然，實際要寫進 Spec 跟後端溝通時的困難就是另一個故事了⋯⋯

正所謂隔行如隔山，不同的專業項目需要很多眉角，我只是借助工程師的邏輯能力去快速掌握這部分知識點。

這只是一個外行人的分享，如果有專業的產品大大可以補充就太好了。

沒講就不做

竹子日誌（竹子） — Sun, 16 Nov 2025 00:50:25 GMT

雖然這問題曾經提過，但無論時空變遷還是值得討論。

今天有個使用者，因為太久沒有操作畫面，導致 token 過期被強制登出，所以回到登入頁面。

請問這名使用者重新登入會到哪？

首頁
剛剛被踢的頁面

如果你是使用者，你覺得是哪個？

其實兩個答案都很合理

其實兩個答案都很合理。

對使用者，它做事情做到一半，當然會覺得我重新登入可以做剛剛的事。

但事實上預設情況都是首頁，但許多使用者已經被養壞習慣，已經預設會回去剛剛被踢的頁面。

有的人會說，Spec 要講清楚啊！

我所開過的網站中，認真說只有5%的PM會有明確告訴你他想要怎麼樣，大部分的 PM 是不會寫進 Spec，有的人甚至內心已經預設兩種答案的其中一種。

有的人會說，要有 Refresh Token 啊！

過去經驗，有多少網站有把 Refresh Token 或是說把 Auth2.0 機制做完善？也甚至很多網站根本不是使用 JWT，而是其它的機制或是自建的編碼。

「有問題就要問啊」，但問得完嗎？

當然有人可能會說有問題就要問啊！

其實有豐富經驗的工程師都知道，開發過程類似這樣的問題多如牛毛，有時候真的跟找碴一樣。真的每一個疑惑都要問到非常清楚，問到都沒問題，幾乎不太可能⋯⋯問到飽可能一整天都陪著你耗，問完筆記都可以當另一份 Spec。

也曾經有人跟我抱怨「問那麼多幹嘛」

也有人要求我「先做再說」

也有人覺得「這不是應該的嗎？為什麼不做？」

所以多半開發時還是慘雜很多很多通靈⋯⋯

但更現實的是政治問題。

多做了，是你自己負責自己的行為。

多問了，就有人幫你背書。

顯然是不同部門在責任歸屬上要去劃分權責。

講到底，這是立場問題

這個問題延伸到後面我想談的是立場。

需求方，產品經理、產品設計、UI/UX

開發方，工程師

需求方希望東西更有效率，希望一些理所當然的常規行為可以工程師能先處理好，後面可以再微調。

維護文件勞心勞力，與其計較一字一句，產品能快速產出及早獲利會是更重要的。

開發方的立場呢？

如果求快沒有規劃好，可能期程不變的情況下要把想辦法趕工把問題修復，因為 Bug 責任歸屬是開發，但求快跟穩定這兩件事其實是有一點點衝突的。

開發要是擅自決定把功能做好做滿，但 Spec 沒有定義，這叫做「擅作主張」。出了問題又是全開發部門承擔，擅自多做的人就是出頭鳥。

大家都沒有錯，溝通、諒解、互助，這才是一個團隊最重要的事。

當我作為一個產品設計師時

竹子日誌（竹子） — Sun, 16 Nov 2025 00:49:22 GMT

近期幫朋友規劃他們家的產品，真的覺得 PM 要直接從無到有產出「Spec」是一件非常困難的事，特別是對這個商業模式還不夠熟悉時，這會是需要反覆修正的東西。

我覺得 wireframe 真的是很重要的東西，它能快速溝通，快速展開對一個東西的想像。我真心覺得一個 PM 真的需要畫 wireframe 去跟夥伴、源頭需求方溝通，可以避免輕易進入開發導致的額外開發浪費。

或許有些人認為，與其浪費時間畫 wireframe ，為什麼不直接畫設計稿？反正也會反覆被修改、反覆被提起介面設計問題。我不能否認有這種狀況，但我覺得那是一個幫助思考的過程，及早阻擋一些明顯的邏輯謬誤。

後面還有很多值得分享的事情，我再逐一分享吧！

竹子的日記 Day02

竹子日誌（竹子） — Sun, 09 Nov 2025 03:44:19 GMT

AI 的時代，學什麼都容易，我不應該一直在「前端工程師」這邊拘泥，我想要更大幅度的跨出我的腳步去嘗試別的東西。

竹子的日記 ep01

竹子日誌（竹子） — Sun, 09 Nov 2025 03:30:42 GMT

沉寂了一下，我整理好自己，我知道我應該用什麼態度面對社群。追逐某個東西其實是有點糟糕的，最後只會迷失自己。我應該做的是展現身為軟體工程師的驕傲，認認真真的去分享。

我不打算追逐話題，打算把這裡當作學習筆記。每一天的學習，每一天的技術研究，每一天都可以有點點的進步。有時候沒空，忙了、累了、懶了就隨心所欲的關閉這一天。我其實不是像很多人想的全天候都在研究技術的人，還是會有需要充電的時刻，但還是得努力成長和往上爬，希望自己更有價值。

真的太多事情在網路上不適合說，私人的事情、公司的事情、商業的事情，我經常要去包裝潤飾，避免侵犯到其他人。但我也不會樹立一個高不可攀的人設。我會有累的時候、有情緒的時候、任性的時候、疲勞的時候。在 AI 和網路寫手橫行的時代，這是一個更加真實、有人味、有個性的帳號。

我不想被日更綁架，也不想被流量影響，不定期更新。期待能夠在 threads 上繼續與你互動，聊聊看這個世界的觀點，一起學習成長。

關於我與前端無關緊要的分享 Day 58

竹子日誌（竹子） — Mon, 27 Oct 2025 13:29:16 GMT

這幾天想了很多東西，開始在思考我接下來要怎麼去經營這個帳號，覺得有點迷失方向。我休息了幾天，慢下腳步，我覺得我太過於急躁不安了。

我暫停我手上目前的開發，看了看近期更新的東西，我覺得我應該要重新審視一下⋯⋯

關於我與前端無關緊要的分享 Last Day

竹子日誌（竹子） — Mon, 27 Oct 2025 03:25:42 GMT

這幾天回了故鄉找老朋友，上次與他見面大概是去年的事了，聊了很多很多事情。有辛辣的，有嚴肅的，有感性的，但蠻多內容真有點敏感，不是可以在網路上分享的。

不過倒是有一點我覺得很值得說。

人終究是有情感的生物，有想法、有情緒、有感情，狀態有高有低。但網路真的沒辦法任意當作情緒抒發出口，經常一個情緒上來就講了不該提的事，我覺得我深刻檢討。

去年因為職場的不順利，接連發生波折，其實低落很長一段時間。而今年看著後輩的成長與突破，看著後輩達到我未達到的高度與結果，雖然替這些後輩高興，但真有點不是滋味。常常自我懷疑我是不是不如人，能力不足？影響力不足？甚至是覺得其實得到一切都是假象。

那陣子，我一度想要用不太好的方式追求流量，也用了不太好的方式在網路抒發情緒，我也因為很多因素我稍微淡出過去喜歡的幾個社群活動，積極度相較去年弱不少，載浮載沉。

其實每天寫文章莫名其妙也給了自己很大的壓力，每天卷技術也是給了自己很大的壓力，每天光應付工作不夠還要被社群網路綁架情緒。我覺得過去自己說錯不少話，突然也蠻沮喪，我真的感覺我應該沉澱一下。

所以，我覺得我應該停止日更，讓自己緊繃的情緒鬆弛。我想我會開始比較沒有那麼緊湊的更新，但我還是會分享一些深度的經驗文章來幫助更多人。

如果你喜歡我哪一段斷更的文章，希望你給予我一點回饋，也許我會重啟篇章。那或許是我重新出發的方向，這陣子應該是佛系更新，不會像這段時間如此積極更新文章。但我不會中斷我寫寫作的習慣，我還是會持續更新一些自己的經驗談，也許哪一天看到什麼有趣的讓我發文。

關於我與前端無關緊要的分享 Day 57

竹子日誌（竹子） — Sun, 26 Oct 2025 23:47:19 GMT

這個系列是有一點過去的故事的。

前些陣子很流行 Frontend infra，我非常著迷在相關的技術和研究中。原本是當初想要做成課程，但寫完後有點怎麼看怎麼不滿意，後來我還是把我的文案放著。

當初是我自己想找龍哥報名這個開課，但後半段實在難產，我現在不免心裡有點愧疚。實際規劃時，真的遇上很多困難，包含很多心理因素，自我懷疑和內耗真的蠻可怕。

這年頭都流行 AI 了，想想也沒有人要看，好像把當初的大綱文稿放出來也不會太羞恥（？

關於我與前端無關緊要的分享 Day 56

竹子日誌（竹子） — Sun, 26 Oct 2025 04:00:16 GMT

這種文章很難條列式，更多是在陳述東西，不會有什麼「精華」的感覺。這種文章特別不容易的欸偏愛，也沒有很多演算法喜歡的團關鍵字，不容易飄出去。

不過這系列會是很紮實的技術文章，都是自己踩過無數坑的經驗談，希望能幫助大家。

如果希望可以聊更細膩的技術討論，歡迎找我 Coffee Chat ，或許討論過程會有一些新發現。

關於我與前端無關緊要的分享 Day 54

竹子日誌（竹子） — Thu, 23 Oct 2025 02:35:46 GMT

印象很久前也發過「全端工程師」這個文，昨天莫名奇妙被燒起來。

早期沒有前後端，通稱「網頁工程師」。但隨著時間推移，大環境走向前後端分離，開始出現所謂的前後通吃的「全端工程師」。

其實一開始「Full Stack Engineer」是一個很尊敬的詞彙，指精通前後端知識的人。但前後端的發展太快速，前端出現各種渲染架構，後端出現各種微服務架構，跟早期的網頁工程師的技術線早已不同。

開始有些人，誤以為全部都做的網頁工程師就是「全端工程師」，但事實上不是等價的。網頁工程師的開發方式也完全不是前後端分離的架構，但這種思維已經漸漸滲透到圈外。所以原本「精通前後端知識的人」這種解釋被曲解成「網頁全部做的人」，這是莫大的誤會。

逐漸，大家開始説「全端工程師」是一種貶義詞。自稱全端的都沒什麼料，就是什麼都會什麼都不會。後來大家即時都學了相關知識依然要站出來自稱自己最擅長的「那個技能」，不然會引來一些歧視。科技巨頭在找工程師也開始改變方針，直接找「軟體工程師」，感覺是把「全端工程師」這個詞彙給取代掉⋯⋯

專精也好，廣學也好，每個人都有他的價值。不自滿，清楚表達自己的深度，持續學習成長，這都是值得被尊重的。

關於我與前端無關緊要的分享 Day 55

竹子日誌（竹子） — Thu, 23 Oct 2025 02:35:40 GMT

決定開一個篇章來說說前端基礎建設，之前因為 threads 寫長文不是很舒服，但現在有「附加文字」功能後，寫長文不需要切斷分篇，感覺上好寫很多。

每一篇長度不均，還會加一點幹話。

不會到部落格的複雜度和長度，但盡量還說交代前後文，希望前端基礎建設的觀念可以帶給大家。

—

關於我與前端無關緊要的分享 Day 53

竹子日誌（竹子） — Tue, 21 Oct 2025 08:37:41 GMT

Monorepo 其實有蠻多流派，有的人喜歡把主框架放在 root，有的人喜歡把共用的放在 root 管理，也有的人喜歡 root 乾乾淨淨。

我個人特別喜歡切分清楚的 monorepo，每一個 package 有獨立的存在和切分價值，不會互相干擾。但說真的就是比較麻煩一點，每一個 sub package 都要做完所有專案都需要定義的東西，比較複雜一點。

真的是看到不少人設計的 monorepo，有朋友寫的、學生分享的、開源套件寫的，每一個都有自己的樣貌和方案。我喜歡看不同人在不同的架構反思中尋求答案，我在前端架構這個技術議題確實深挖了很多墨水。其實，很多所謂的「官方建議」我也幾乎是看看而已，因為我知道「技術本質」，我只是在評估而已。

如果你希望建置自己的前端架構，在龐大的技術選型和策略充滿迷茫，也許我們可以深度聊聊，歡迎私訊約我 Coffee Chat~

關於我與前端無關緊要的分享 Day 52

竹子日誌（竹子） — Mon, 20 Oct 2025 09:57:13 GMT

繼昨天談到的 JavaScript Module System ，可以來提及一下近期發生的事。所謂的打包知識是非常龐雜，打包知識多半毫無系統化，大部分的知識點都在原始碼、Github Issues 、散落的文章。

我近期遇到 webpack 打包時，無論怎麼處理都無法將 require 轉譯成 __webpack_require__ 。心裡想，有點懶得去查原因，我就交給 Claude code 自己去找原因，請他幫我解決。但這真是我最大的錯誤決定，AI 嘗試了增刪套件，從 babel 做多種嘗試組合，還有直接把 require 改 import，最後仍然無法正確處理，直到 Token limit 為止，還是沒有解決。過程來來回回好心累。最後我認真去查原因，翻了幾篇跟這有關的資訊，結果花不到半個小時就找到答案。

必須說，Google 找資料才是一切的根本，知識的根基和基礎都是到處學習別人的經驗，然後透過實測、經驗累積、知識交錯得到更複雜的結論。現在的人求速食，覺得打包問題問問 AI 迎刃而解，但事實上是誤導、繞道、過度實作，最糟糕是仍然解決不了。

AI 強大的是在很多人都遇過的問題，只要基數大都可以很快找到解答。但只要問題直追原頭、不多見、夠複雜，那可能就是 AI 弱項，AI 的智慧來自前人的經驗與累積，透過模糊的處理得到趨近於答案的結果，但絕對不是全能。

最後，你問我為什麼 require 無法轉譯？就單純是 package.json 把 type 設定成 module，所以 webpakck 忽略處理，把它刪除就好。但這是最終正解嗎？我也會告訴你「還不算是」。

關於我與前端無關緊要的分享 Day 51

竹子日誌（竹子） — Mon, 20 Oct 2025 05:12:23 GMT

JavaScript 發跡後發展多年，直到 Nodejs 才真正模組化的實作誕生，那是一個有點像 Function 的一個堵塞請求，讓垮檔案變得可以被溝通。大家熟悉的那 require 就是 CommonJS 的語法，從 webpack 時代一點一滴深植在開發者的底層知識中。

ESModule 統一之前，CommonJS 的生態有多深

時至今日的前端開發已經很習慣所謂的模組化開發，但過去模組化迎來 ESModule 的統一之前，其實還是爭亂不休。特別是 Nodejs v8.5.0 的實驗性支援開始，歷經迭代變革，如經的 nodejs 可以直接透過設定 type: “module” 支援 ESM 的運行。但多年的 Nodejs 所建構的 CommonJS 生態還真不是說假的，事到如今 Nodejs Default Runtime 依然是 CommonJS。而過去龐大生態系重度依賴的包含 webpack, jest, storybook 等等多年的老工具都是預設支援 CommonJS，而對於 ESModule 的運行基本上存在龐大的問題。

到達現今，有一層 TypeScript作為抽象介面，打包後有 rebuild, rollup, vite 等等工具生態可以多輸出不同環境的打包，但現今並不是每一個 npm package 都知道要支援完善，有的是設定問題還後多疑慮。除此之外，還有可怕的 npm system 複雜的 dependency architecture，真的是坑山滿滿。

轉換工具解決不了 CJS 與 ESM 的不對等

當然你會覺得使用一下轉換工具就好，但事實上並不是這麼單純的事情。CommonJS 和 ESModule 是天生不對等的兩種實作，只能做到極其相似，但依然是不等價。所以即使 ESModule 誕生多年，仍然有無數的開發者卡到對應的實作行為，沒辦法正確去處置它。甚至是編譯過關，實際運行卻會報錯。而且現今的 Builder Tool Runtime 也並非都是基於 ESModule 去運行，而是各自跑各自的。Dev Server 一套，Test Runner 一套，UI Peview Tool 一套，各自有各自的 Config 去管理運作，為了一致就費盡心思。加上每一套 Library 也不保證同時去支援 CommonJS、ESModule，不是要避開使用，就是要自己去過一層轉換或 mapping，甚至你覺得理所當然要支援的其實都沒有。這些龐大的問題體系在一般的 application 開發未必會讓你遇上，但你開始擴大應用的複雜度與規模，這些問題才慢慢浮上水面。

這塊的資料少到連 LLM 也幫不上忙

即使 AI 時代，LLM 可以從過去的歷史資料庫及網路上的文章尋找答案，但資訊可以說是少之又少，也極其缺乏系統化的教學，多半還是開發者自己學習多。包含有優化技巧、架構技巧、自動化搭建方案、Dev Config 環境隔離、相關的底層套件抽象… 等等龐大的資訊量。這些知識點真不是隨口兩句用什麼工具就可以全數解決，這些也都是透過無數的時間踩坑克服，參透原理。並不是「因為 AI 說這樣就可以解決」而胡亂加上看不懂的設定，而是透過龐大的知識疊加而透徹每一個環節的運行理念。

只能說我獨自在這塊花了好多精力學習這些知識，但真要說多少人需要？有多少人想優化？我想是微乎其微吧。

關於我與前端無關緊要的分享 Day 50

竹子日誌（竹子） — Sun, 19 Oct 2025 13:19:52 GMT

我只能說 AI 切版切的好不好取決於設計師 Figma 的品質，而不是說有強大的 AI 就可以完美做出來。一直以來，能力不到位的設計師都要仰賴前端工程師「通靈」補足設計缺陷，到了現今也依然如此。

印象五年前，有個設計師跟我說 auto layout 很麻煩，很花時間，要我幫忙補足一些東西，仰賴口述希望把 RWD 細節完善。那個時代，Figma 還不是獨霸市場一方的設計軟體，所以並不是所有人都是採取 Auto Layout 在排版，Figma 只是另一套 illustrates 。

現在，Figma 和 AI 當道，但切版還是前端工程師很沈重的工作，花時間也價值低。有人說 AI 切版切的很棒啊？蛤？截止至2025年9月，我不覺得 AI 切的很好。

要切的很好有兩個可能的關鍵前提：

不需要設計稿，隨意發揮，但設計細節缺乏，甚至是 RWD 各種情境炸裂。

另一個可能，有完善的 Figma 檔案，無論是variable 、component 、auto layout 用好用滿，搭配 MCP ，快速產出。

所以今天你告訴我 AI 切版很厲害只有兩個可能，要嘛你的設計師功力高超，要嘛你沒有設計稿，覺得給出65分的東西你就非常滿意。

無論時空迭代，AI 談的是加速不是取代。

關於我與前端無關緊要的分享 Day 49

竹子日誌（竹子） — Sun, 19 Oct 2025 07:53:21 GMT

現在幾乎壟斷前端市場的 tailwind ，語法幾乎成爲 Atomic CSS 的「標準」，在這之下去擠壓其他解決方案的空間。或許統一是好事，但社群發展因此就不鼓勵異聲，會得到「為什麼還要造新輪子？」這樣的質疑。

但 tailwind 是最好的方案嗎？

其實我也不知道，在設計 UI Library 中有種被 tailwind 綁架的感覺，但我覺得 tailwind 並沒有跟 UI Library 這種東西很合。他不能動態拆分 CSS Chunk、掃描原始碼需要被曝露出來、CSS 變數架構更加複雜而隱晦⋯⋯

這些問題依然是存在，並沒有因為演進消失。鼓吹著 zero runtime 的現在，被忽視的動態加載機制，這真的是趨勢？

我不覺得 tailwind 是唯一的選擇，過去很多做法也都有它的優勢與價值，重新審視架構去評估不同的解決方案的價值還是很重要的。

關於我與前端無關緊要的分享 Day 47

竹子日誌（竹子） — Thu, 16 Oct 2025 15:55:53 GMT

這兩天情緒特別焦慮，不知道為什麼。看著身邊優秀的後輩攀爬到另一個高度，祝福他們大鵬展翅，我羨慕也嫉妒。不知覺在內耗，覺得自己很差。

剛好回想起前幾年的生活，覺得那幾年真的是拼了老命的認真，是我差勁、頹廢、散漫了嗎？可能⋯⋯是包袱多了，放不下多了，反而沒有剛轉職當時的瘋狂。

最後一集，明天要寫點其他主題了。

我的故事 ep5, End:

關於我與前端無關緊要的分享 Day 46

竹子日誌（竹子） — Wed, 15 Oct 2025 15:49:43 GMT

覺得每天 PO 這種挺無聊的，但就先把部落格的進度給追完，更後面的暫時沒有想寫。

其實我自己的故事也算不上精彩，也不一定什麼頂尖，更不是什麼最佳示範。我只是單純分享我的經過，一個平凡人的轉職，平凡的工程師求職的過程。沒有優良的背景，沒有正統的學歷，沒有幸運的進入好公司，一切從基層一步步爬上去。

等連載結束再後續的廢話好了。

我的故事 ep4:

關於我與前端無關緊要的分享 Day 45

竹子日誌（竹子） — Wed, 15 Oct 2025 00:04:00 GMT

這幾天有點軟爛，我想做的東西都沒進度，最少還是 Po 個文章吧⋯⋯

我的故事 ep3:

關於我與前端無關緊要的分享 Day 48

竹子日誌（竹子） — Mon, 13 Oct 2025 12:18:39 GMT

要在一個比較老派風氣的地方要推動改變很難，層層關卡、層層挑戰、層層突破。

想要發動改革是需要天時、地利、人和，諸多條件都需要滿足。需要有一個陳年殘破不堪的老專案，並且他有在賺錢，夠值錢。有一個想要進步的主管、有一個想要改善產品的設計師、有一個有執行力的統合者，需要有這些特質的人兼備。最後，需要一個有時間空檔檔工作環境，插縫執行各種工作。

這一切兼備後，才能逐步進步往前。

最近工作很開心有各種改變。

導入單元測試系統，並且開始有人使用。

導入JSDoc，大範圍在各個常用元件採用。

重構私有函式庫，開始長期的優化計劃。

有種齒輪鬆動的感覺⋯⋯

關於我與前端無關緊要的分享 Day 43

竹子日誌（竹子） — Sun, 12 Oct 2025 14:45:44 GMT

日前看到脆友有說可以分享一下自己的轉職和成長歷程的故事，我覺得也可以。

其實我在社群上也分享過，部落格也都是公開的，只是很久也沒有去更新版本了。如果你看過可以忽略，就是一個爽發的文章。

反正我決定發個小連載。

我的故事 ep1:

最後我在這過程中認識了 Wordpress ，這是我打開這條路的契機。

關於我與前端無關緊要的分享 Day 42

竹子日誌（竹子） — Sun, 12 Oct 2025 03:24:44 GMT

很多時候一個人努力的軌跡都會在程式碼中，他的執著和熱情是可以看到的，一點一滴的打磨中有各種痕跡。

平常幫同事、客戶、學生、朋友 Code Review ，慢慢的都可以看到一個人的成長軌跡。AI 出來前其實資訊量更大，自從 AI 的洪流到來，多了很多雜訊，為了去蕪存菁，需要花費更大的心力。但有趣的是，AI 寫的跟家去複製貼上的更好辨識，因為 AI 寫的東西就是有一股「AI 味」。

現在的新人過度依賴 AI，無法為自己撰寫的交付負責，真覺得 Code Review 的負擔是越來越大的。過去花時間在設計和嘗試，現在花更多時間在定義和測試。

感嘆，時空變化…

關於我與前端無關緊要的分享 Day 41

竹子日誌（竹子） — Sat, 11 Oct 2025 04:02:27 GMT

UI Library 已經卡住兩週，都在調整架構。真的覺得 Primitive UI 的設計很困難，API 設計常常會卡到很多底層設計的盲點，東迴避西迴避。

剛好最近工作也需要重構 UI Library ，把工具鏈進行大幅度的升級，將較舊時代的技術轉移到這個世代的工具鏈。工具鏈一環綁著一環，要怎麼拆 Commit 和 PR 也是一個莫大的議題，我費了很大的勁。最後一整週來來回回都在測試，但總是有可能有些 Edge Case 藏匿在某些地方。如果整個技術線和方案沒辦法足夠真實的測試真實場景，那東西的穩固性極爲困難，其實有種經常在走鋼索的感覺。

我只能說，漸進式處理吧…

測試案例真的很困難，真的要寫，動不動都比原始碼大上 2~3 倍，維護 Test Case 難度又比原始碼困難… 測試真的是軟體難題，成本和穩定的天秤上膠著。

關於我與前端無關緊要的分享 Day 44

竹子日誌（竹子） — Fri, 10 Oct 2025 01:52:15 GMT

雖然知道沒什麼流量的文章，不過就是爽發就發的系列，其實就是舊文章拿來貼。

我的故事 ep2:

關於我與前端無關緊要的分享 Day 40

竹子日誌（竹子） — Thu, 09 Oct 2025 02:47:33 GMT

近年越來越常聽到設計師主動請求則採用 Storybook，什麼時候開始在設計師的領域被傳開來了？

我經歷數間公司，大部分公司導入 storybook 的失敗都在於不重視元件庫迭代。輕易修改，輕易加功能，文件規格沒有工程師以外的人協助維護。AI 當道的現在，其實維護 Storybook 成本更降低了，那些 .stories 檔案其實也是給 AI 爬蟲很好的 Context，我認為現今更需要去維護這樣的元件庫工具。

必須說，storybook 並不適合所有的團隊，畢竟它維護成本相當高。依照經驗，storybook 的 Use case 和 Component api documentation 的維護是非常費心的，如果不是專案反覆需要重用元件，並不這麼適合。所以大致上可以歸類，接案公司其實不適合使用 storybook ，除非有長期維護的專案與產品，那在於人員交接與接手上就會帶來很大的價值。

我其實推崇，但也不盲推，真的看需要。如果公司產品非常專案性質，介面沒有固定的調性，那其實意義也不大，甚至連元件庫都不需要。

你聽過 Storybook 嗎？分享你的看法吧～

關於我與前端無關緊要的分享 Day 38

竹子日誌（竹子） — Tue, 07 Oct 2025 22:37:54 GMT

我朋友都知道我對於 React 不少怨言，但社群環境依舊是傾向著它，這讓我確信。市場需要的不是優雅的程式實作，名氣、認同、穩定，這些要素對於產品來說重要。連個軟體的 Library 都是這樣，更別說像樣的商業應用。

今早看到追蹤的工程師分享 React Conf 在探討 signals 在 react 的可能性，姑且不知道是否成為未來，也必須說除了 react 之外的所有框架都在走 signal 的心智模型。

坦白說我並不支持 React 第三方的 signal library ，因為這件事應該是響應底層的工作，透過第三方耦合的延伸問題其實蠻嚴重的。真的要做，還得痛定思痛去重構 React 舊有的程式碼。React 原始碼閱讀過都覺得很不舒服。依賴複雜，型別脆弱，解耦不良，對於 tree shaking 不友好。我不清楚 React 什麼時候願意改變去面對他的技術債，甚至某幾款「大家很愛的」的Library 也都是問題很大。

事實證明，成功的產品不需要多優秀的工程實作，不需要人見人愛的原始碼，它需要的是市場聲量和穩定。反正多數人從來不會去計較內部實作，他們要的就只有「可用可信賴的產品」。

關於我與前端無關緊要的分享 Day 39

竹子日誌（竹子） — Mon, 06 Oct 2025 23:57:09 GMT

有時候覺得精疲力竭，精神力與專注力被榨乾，這時真的需要好好休息。

其實出門玩，不管是大家喜歡的唱歌、打桌遊、旅遊都是很開心的事，但也比較消耗精神。

如果缺一些 E 能量，可以去跟朋友去喝咖啡閒聊、無目標逛街散步、小酌兩杯。

如果缺一些 I 能量，可以冥想、瑜珈、沖熱水澡。

其實我自己是一個需要平衡的人，有時有要均衡攝取不同的生活能量。

真的太沒有勁，其實需要的就是好好睡一覺，早起也是蠻多好處的。

疑問

竹子日誌（竹子） — Mon, 06 Oct 2025 10:41:19 GMT

萬事問社群

先不管我的實際情況。

如果是你，如果要投入開發原生應用開發，並且想要對 UI Style, UI Flow最大化做各種調整，你會選擇什麼技術線？

走原生 Swift, Kotlin
使用跨平台 Flutter
適用跨平台 React Native
使用 Web View 方案，Cordova, Ionic

理由是什麼？

關於我與前端無關緊要的分享 Day 37

竹子日誌（竹子） — Sat, 04 Oct 2025 09:37:11 GMT

這年頭似乎比較流行使用 Primitive UI ，也有人稱之 Atomic UI ，也有人稱之 Headless UI，反正其實在講的都是同一件事，就是原子化元件設計。

原子化設計之後，誕生了諸如 Redix UI, Base UI, Chakra UI, Headless UI 等等的 UI Library 。他們最大的優勢在，不用煩惱每個節點你要怎麼去翻改樣式，提供你最陽春簡單的樣式，針對指定的 HTML 節點來進行修改。

但這類的 UI Library 就是使用上門檻高了一點，要理解使用會是一件頗吃力的事情，所以現在還有 Shadcn UI 這樣的 UI Registry ，可以用指令把必要的實作層給安裝上專案。

這整套下來可以說是在社群大流行，然而卻也帶來過去不存在一些問題。比方說版本管理、依賴共用、功能覆蓋、權重管理等等，這些過去問題被封裝在元件中，被妥善管理。隨著曝露出來，管理這些東西開始成為一個問題。

關於我與前端無關緊要的分享 Day 36

竹子日誌（竹子） — Sat, 04 Oct 2025 09:28:56 GMT

無論參考再多的開源庫，無論規避多少問題，技術選型永遠存在缺陷和困難。真的只有面對這些問題，去實際實現、體會、製作，慢慢得已感受每個細節的天工。

現在越來越熟悉 Chakra UI 生態系的底層實踐機制，我真的覺得它的抽象化完全是藝術，有很多設計精神非常之優秀。但如果單純使用它沒有什麼出奇之處，我覺得就不過是一個普通的 UI Library 。但它驚奇之處是在 Zag, Ark, Park 三套底層的抽象技巧，真的是非常有趣。有想要客製化開發 UI 的人，真的很值得學習的設計理念。

當然，我也是從模仿開始，進而發現問題、微調，最後意識到不簡單之處。慢慢也會踩坑，開始淬煉品味，看到各種複雜的問題。我非常想要分享，但太多問題的複雜度真的不是簡單可以用文字傳達的。

關於我與前端無關緊要的分享 Day35

竹子日誌（竹子） — Fri, 03 Oct 2025 10:19:03 GMT

最近又有老友要找我進行開發報價，認真計量成本後，真覺得外面接案市場的價格真是凌亂。我自從薪資突破某個水位後，我意識到接案市場的價位混亂，大部分要做系統的需求方根本沒有意識到實際上處理系統要付出的成本，所以我就很少去接案了。

其實可能是因為競爭，大家殺的價一個比一個還要低，真的很可怕。100 萬？50萬？10 萬？5 萬？我還真的都看過。如果是要用更低價做，我會覺得乾脆自己請工程師做看看就會懂。或是簡化商業模型去製作，不要什麼都要做成系統。當然也有人認為花了 50 萬、100萬、500 萬等等水位做了系統，希望能達到某種水平，結果根本不符合期待。但是真的不符合期待還是單純期待太美好？

必須說這些系統開發下來都是高昂的成本，隨便個產品級的 MVP 都要百萬預算。你也許覺得可以「簡單做」、「AI 做」、「大概就好」等等，但基於面向的市場與複雜度不同，你可能連系統要設計多複雜都不知道怎麼去評估。專業人員眼睛看到的東西是不同的世界，這就是溝通到困難，系統的變現和落地的成本和技能本身完全不是可以做對比計算。

關於我與前端無關緊要的分享 Day 32

竹子日誌（竹子） — Thu, 02 Oct 2025 00:24:45 GMT

React 更新了，React 19.2 ！

其中我最在意的功能莫屬 useEffectEvent。

一直以來 react 在下傳 function 時要去掛勾 useEffect 常常造成不必要的更新，這不是用 useCallback 能解決的，也解決以往我在開發時的痛點。

其他還有 Activity, cacheSignal 等等API，也為 SSR 相關機制與渲染進行優化與新功能提供。

https://react.dev/blog/2025/10/01/react-19-2?ck\_subscriber\_id=3110441451&amputm\_source=convertkit&amputm\_medium=email&amputm\_campaign=%E2%9A%9B%EF%B8%8F%20This%20Week%20In%20React%20

關於我與前端無關緊要的分享 Day 34

竹子日誌（竹子） — Wed, 01 Oct 2025 04:19:41 GMT

最近有點停滯，我覺得倦怠感有時候一波一波。每次倦怠感一上來，Side Project 、英文、寫教材、寫書信、寫文章等等，全部都會延宕。目前強迫自己每天還是要輸出點東西，寫點文字驅使自己不能懶惰。

雖然最低限度就是做好工作，其他事都可以放掉，又有莫名罪惡感告訴自己，做不到每天把固定的事情做好，那真的很糟糕。

我覺得要調整好狀態重新開始，今年所剩不多了。

鏟子英雄

竹子日誌（竹子） — Wed, 01 Oct 2025 01:30:12 GMT

原本沒有連結的兩個事件因為它被聚集在一起，一個是 Vibe Coding 翻車，一個是鏟子英雄，但因為有善心人士發佈了「鏟子英雄」這個網站而有後續。

我姑且說我沒判讀這個網站是否 Vibe Conding，基本上如果是我去做我也會使用 AI 工具。但最近因為 Vibe Coding 翻車事件，導致工程師群體對這種事極敏感，大量湧入的人群和聲音，作者不免承擔了龐大的壓力。

我不知道可以有多少人看到，但我希望大家多點同理心，用心做這東西也是一片善意，不需要用這麼鋒利的詞彙和攻擊的語氣去指責。很多時候很多考量都是當下情況的選擇，但我們不是站在其中的人，無法理解他們的難為與辛苦。

如果做這有看到，麻煩你公開 Github，我相信有很多善心工程師願意去協助你完善它，你只要審核 PR 並合併部署。如果一人太辛苦，或是技術遇到瓶頸，也歡迎發文找夥伴協助你做這些龐大的工作。

開源精神與你同在。

關於我與前端無關緊要的分享 Day 33

竹子日誌（竹子） — Tue, 30 Sep 2025 03:17:05 GMT

這是最後一次，針對這個事件上發文。這幾天真的是被轟炸。我可以選擇不要看到，但我打算繼續看這波可以燒多久。

開頭必須說，我也是跨過多職能的人，直到近年才慢慢穩定下來在軟體工程師圈。

業務、行銷、公關這些看似沒有「專業」的職能也是有莫大的專業成分，並不是外面所講的沒有專業成分。特別我要強調，行銷的資訊迭代速度的辛苦絕對跟軟體有得拼，追趕這些新工具非常辛苦。行銷也更不像工程師一律躲在背後，常常需要拋頭露面，成為行銷的那個品牌之顏。我過去從事相關工作時，每天發文的壓力是多麼大⋯⋯

工程師確實驕傲，領著不錯的薪水，經常在「不行」、「做不到」、「好麻煩」這幾句話周旋。領著高薪在公司囂張跋扈的不少，不知進取卻把持公司產品命脈的也不少。我曾經當 PM 和 UI 時面對工程師時，工程師經常就是一副愛做不做的嘴臉，我都懂。

現在我成為工程師，我非常尊重所謂的專業素養，每一個人都有他職位上的專業，不應該去踩踏任何人的專業。可以用各種角度訴說困難，討論解決方案，但絕對不要預設對方是「容易的」，尊重也都是必須的。

站在商業立場，當然就讓那些付出成本投入的人去承擔被客戶帶來的，我們這些旁觀者沒什麼好嘴的。所以「我從頭至尾不批判開課這件事」，因為那是他的商業選擇，他自己會對客戶負責。當然，他吸引了一群瘋狂的工程師去攻擊，我覺得大可不必。

但這件事爆發後，有莫大的兩股聲音在相互攻擊。工程師也好，行銷也好，我們不應該去踐踏對方專業、恐嚇對方，甚至頤指氣使。

一群行銷人和工程師們開始互噴。

「都是你們害怕被取代」

「什麼都不會在割韭菜」

「少那邊築起技術城牆」

「不懂就不要 Vibe Coding」

等等輕視的情緒詞彙⋯⋯

網路有時候就是情緒高漲，但我也知道不是每個人平時講話都是這麼兇悍和不禮貌，但真的說話前多想想是好的。我的觀點一直都是「請不要去貶低別人」，不管你是行銷人還是工程師，你去貶低或看不起別人的專業，我先看不起你。

關於我與前端無關緊要的分享 Day 31

竹子日誌（竹子） — Tue, 30 Sep 2025 00:09:20 GMT

我這幾天很認真思考，要讓一個純小白開始寫程式，搭配 Vibe Coding 產生出一個應用程式，背後需要知道的基礎知識量實在太過於龐大。

回想起自己曾經不懂軟體開發時，確實買過相關的課程，從如何架網站、部署網站、整合商業模式⋯⋯各種環節。我當時只是想行銷產品，覺得可以靠技術解決問題，在那個 AI 不如今天方便的時代，我沒有人脈、沒有技術、沒有知識，我只好無助的尋找課程滿足我面臨的問題。我又再度花錢學切版、學如何進行細膩的程式調整，也問網路上的工程師然後被打臉，花了海量的時間練習、嘗試，最後誤打誤撞自己成為了工程師。

小白期待自己可以突破技術的枷鎖，龐大的知識的焦慮，希望利用科技來幫自己賺到錢。其實我都懂，確實賺這種錢可以快速賺到一些韭菜錢，但你可知這種錢背後 80% 的人根本沒辦法幫助到他們。看似學會了一門技術，看似可以執行商業應用，那只是在愚昧的山峰感受到無所不能的假象。後面接踵而來的問題成堆成山，如何調整版面？如何串接 API？如何建立會員系統？如何整合金流？如何做資安防禦不要被攻擊？如何做出 SEO？⋯⋯⋯太多太多知識了。

最後我的結論，如果你不是真心想走向工程師這條路，隔行如隔山，還是讓術業有專攻的專業人士處理，不要妄想著花幾堂課、幾個月、幾萬塊錢就想要學會別人吃飯的傢伙。學習在業界如何跨領域協作，結合不同人的專業知識去做事，而不是輕忽一切的直接跳下市場被現實重拳。輕者只是賠個小錢道個歉，重者會吃上官司纏上天文數字，「不了解」背後要承擔的成本跟風險你根本就不知道有多大。

我知道想太多會影響到執行力，創業是需要先執行後修正，但你真的有做過「風險管理」嗎？還是說你只是傻乎乎的把自己置身在危險當中不自知？我真的有認識的人因為答應客戶處理了超出自己能力之外的事，甚至纏上黑道，差點命都不知道在哪了⋯⋯

關於我與前端無關緊要的分享 Day 30

竹子日誌（竹子） — Sun, 28 Sep 2025 07:06:50 GMT

Portal 是許多元件的的基礎，也可以跟 Dialog 進行延伸與變化。舉凡 Select, Dropdown, Input Picker, Tooltip, Modal, Drawer 這些都是相關體系分類。他們的共同點就是脫離元素的地位，以視窗為主題來呈現資訊。

但正因為以視窗為主題，所以也存在更多的陷阱與處理上的困難點，許多邊際問題必須去處理。

點擊背景是否允許關閉展示？

比如超過視窗是否要限制？

內容過多該怎麼滾動？

如果非同步的資料進入如何正確展示？

彈出展示時，如果撞到邊界是否要換邊？

其實還很多⋯⋯

這部分的設計相信是很多元件設計者的煩惱，要處理到優雅、完善、彈性等等條件，真的不是一件容易事情。這幾天卡在內部 API 設計的思考上好幾天，一直未能有突破。

我現在稍微停下腳步去看看各家的元件怎麼實現，迷茫時不要瘋狂自幹，多去參考別人家的實作，有時候也是獲取靈感的方式。雖然不見得真的會喜歡，最少我可以很確定告訴別人每一家 UI Library 的實作細節。

關於我與前端無關緊要的分享 Day 29

竹子日誌（竹子） — Sun, 28 Sep 2025 06:32:53 GMT

我學習的方式

我以前蠻喜歡畫圖的，在沒有任何有系統的方法前，當時怎麼學習呢？

從把自己的圖紙壓在模仿對象上面，100% 模仿，依樣畫葫蘆，這階段是描線。

下一階段是把模仿對象放在旁邊，盡可能模仿畫出一樣的線條，這階段是臨摹。

下一階段是腦袋空想模仿對象，盡可能重現相同的筆跡，這階段是內化。

最後是把掌握到的筆觸和技巧拿來修改創作出不同的東西，這階段是應用。

寫程式也是如此。

從能夠照抄寫出會動的程式，默寫會動的程式，微調程式後還是會動，這就是學習的過程。

即使科技日新月異，掌握新技能的方式其實沒有變化，你需要的是尋找模仿對象、重複的模仿、重複的練習、重複的應用，最後到能夠掌握技能。

工具可以加速、帶來生產力，你可以利用工具快速產出帶來成就感，但不是利用工具後輕視「學習基礎」這件事。

關於我與前端無關緊要的分享 Day 28

竹子日誌（竹子） — Sun, 28 Sep 2025 02:32:05 GMT

雖然我慢了兩天才說關於 Vibe Coding 的事情，但我還是為這件事難過。

我是從業務圈和行銷圈脫離的人，我不得不說，散播與成交經常要用一些「我覺得不舒服的方式」。我懂一些行銷，但我不是真的耕耘很深的人，所以無法跟大家分享什麼實戰和經驗，我只是分享我所知道的。但我過去看到的行銷經常是「製造焦慮」、「引起爭議」、「藏招吸引消費」、「沒一回事還是要說的很厲害」等等手段，利用各種人性在做銷售漏斗，我真的常常要跟自己道德底線交手。我到了工程師圈，我很喜歡圈內「樂於分享」、「單純直接」、「追求能力與正確」這些特性。工程師們靠技術扎實去解決問題，能夠務實談可以與不行，凡事求正確與確實，這我真的很喜歡。

工程師就算學了行銷，也會更保守

大部分工程師即使學了行銷，就算知道那些技巧與知識，總是會更保守一點，他們知道「什麼可以什麼不行」，知道「現實情況的實際面」。他們常常會想，「這些東西很多人分享了」，談不上什麼含金量，也幾乎不會藏著捏著，四處與人分享他們專研的成果。確實在商業上看起來愚蠢，但這也是讓這領域不斷高速成長的原因。我們行內有一句話：「取之社群，用之社群」，這是一個回饋社群的正循環。

免費套件跟 AI 的能力，到底是哪來的

你知道你現在軟體業的各種免費套件是哪來？這些全部都是網路上熱心的工程師們建立起的豐碩成果。他們開源這些他們研發的功能分享給大家，讓大家開發速度更快，如果什麼都從頭來是一件很可怕的事情，那個工作量真的是很龐大。

你知道你現在聰明的 AI Coding 能力是哪來？是爬蟲爬取廣大開源的程式碼和部落格，打這些技術與知識的結晶淬煉現在的 AI，我們才擁有現在科技豐碩的成果，不是那些科技巨頭真的從零打造的黑魔法，而是基於這些願意將知識整理好放到網路的這些善心人。

所謂飲水思源，我很感激這一切，我也永遠景仰這些優秀的貢獻者，他們理所應當得到更多。我只看到很多人嘲笑他們不懂賺錢，連提供捐獻的流程都亂七八糟。你覺得這種嘲笑對嗎？他們不懂是他們把時間都投入在有價值的東西上，分享出大家的好心人，你也可以為他貢獻，幫助他能更好的募資到生活費。

大家都在比誰賺得多，這讓我難過

近年，我感受到大家總是在追求「誰賺的錢多」，對於技術的執著少了很多，總是喜歡比較誰薪水多，誰賣的課程多，漸漸讓我感覺的難過。寫部落格、研究技術、社群分享，這些東西真的不能讓你領更多錢，領更多錢的人未必對社群帶來貢獻，這就是現實。我覺得談「道德」與「善心」太過高尚，也太困難。我只覺得，網路上多一點愛心，多為分享者提供情緒價值，這就是科技成長的基石。而不是每天危言聳聽，恐嚇別人即將沒有工作。

關於我與前端無關緊要的分享 Day 26

竹子日誌（竹子） — Thu, 25 Sep 2025 23:19:22 GMT

對於 webpack, rollup, vite 你懂多少？

前端打包真的是一門超級難學，但又最不容易被看到的技能。

大部分的人學習打包都是止步於網路上部落格看到的知識點，或是能解決的簡單情境，看到有插件大概看一下文件就使用，基本上腦袋都沒有思考過在打包中的 pipeline 發生了什麼事情。所以大部分的人在打包工具出問題時，要不就繞路而行，要不就是直接放棄。你真的有認真閱讀過你包出來的 dist 長什麼樣子嗎？

近年 AI 興起，蠻多打包設定問題可以問問 AI，省去爬 Github issues 和 Stack overflow 的時間，但也不代表不需要懂那些知識。大部分的人遇到的問題都是爽快的把東西加上去，以為萬解。但如果不知道一些根本性的問題，其實你只是在疊加技術債，打包設定越多，增加太多你連做什麼都不知道的設定越多，要承擔未來的苦痛重量就越重。

最近都在處理跟打包的問題，突然間覺得好像使用比較新的技術在設定打包上越來越輕鬆，但坑卻埋藏的越來越深。有時真的想罵「這不是我知道的坑嗎？我怎麼忘記了」這種感覺。近期剛好有學生也問到了學習打包的問題，我也才在想我怎麼開始學習的？其實仔細想想我學會打包的過程還是挺地獄的，真的是在磨難中成長。

最近 UI Library Side Project 也處理了頗多打包問題，在一個個拿來分享吧。

關於我與前端無關緊要的分享 Day 27

竹子日誌（竹子） — Wed, 24 Sep 2025 16:06:20 GMT

我要其實蠻害怕 PM 開出驗證需求寫「禁止特殊符號」，我這個時候都想問，「何謂特殊符號？」。

特殊符號的覆蓋範圍非常之大，到底是要用白名單還是黑名單？鍵盤上看得到的符號才算？還是非主語系文字都算？emoji 也算？

這件事其實超級難定義啊⋯⋯

中文怪物

竹子日誌（竹子） — Mon, 22 Sep 2025 15:30:34 GMT

我要來蹭一波「中文怪物」的熱度了。

其實這件事雖然跟軟體沒有太大的關聯性，但就是有這麼一丁點🤏關聯性。

Ku’s 在其他 Youtuber 訪談中提到，他們為這次活動寫了答題 App ，但就是在前一刻要啟動時發現「啊！要更新系統」。這就是網頁應用程式和行動裝置應用程式最大的差別點，就是「版本的兼容能力」。

如果選擇的是瀏覽器，那既不用下載，也不用強迫更新，也不會綁定設備的超強兼容能力。但原生應用程式致命傷就是沈浸體驗，綁在瀏覽器上終究輸一點，但能做的東西真的沒有差很多。

那是一個簡單的答題程式，並不是很難，搞不好 Vibe Coding 隨手就可以產出，也很可能不需要找工程師。這也是這個時代不一樣的地方，現在可以搭配專業的工程師顧問，幫忙指導 Vibe Coding 的策略，輕鬆滿足一個活動背後的需求。

不知道後面有沒有其他有趣的事情可以分享，反正我們就繼續看下去。

關於我與前端無關緊要的分享 Day 25

竹子日誌（竹子） — Sun, 21 Sep 2025 13:57:53 GMT

各種 Icon 採用方案中，我最喜歡的莫過於 SVG了。有最大的控制彈性，可以改顏色、可以改大小、可以改細節、可以加動畫。完全不需要像是過去使用 Font Icon 還要去重新打包發布字型，就可以在 runtime 做到改變。

也許會有人說，url 內部的資源怎麼改？

其實我採用的是把 SVG 的文字讀出來直接 mount 到 html 上，就跟 DOM 操作一樣。

也許有人會說，SVG 怎麼可以改顏色？

其實可以，真的要利用 CSS 的 currentColor 的特性，直接就可以控制顏色。把向量上的 stroke color 或是 fill 改成 currentColor 就可以控制。

也許有人會說，SVG 高度寬度還要手動設定。

其實可以在 SVG 上設定 width, height 的數值為 em，透過比例和 font size 就可以繼承大小。

也許有人會說，樣式修改我用 CSS 就可以控制了，為什麼要用 SVG？

因為 SVG 的控制能力更強大，很多 CSS 還沒發佈的渲染功能都可以在 SVG 的渲染引擎找到對應的語法。包含 Liquid Glass 的玻璃折射渲染，也都可以找到解決方法。

也許有人會說，動畫我用 CSS 就可以控制了，為什麼要用 SVG？

因為 SVG 可以做到向量軌跡動畫，可以做更加絢麗的效果。也可以向量變形動畫，達到一般 html 無法呈現的變化。

現在 AI 加持的今天，這些靜態效果並不難寫，但可以產生的便利也非常多。我也必須承認這沒辦法 100% 取代字型 Icon 能做到的事情，比如說漸層色，它需要採用更侵入的做法，卻也不是完全做不到。

關於我與前端無關緊要的分享Day 24

竹子日誌（竹子） — Sat, 20 Sep 2025 05:55:50 GMT

曾經我製作過無數的 Dialog 元件，嘗試使用各種各樣的方法，踩過無數的坑。

這種基於視窗彈出的元件一定要實作「Portal 」，在 vue 的話叫「Teleport」，並且搭配 position fixed 定位到指定的位置。

Position

初次刻這個元件的人肯定覺得，position fixed 不就可以固定到螢幕中間？如果是下拉選單 position absolute 在旁邊就可以正常作動？何必搞一個 Portal 丟到 body 去？這件事真的沒有那麼簡單，有一個天坑就是 overflow ，任何超出這個元素都會切掉。沒錯，即時你 fixed 也一樣會被切掉，但難保你在畫面中就是會需要 scrollbar，所以你避也避不開，逃也逃不掉。

Transform

另外就是定位不能用「相對位置」，一定要使用絕對位置。因為定位邏輯上面還有可能發生即時運算的調整，不可輕言去相對設置，不然越喬越奇怪。更是不能用 top,left,right,bottom 去定位，要使用 transform translate，不然每次修改都會引發大面積的重新渲染。

也因為採用了 transform 的模式，使用了 translate 去定位，但其他的功能會失去。為了保有其他如 scale, rotate, rotate 等等能力，必須再搭配變數去完成多種效果的組裝。

Scrollbar

Portal 真的只要丟過去 body 就好嗎？

事情真的沒有那麼簡單，因為一路向上還有可能會遇到scrollbar，當你在滑動會意外觸發不同層級的 scrollbar，你必須把上層的 scrollbar 給 Lock ，以防使用者誤觸滾動。

也因為你塞入額外的元素在某個層級，可能會影響到那一層的寬度，使用者會有極不舒適的抖動。所以必須要取得 Container 的正確寬度來做定位計算，暫時在 Lock 時固定寬度。而這個正確寬度要扣掉 scrollbar width ，必須判斷是否存在 scrollbar，並取得其寬度。

關於我與前端無關緊要的分享Day 23

竹子日誌（竹子） — Sat, 20 Sep 2025 05:48:10 GMT

過去都覺得 Button 是超級簡單的元件，然而真的開始做才會知道，它超級困難⋯⋯

Variant

除了基本的 Variant，可以表示 filled & outlined，甚至是 text。但 Theme 超不適合和 Variant 混合使用，但似乎蠻多人卻習慣這樣做，但我的觀點是配色是配色，變體是變體，它們能夠交錯搭配。最讓人崩潰的還是它 Design Token 的配色，要如何舒服的進行顏色的轉化與變化，我用了很多組裝技巧。

Size

最頭疼的莫過於 icon，Space 超級難以分類，如果混雜在 size 也會難以處理。一般的情況，padding 的 x axis 與 y axis 都會是不同的間距，但遇到內容只有 icon 卻反而適合相等的間距。

是不是要預設提供 Loading icon 也是挺讓人煩惱的。甚至切換狀態時是否要保留原本的按鈕寬度，可能還要處理對應的狀態切換生命週期。

關於我與前端無關緊要的分享Day 20

竹子日誌（竹子） — Sat, 20 Sep 2025 02:52:27 GMT

最近跟很多朋友聊天，聊聊工程師衝上薪資天花板的策略。

年薪一百前，All in tech。無疑是最快達到第一場階段薪資天花板，可以最快滿足各種需求，成為一個「合格的」工程師。

年薪 120～160，撇除外商化的，這是台商極限範圍。就算去了菠菜、區塊鏈這些高新產業依然在這個區間遊走，傳產更是困難重重。這個時候最重要的是人格特質，得到機會的關鍵是「讓人喜歡你」。

再往上呢？更現實。

學歷、刷題、英文，你需要去的頂級社畜工廠要的就是這些東西，技術好壞這件事多半被丟到不知道多遠。

台灣人文環境大多評價一個人的實力是用「薪資」，通常技術能力特別好的未必薪資高。樂於貢獻開源、樂於參與社群、樂於付出公益、Side Project 等等，這些看似很有價值的事情其實對於一個「員工」沒有想像中有幫助。這些不會幫你突破薪資天花板，因為這些不是那些公司多在乎的事情。

如果你覺得你學習和付出只是為了突破薪資天花板，那我覺得你直接專注在對薪資有幫助的事物上，那些額外的東西幫助沒有想像中大。

其實，我很希望有年薪 250～350 的軟體工程師來打臉我，告訴我我說的是錯的，這樣我會覺得這個社群和社會還是有一些熱情與希望。如果存在於社群中只有功利主義，那真的很殘忍糟糕。

關於我與前端無關緊要的分享Day 22

竹子日誌（竹子） — Mon, 15 Sep 2025 05:01:02 GMT

從頭去研究色彩系統，才發現現在 CSS 系統飛躍性的進步，跟過去顏色系統已經完全不一樣了。包含 color-mix, oklch 等等功能。

傳統要用基礎色延伸成透明疊色語法上滿限制，也不太能疊 CSS 變數混搭半透明。但有了 color-mix 功能反而這件事可行了。

覺得也是因為這樣，基礎色的使用更自由了，我決定用 mixin半透明來達到 color token 的變化。透過按比例疊色與疊色和半透明化，可以某種程度展示出特效感。

但我也發現致命的缺點，就是不能 transition，算出來的顏色不是一個容易得到結果的色彩，還需要搭配工具去確認最終結果。搞不好我找時間還得去改顏色系統的設定，不過就先做一個大概了。

關於我與前端無關緊要的分享Day 17

竹子日誌（竹子） — Sun, 14 Sep 2025 16:05:51 GMT

被許久前的老客戶召喚，他們希望重啟維護 4 年前的專案，這是一個可怕的事。

打開專案的瞬間心都涼一半了，4年沒有維護過任何一行 Code，沒有升級過任何套件，我只是把它 Clone 下來 install，就紅的慘烈了⋯

npm 系統不開玩笑很可怕，如果你不了解它安裝的原理和依賴的計算方式，真的會踩一個你不要不要的。git 最後的 lock 檔紀錄了很多拯救我的蛛絲馬跡，把那些沒有問題的版本組合給挑出來。

最後還動得起來，真是萬分感激。

關於我與前端無關緊要的分享Day 18

竹子日誌（竹子） — Sun, 14 Sep 2025 08:32:53 GMT

[Build in Public]

之前做的那個 UI 專案陣亡了，這次我打算自己顧自己的衝刺。初步先開了 UI Library Repo，很多東西都還沒整理好。不過打算邊做邊分享遇到的事情，來個 Build in Public 的開發，可以讓大家看著我做這個東西。

其實核心我有一個想完成的東西，但那個核心產品我覺得我想先賣個關子。

老樣子，這就是一個造輪子專案，怎麼難怎麼來。我打算基於 zag.js, panda.css, oxc lint 等等技術線為基礎來製作，大致上會參考 Chakra UI 相關專案的架構來進行設計。有不錯的實作我也會考慮直接抄，然後微調成我的形狀。

如果有興趣參與 UI Library 專案的歡迎私訊我

徵：前端工程師、UI 設計師

https://github.com/willy874/ui-library-architecture

關於我與前端無關緊要的分享Day 15

竹子日誌（竹子） — Sun, 14 Sep 2025 01:38:17 GMT

日前有個業務朋友語重心長說了一句：

「我覺得當業務真的需要低一點的道德值」

我：「我懂～～特別是 2C 的業務」

對方：「所以我選 2B」

我：「我道德值太高，我當不了」

對方：「還好我道德值低你一點」

關於前端工程師的無關緊要的分享Day 14

竹子日誌（竹子） — Sat, 13 Sep 2025 16:40:04 GMT

每走一陣子會有一股迷茫，覺得努力做這麼多但都沒有進展。嘗試了很多事物，但不是每件事都可以得到很好的結果，有時候可能像是把東西丟進大海那種「噗通」就結束了。

最近靜下來思考，有沒有什麼可以繼續前進的道路？

關於我與前端無關緊要的分享Day 19

竹子日誌（竹子） — Fri, 12 Sep 2025 00:41:06 GMT

每一次開新專案都沒有一次是一樣的，每一次都在思考如何拆分如何共用，這些架構規劃很有趣，處理起來也很繁瑣。

這次老樣子先開 monorepo，我把測試相關的應用程式放在 apps 資料夾，拆分包分在 packages資料夾。起手勢就是把 eslint, builder 相關的 config 抽出來做共用。

過往都是玩純 rollup 打包，但因為想要玩 oxc 套餐，所以乾脆都用 vite 處理核心 UI 打包。不知道改成都用 vite 會不會有問題，但總是要解決的。

[Build in Public]

關於前端工程師的無關緊要的分享Day 12

竹子日誌（竹子） — Thu, 11 Sep 2025 12:00:07 GMT

我決定開始開啟我的 UI Library 專案，打算拿之前的 Side Project 來改。可能接下來會把一些開發瑣碎的小事情都寫上來，紀錄遇上的種種問題。

關於前端工程師的無關緊要的分享Day 13

竹子日誌（竹子） — Wed, 10 Sep 2025 01:00:22 GMT

數據上來講，前端前景一片大好。

前端的職缺數上升了，起薪也上升了。

但數據沒告訴你：

前端求職者人數上升的比職缺數快，所以僧多粥少，一個職缺有更多的競爭者。

起薪雖然上升，他背後的意思是「你沒有到這個起薪的功力你跨不進來，因為更低階的職位消失了」。

關於前端工程師的無關緊要的分享Day 9

竹子日誌（竹子） — Sun, 07 Sep 2025 12:22:53 GMT

我覺得現在做 Side Project 真的很難。

明明初期規劃 Product 的過程很辛苦，工作量龐大，然後要去統合很多職能。開始做之後夥伴又愛做不做，真的是工作是不會有那麼多的理由的。

但就是因為是 Side Project ，沒有支付薪資，那完全就是用愛發電，所以沒有辦法用任何「時程」去要求。

給錢，那肯定給不了「上班的薪水」。

不給，就會被說是「白嫖專業」。

談分潤，那叫「畫大餅」。

甚至有些開源項目真的是原作者「肝出來」，因為現在台灣環境會寫 Side Project 的人超級少。怎麼這麼說？因為我有一堆優秀的 Side Project 夥伴都是在國外的台灣人，那在台灣的人呢？

關於前端工程師的無關緊要的分享Day 7

竹子日誌（竹子） — Fri, 05 Sep 2025 13:15:36 GMT

跟老弟晚上去 Bar 享受悠哉的酒精。

閒聊一些有趣的事業話題，我還是喜歡理這種東西，相對有趣。

結束後漫步在深夜的街道，夜晚微風很涼爽，走得也全身熱呼呼的，酒感也退去了。突然覺得這樣也挺好的，很久沒有這樣的生活感。

總是忙碌於自己現在專注的事情，忙到忘記去真正享受自己想要的感覺。

關於前端工程師的無關緊要的分享Day 6

竹子日誌（竹子） — Fri, 05 Sep 2025 13:04:44 GMT

最近跟老朋友相聚，聊到了現在大環境對小孩不太友善，帶小孩出去都變成次等公民。

我朋友是對小孩有神之耐心，可以認認真真對待發瘋的小朋友，好好溝通講道理，循循善誘，真的是優秀好媽媽。兩個小孩很活潑，也偏吵鬧，但我對小孩子的耐心很好。我都會告訴我朋友：「沒事的，我不會覺得吵。」

但說起外面大環境的不友善，長輩他們匪夷所思，帶小孩小孩吵鬧哪裡錯了？我都懂，兩邊我都理解，但兩邊立場都無法相互理解。

我覺得，這世代很厭童⋯⋯

小孩，真的是沈重的負擔⋯⋯

關於前端工程師的無關緊要的分享Day 8

竹子日誌（竹子） — Fri, 05 Sep 2025 08:07:36 GMT

到底要不要使用 useMemo ？

我們寫 React 久了都吃到優化要用 useMemo，但使用的方式卻很多派系。

我以前不懂時覺得包一個 useMemo 感覺特別好閱讀，但後來才知道這樣有無謂的效能開銷。再後來我改成用 IIFE 寫，只為了閱讀更容易。但我最近又被說「包一個 useMemo 更好讀」，甚至告訴我「多開幾個變數宣告處理就不用寫 IIFE」，我真的是覺得頭很痛。

其實也是萬年話題，在現在 react compiler 沒有很普及，依然逃不過要花心思去優化 memo。

關於前端工程師的無關緊要的分享Day 11

竹子日誌（竹子） — Fri, 05 Sep 2025 05:00:32 GMT

去年搞了一整年的 UI Library 難產，總是把時間花在管理和人身上，導致實質自己的產出很糟，有時候真的一個人衝得快。

最近開始重新籌備 UI Library Project 的再次啟動，重新規劃創建架構，有一套比較完整的做法可以提供出來被執行。剩下我不打算花時間處理人的問題了，我打算自己按照內心所想的衝刺，願意跟上來的我再花時間。

這個題目想找到一起努力的夥伴很難，畢竟不是每個人都對這個題目有興趣。如果你喜歡這個題目，歡迎可以找我！

關於前端工程師的無關緊要的分享Day 10

竹子日誌（竹子） — Tue, 02 Sep 2025 04:51:36 GMT

我當工程師以前有一群很要好的朋友，但隨著我的成長與進步，我怎麼覺得那些朋友像以前一樣對待我。永遠把我當作那個天真傻氣的孩子，永遠把我當作小圈圈的丑角，甚至要做什麼理所當然認為你應該配合，私人空間的使用沒有尊重，久而久之⋯⋯

當已經習慣不尊重你身邊的人時，有一天他不再允許你對他不尊重，你會認為他變了。不是他變了，是他長大了。不是你沒變，而是你沒有長大。此時，這個團體就會漸行漸遠，宴席消散。

關於前端工程師的無關緊要的分享Day 5

竹子日誌（竹子） — Tue, 02 Sep 2025 00:01:01 GMT

大家都知道我是一個工程師，專門在軟體開發領域深耕，技術不外乎是程式撰寫。

但我技能真的只會寫軟體嗎？

其實我真的學過不少奇奇怪怪的技能，要羅列出來還真的一堆沒什麼關聯性的東西，不過也是因為這樣人生才這麼有趣吧？

改天分享一下這些奇奇怪怪的技能。

關於前端工程師的無關緊要的分享Day 4

竹子日誌（竹子） — Mon, 01 Sep 2025 23:47:54 GMT

有些人覺得我難聊，有些人覺得我好聊。

從過去到現在，身邊朋友們的話題不外乎買房、小孩、股票、健身、旅遊、虛擬貨幣。真的都是圍繞在這些東西，但這些東西我只對技術有興趣，自然我覺得就不好聊。

我喜歡的東西也不算少，也最近有人跟我聊商業、行銷、教學、MBTI、世界觀、人生觀⋯⋯我覺得聊這些很多深度刺激，很有趣。當然閒聊也有人會跟我聊美食、料理、咖啡、酒、動漫⋯⋯當然我不止這些東西能聊。

我覺得聊天是一種散射的光譜，只有重疊時才會疊出有趣的火花，當沒有生活沒有重疊點，自然聊起來索然無味。

關於前端工程師的無關緊要的分享Day 3

竹子日誌（竹子） — Mon, 01 Sep 2025 00:31:44 GMT

經常有人問我，怎麼樣成為「Senior 」？我曾經回答過無數的答案，總是想具體定義，但最後我發現，這其實不是他「真正想要的答案」。

最近我開始會想要挖掘「原動力」，因為一個人追求成為資深工程師只是為了薪水，一個人追求薪水只是追求背後原動力帶來的目的，如果滿足目標卻沒有滿足原動力，那最後只會很空虛。

最後，我只會定義這是一個「大題目」，如果是公開場合，我會講一個「標準答案」，但如果想要聽「理想答案」，那恐怕只有「合適的情境」我才能夠說出你真正想聽的答案。

你不會在這裡聽到多具體的東西的。

關於前端工程師的無關緊要的分享Day 2

竹子日誌（竹子） — Sun, 31 Aug 2025 15:37:21 GMT

最近 Side project 出現重大的轉折，我們團隊放棄原本的方向，重新修正策略。

有些題目氾濫成災，都是 Side Project 家常項目，無數的人充滿理想與豪情壯志要做，但大家都以為能做出什麼，事實上這些題目早已有無數的人嘗試了。

包含著，記帳軟體、XX地圖、旅遊規劃、媒合平台⋯⋯但這些頻繁到不能再頻繁的題目，卻是大家想要做的，但卻很難以商業化。

要做一個題目，是不是可以再花更多時間選擇題目的調查，評估「自己為什麼要做 Side Project 」，你才會知道該怎麼選。

關於前端工程師的無關緊要的分享Day 1

竹子日誌（竹子） — Sun, 31 Aug 2025 14:35:41 GMT

最近有朋友跟我分享，哪怕貼的是一些無關緊要的東西也是一種貼文取向。最近有點不想一直講生硬的主題，可能會開始帶入一些生活中無關緊要的東西。

就是這麼無關緊要，所以可能沒什麼營養，但也許某一天靈感來了就會發有重量的內容吧。

週五上版

竹子日誌（竹子） — Sat, 23 Aug 2025 15:03:37 GMT

在軟體業中，有沒有聽過一個不成文的規定，就是「不要在週五上版」。

這件事情很邪門，只要挑這天上版，就會很不妙的加班，就會很不妙的週六日假期會接到來自客戶的緊急問題。

你有遇過嗎？

設計要懂技術還是不要懂呢？

竹子日誌（竹子） — Fri, 22 Aug 2025 02:32:29 GMT

很多設計師常常會說「太懂技術會限制創意」，都會說「懂了技術規則比較沒辦法天馬行空」。

我個人經驗，因為自己是幹過前端和設計，我的做法是：

「設計時不要想怎麼實現，實做時不要回頭改設計」，當你兩邊同時思考只會都做不好。

所以請「換個位置換腦袋」。

但我最近也聽到一種說法：「懂規則是為了具備控制成本的能力」，掌控成本是一個很有商業價值的能力。

你會怎麼看呢？

Shadcn UI

竹子日誌（竹子） — Wed, 20 Aug 2025 12:24:48 GMT

近期覺得 Shadcn UI 氾濫，切版用、入門用、後台用、AI也推薦你用，看到 PoC 用、學生用、Side Project 用、面試者用，現在幾乎成為前端的優先選型，老實說有點疲乏。

我同意 Headless 系列的 UI Library 帶來極強的可修改性，但我覺得相對的也帶來很大的學習與閱讀負擔。甚至必須說很多細節的功能要你自己去實現。

沒有一套「完美的 Library 」，工程師永遠在「彈性」和「效率」之間取捨。選了彈性會犧牲點效率，選了效率會犧牲點彈性，這通常都是二擇一。做了幾年的工程師，選技術考量的已經不是「喜好」和「習慣」，而是「取捨」和「合適」。

鼓勵大家 Vibe

竹子日誌（竹子） — Wed, 20 Aug 2025 12:24:29 GMT

其實我非常推薦所有不是軟體背景的來玩玩看 Vibe Coding，我並沒有要刻意築起一道技術壁壘，而是希望大家能了解軟體開發這件事。

基本上軟體規模不大的時候，AI 能產生驚人的效果，真的可以快速解決問題，快速開發，讓你瞬間好像擁有一個會寫程式的小夥伴。但跟人類一樣，AI 也會犯錯，對他依然要有耐心，具體告訴他問題在哪，他會更快幫你修復 Bug。

但到了規模突破到某個瓶頸，AI 處理問題漸漸不管用，而且也不會隨之成長與記憶，每一次溝通都得重新把你的訴求轉達給他。這些訴求越是複雜，他越容易搞混，而且你需要花費更多的 tokens(錢）去支持開發。

隨著規模成長到無法控制的程度，自然也更懂得為什麼要有「軟體工程師」，為什麼純粹依賴 AI 無法取代工程師，它頂多是一個輔助者。

每一個跟我說「那個叫 AI 弄一弄應該很快吧？」，我都會請他「那你讓 AI 做就好，我知道你不需要我😊」

Side Project 的找人的感想

竹子日誌（竹子） — Wed, 20 Aug 2025 01:28:08 GMT

可能很多人在找 Side project 的夥伴時會擔心「這個人外務這麼多，有時間做 side project 嗎？」，有些是「這個人目前挺閒的，應該會分配更多時間給我的 project 吧？」

然而，我不是這麼想。

我反而覺得「習慣去花時間在非盈利外務的人，才是真正會擠出時間的人」。擠出時間從來不是這個人是不是比較有空，而是這個人喜不習慣擠出時間做額外的事情。

有些人會花比較多時間準備業內的事情。

有些人會花比較多時間陪伴家人。

有些人會花比較多時間加班。

有些人會花比較多時間接案。

那麽這種人比較不會花時間做 side project 。

沒有對錯，這是他選擇的人生，我尊重。但作為一個評估者，我會更想找願意投人更多的人，而不是答應能付出多少時間卻做不到的人。對於一個發起 side project 的人很困擾，所以

伸手牌

竹子日誌（竹子） — Mon, 18 Aug 2025 10:14:58 GMT

工程師群體總是很樂意回答問題，充滿愛心和關心。但我原則就是「個人學習無償幫忙，公司問題絕不幫忙」，因為幫忙這種東西就是貶低自己的價值，助長慣老闆伸手牌。

日前聽到慣老闆朋友分享他如何去工程師社團伸手牌，到處白嫖熱心工程師，聽了真的讓人一把火。我當然不會講什麼，只能默默心裡不爽。

幫忙是有限度的，技術是有牌價的。

AI 的嘗試

竹子日誌（竹子） — Tue, 12 Aug 2025 14:26:41 GMT

數個月下來，我讓 AI 幫我產出不同的東西，我逐漸掌握他的套路，我開始對他的產出日漸不滿。現在各家 AI 廠商對於 tokens 的開銷越來越大，但限制就硬生生擺在那，實在不太有重大突破。

腳本是我覺得最優秀的，通常沒什麼上下文，做的事情也單純，幾乎都可以精準完成。

接著是文件，雖然好像很豐富的給很多東西，也沒有所謂標準的對或不對，但真的產出太多沒什麼用的東西。需要花很多時間刪減與細化，這還需要琢磨。

再來是單元測試，其實成效都蠻好的，該 mock 會 mock。也可以產出豐富可用的 Test Case，不要太在意架構，其實都可以很滿足需要。

但也有很差勁的。

分析複雜的程式，經常會錯誤分析，不然用幾個隨便的文字唬爛你。

切版，大多無法精確處理，就是會歪掉，就是會缺漏。沒辦法真的表現出設計稿的成果，總是會有明顯肉眼可見得大問題。

反正結果而已，我還在努力嘗試，希望更進一步有突破。

感觸

竹子日誌（竹子） — Sat, 09 Aug 2025 12:21:04 GMT

如果拓展業務是靠騷擾人

如果跟進客戶是靠奪命連環叩

如果自以為的關心只是為了建立潛在客戶

如果佔朋友勞力和技術的便宜是商業成本的優化

這種人的人生成功，我就是鄙視

我的新方向

竹子日誌（竹子） — Sat, 09 Aug 2025 07:51:09 GMT

我希望成為一個技術資訊的宣揚者，讓消費者更刁鑽的去要求網站品質，讓大家享受更好得體驗。踢除不好的品牌，不要只是招搖撞騙。

Web 和 App 的差別

竹子日誌（竹子） — Fri, 08 Aug 2025 00:21:08 GMT

很多應用程式我們都會看到做 Web 和 App ，就算都是 Mobile ，但因為運行環境不一樣，所以操作也截然不同。本篇撇除工程意義上的不同，我直接來看對於使用者體驗上的不同。

到底有什麼不同？

Web 的操作行為不同，舉凡如上一頁、下一頁、重新整理、貼上網址、滑鼠右鍵、啟動閱讀器、修改放大比例⋯⋯諸多介面外的特殊操作。

Web 的權限不同，在 App 所有操作權限，舉凡定位、攝影機、檔案操作、通知系統⋯⋯都是直接收到作業系統管制，而Web 是基於瀏覽器之上再去做一次權限細分，而且全部是「預設關閉」，第一次請求會詢問開啟。只要任何一關檢查不過，通通無法操作。

Web 多了一個外框。因為多了一個追加功能的外框 UI，所以顯示空間更加擁擠，要更有效去管理介面上的顯示。

版本兼容問題，App 壽命直接受到「作業系統」限制，而作業系統受到「裝置」限制，加上行動裝置的壽命短，通常很難超過十年。但桌上型裝置動不動超過十年壽命，作業系統不升級更是常態，Web 要做向下兼容的範圍更廣、更難技術迭代。但相對的，強行為使用者升版也是 Web 的優勢，說升級就升級。

很明顯大致方向都是 Web 的限制更多，但操作方式更複雜，但因為限制和通用性，維護起來確實輕鬆不少。在諸多限制和基礎功能繁多的前提，其實 Web 很明顯是更難設計的，要考慮使用者會對你應用程式所做的操作其實更多。

最後我必須說，不要把 Web 當 App 去設計，你永遠不能去限制使用者行為，更無法阻擋使用者去做這些操作，不要異想天開去封鎖使用者行為，這些封鎖行為加諸的代價是需要更高昂的成本去維持的。

Token 很貴

竹子日誌（竹子） — Mon, 04 Aug 2025 10:24:09 GMT

今天看到最好笑的一句話：

「不是大家不想要全 Vibe Coding，是工程師比 Tokens 還便宜」

阻礙 Vibe coding 的極限竟然會是 token 太貴⋯⋯

隨手開發小記

竹子日誌（竹子） — Mon, 04 Aug 2025 05:48:24 GMT

平常開發會用 position absolute + inset 填滿這種技法去拉撐 html。

但這技法在 Firefox 中，input, img, video… 等等無結尾標籤的 html 會失效，這時要搭配 width, height 100% 來填滿。

通常 flex 之下，flex-shrink 如果大於 1，如果內容過多，都會壓縮回 flex 大小。

但在 webkit 核心中(safari)，這種壓縮效果會失效。

效能優化故事

竹子日誌（竹子） — Fri, 01 Aug 2025 06:27:13 GMT

最近踩到一個很有趣的坑，值得分享一下。

多數業務場景多半都是遇到 JavaScript 的效能瓶頸比較多，所以多數面試都是考框架效能的優化。但真實讓你遇上很邊緣的問題時，整個尋找問題的流程變得很不容易。

事情是這樣的，工作上有某個 Issue 是這樣說：「當某個頁面打開 devtool 時，畫面會非常卡頓，甚至卡死。」

剛開始我往 debug 功能相關問題尋找，但我怎麼找都找不到相關的問題。甚至無法重現這個問題，我只好先模仿那個生產環境去實現，並且採用「降低 CPU 運算」的方式去測試。

後來我意外發現跟 devtool 一點關係都沒有，只要出發任何 browser resize 都會加重這件事的顯現，只是剛好打開 devtool 觸發了 resize 導致這件事。

但只是 resize 都不夠證明效能瓶頸的原因，這時候只能使用 performance recoding 去錄製效能分析。結果是發現大部分的瓶頸都卡在 Render 這個環節，反而是 JavaScript 部分根本沒什麼瓶頸。

這就怪了，通常會在這塊出現瓶頸都是 DOM 過多，或是渲染計算過於複雜。但我一看，DOM 總數大概在 1500 左右，而經驗上要遇上瓶頸少說也要5000 甚至 10000 以上的 Node 才會有體感。

當然，回到用最老套的方法，「註解大法」。

我一步步縮小這個範圍，結果元兇竟然是⋯⋯

「Textarea」

我真的想不到，Textarea 當渲染過多的「value」時，也會造成巨大的瓶頸。當然，知道問題後，後面就開始一系列的解決方案討論，但真再次刷新我的三觀⋯⋯⋯

被罵的 Web RWD 系列（一）

竹子日誌（竹子） — Fri, 01 Aug 2025 00:22:51 GMT

有鑑於這個系列三觀跟很多人不合，也會不小心噴到很多設計師工程師，我就直接歸類為被罵系列。我覺得這個應該也可以開很多集。

======

對於用戶來說。電腦板不單單只是閱讀空間比較大，甚至很多螢幕會再次進行放大，所以文字大部分情況在電腦板的都沒什麼問題。

以按鈕為例，依照我的開發經驗，最適合閱讀和操作的一個組合。

FontSize 18px

LienHeight 1.5

Padding 8px 16px

很大？確實習慣來說確實蠻大的。

但到了「手機版」這種小螢幕場景，很多設計師習慣性直接把文字大小壓低到 14px 甚至 12px，縮減各種間距，極盡所能壓榨出更多畫面空間。整個畫面極其擁擠，甚至大幅度改變排版邏輯，只為了畫面可以更多東西。

但我也知道，很多設計師有苦說不出口。業主希望「可以一個畫面看到全部東西」，但這件事對於使用者來說本身就是負擔。手機已經夠小夠難閱讀了，所有的元素又要再縮小一號。桌機明明可以足量留白產生出足夠的美感，降低資訊量，但卻瘋狂塞入不必要的資訊讓閱讀者更加疲累。

雖然像是 Bootstrap 很早就支援 RWD 字體，但其實根本滿足不了現實情境。最終前端只好手動追加大量的 media query ，sm, xs, xxs, xxxs…

最可怕的是「年長者必殺技」，字體放大 200%。然後發現很多按鈕看不到字，甚至破版到連點擊都點不到。網頁不是純粹服務「好看」，而是拿來「使用」，如果為了好看而失去彈性的易用性就本末導致了。不要老是嘲笑長輩不愛用 3C，是整個軟體設計根本對這些「長輩」和「視覺障礙者」非常不友好。

也有人說，年輕人好像沒差？確實沒差，文字小或大，年輕人實在不在意，但對於眼睛不好的族群真的是折磨。那你的 TA 是誰？難道你想跟我說「都可以是 TA」？我怎麼覺得這句話很眼熟？

我經常說的，UI 設計不只是畫圖的。我聽過一句話：「UI/UX 本身就是一體兩面，UI 只是 UX 的一種體現」，你到底是在做 Web 還是做海報呢？

關於網頁字體（一）

竹子日誌（竹子） — Wed, 30 Jul 2025 00:22:18 GMT

網頁字體的知識點可以說是一個大坑，可以講的東西多如牛毛，幾乎可以開一整個系列來說。

但我今天會針對幾個常見的東西來談談。

網頁並不是本身具備各式各樣的字體，而是靠電腦內部預設安裝的字體來產生各式各樣的字型（font family）。但也可以由網站本身去下載字體讓系統去讀取，可以支援的檔案格式有 ttf, eot, woff… 等等。

字體檔本身是什麼？

其實你可以想像是一組組的 image sprites 湊出來的向量圖，宣告著粗體、斜體、扁體、窄體等等，這些排列組合是「指數相乘」增長。更恐怖的是中文因為文字符號龐大，每「一個字」就會有一組，再乘上前面講的排列組合，所以通常中文的字體會比較肥大。

（準確說法待大神補充）

所以流量考慮，其實網頁不適合大量採用不同的字體，能預設就用預設。我知道，預設字體普遍很醜⋯⋯⋯

Figma MCP

竹子日誌（竹子） — Tue, 22 Jul 2025 13:38:59 GMT

現在每個工程師都追求用 AI 帶來更高的產出，精心規劃了自己的 project contexts 幫助產出。我完全能同意專案由無到有用 AI 可以大幅提高速度，一些瑣碎的工作可以加速收效。

但我真的可以完全交給 AI 工作了嗎？

大家常說的，你的 prompt 要下清楚。

意味著 AI 不會幫你規劃複雜的系統架構，你需要什麼都要講清楚說明白。說真的，

Design System

竹子日誌（竹子） — Sat, 05 Jul 2025 16:11:28 GMT

經常大家認知的 Design system 就停留在色票、文字、元件⋯⋯這些東西，但做過 Design system project 後，我認為並不是這麼狹隘的東西。

什麼是好 Code？

竹子日誌（竹子） — Thu, 03 Jul 2025 12:04:40 GMT

以前工程師常常：「喔，你的扣好難懂喔～」

但這樣怪來怪去，到底什麼是好懂的程式？這個可以說是沒有標準，大家責怪來責怪去。

近期，我覺得有個很好的標準了。

那就是使用 AI 去決定。

AI 閱讀力相對是客觀的，理解的 Context 越少，越能靠通用知識去理解，而不是靠腦補或分析。

最近讓 AI 去分析老專案的程式，分析出來的結果可以說是錯誤百出，完全不行。真的能完全相信或信賴嗎？我覺得基本上不行，人的分析能力依然遠遠超過 AI，就只是慢而已。

只能說，AI 很好用，但有限。這已經不是 prompt 的問題，不需要再責怪是 prompt 沒下好，這種東西是一番兩瞪眼的。

AI 的成果取決於你的管理能力

竹子日誌（竹子） — Wed, 02 Jul 2025 04:14:24 GMT

最近越來越覺得 Token 不夠，開始嘗試大小工作都外包給 AI 工作。不管是規劃任務、研究專案、技術分析、功能實作⋯⋯幾乎想得到的事情都可以有給他。我的工作就是架構、檢查、驗證，甚至幫他處理很蠢的 Bug。

欸？怎麼工作內容和當一個 Team Leader 很像？

我目前覺得 AI 很聰明，我想要執行的任務它幾乎可以承接，我拆的越細，它做的越好。但我越發感覺它無法取代我，一旦我工作交代不清楚、拆分不細緻、決策不恰當，它馬上出包，沒有意外、沒有驚喜、沒有不小心，100% 會因為我的失誤搞砸。

不要說 AI 厲害到可以處理的很好，他們只是能力值點的比較平均的 Junior ，他們什麼都會，只要指示清楚都做的很好。但多半情況下需要你去把關跟處理，犯蠢次數絕對不少。也經常會傻傻的去執行錯誤決策，明明有更多更好的方案，但他們完全不會在處理過程提出質疑，或是有效的回報情況。

欸？這怎麼跟底下全部是聽話員工的主管面臨的窘境一樣？喜歡 AI 的原來是慣老闆 😈

最終，依然需要大量依靠我去分析問題，找出問題。需要有良好的技術和知識去支撐我的策略。技術人才的知識與真實情況的整合，以及產業的實戰經驗依然無可取代。

傻傻搞不清楚

竹子日誌（竹子） — Tue, 01 Jul 2025 04:28:39 GMT

基於 JSDC 小聚現場所提到，現在的 SSR 已經跟你想的那個 SSR 不一樣了。

一堆名詞，你真的都聽過嗎？

除了 CSR, SSR, SSG，我在查資料過程中還發現了 ISR 和 PPR，真的是一堆名詞，光要搞清楚差異就一顆頭兩顆大了⋯⋯

JSDC 小聚

竹子日誌（竹子） — Sun, 29 Jun 2025 15:24:03 GMT

原本以為是20人小場，結果現場是百人大場，這小聚也太「小聚」了，嚇死XD

很感謝 SPT 總召的介紹，也很感謝 JSDC 總召的照顧，剛好人生成就解鎖。

這場其實壓力蠻大的，底下成員喵到很多大神偷偷坐在底下聽，害我好緊張。還被抓到簡報勘誤，雖然很感謝指正的會眾，但也真是糗。20分鐘比想像中還短，全程飆車、原本預期的內容刪減刪減再刪減，看到時間飛速而過，後半開始語無倫次⋯⋯

不過還是很感謝 JSDC 工作人員和會眾的大家！

前端 Serverless

竹子日誌（竹子） — Fri, 27 Jun 2025 00:21:40 GMT

許多從前端剛摸後端的人以為連線資料庫只是一個單純的 HTTP 請求，事實上，資料庫服務溝通其實很多時候是一個 Socket 連線，並不是你以為的 WebSocket，而是純粹的 TCP 請求。

前端近年 SSR 架構興起，也因為 Next.js 的推動，Rendering Service 流行起採用 Serverless 架構，以加速爭取更多的效能優化。然而，隨著架構的拓展，除了一般的請求外，開始需要 Redis, Message Queue 之類的服務，這時候問題就開始浮現。

Serverless 實現中，常常會使用 Edge runtime 這樣的啟動環境。打一個比喻，就是閹割版的 nodejs，它很多功能不存在，但也因為輕量換取跟多的速度和模擬環境的能力。然而這些細節並不是每個在寫 serverless 的前端都有注意到，某天你想串接外部服務，你會注意到⋯⋯

「欸？為什麼沒有 ”net” module？」

沒有錯，確實 Edge runtime 沒有Socket 的能力，也就是不能採用一般的方法去連線這些外部模組，只能採取純粹的 http fetch。

最近實作這些架構真是踩的傷痕累累，只能怪自己後端架構知識不足。

Vibe Coding 的感覺

竹子日誌（竹子） — Tue, 17 Jun 2025 15:55:09 GMT

最近為了做教學案例，希望快速產出後端服務，我用了 Claude Code 快速建置後端專案。含微調不到 30分鐘，哇～超快呀！如果是我自己寫可能要兩三個小時吧。

後端要失業了⋯⋯

欸！不是啦，講這種話等一下又炎上XD

我只是想分享很好用，沒有其他意思。但確實可以在 0 - 70 的階段馬上有成果，真的很有效率。對於前端教學來說，馬上有後端服務可以打，真的挺方便的。

一定要用 TypeScript 嗎？

竹子日誌（竹子） — Wed, 11 Jun 2025 00:17:22 GMT

過去其實出過不少 JavaScript 的超集，包含 Coffee Script 、Flow ⋯⋯等等。近年真的是 TypeScript 獨霸市場，幾乎快要成為前端一致認可的標準，成熟的 Library 幾乎會與 TypeScript 綁在一起。

然而，我也依然會聽到這樣的聲音：

TypeScript 的開發成本過高，不適合快節奏的公司導入。
TypeScript 編譯需要比較多的時間，對 CI/CD 很沒效率。
公司專案很老舊，不適合再導入。

這些問題我「認同」，但也覺得不是問題：

覺得定義型別成本高，可以寫 Any。
覺得編譯成本高，其實可以做部分預編譯。
公司專案還在 JavaScript 可以用 JSDoc 漸進導入。

但必須說，沒有使用 TypeScript 時，稍微大一點的專案真的很痛苦。

可能一不小心就操作到 undefined 。
無意識會做大量動態操作。
當參數穿越多個元件，難以預期是什麼東西。
沒有文件時，理解難度上升。
AI 工具更難預期上下文。

曾經有一位大神這麼說過：「當你團隊超過三人協作，而且是長期維護的產品，卻不打算導入 TypeScript ，這是對你的專案不重視」

這話是比較過激，但某種意義上卻代表著

處理資料

竹子日誌（竹子） — Mon, 02 Jun 2025 02:20:01 GMT

前後端在處理資料這件事上的思路差別，這是一段還沒寫完就擱著的隨手筆記，先留個開頭。

創業格局

竹子日誌（竹子） — Sun, 01 Jun 2025 07:49:26 GMT

前幾天跟朋友爭執，一個產品到底要拿什麼程度出來才算產品？

現實是，你拿出跟玩具一樣的東西，別人就把它當玩具。當你問任何回饋，人家給你的是玩具的回饋。如果你拿出像樣的東西出來，別人也會拿出像樣的回饋。

當你讓別人感覺到你玩真的，別人才會把你當一回事。

新技術

竹子日誌（竹子） — Thu, 29 May 2025 01:23:06 GMT

每一次技術圈流行起新技術都會有一波革命。

不管是 AI 也好

還是 Notion 也好

還是 Figma 也好

還是 Frontend Framework 也好

還是 Docker 也好

每一個專業圈層都會遇到這事情

沒有工具能談得上長長久久

一定會有迭代與升級
一定會有各種痛苦

隨著產品的成長，迭代與升級難度也會增加

緊接著開始被時代洪流衝擊

保守派會說：

舊的東西和流程跑那麼久都沒問題，不要改變。

改革派會說：

你不調整與升級，要進步會更困難，資源會越來越匱乏。

其實都有道理…你會怎麼選擇和解決？

Figma Auto Layout

竹子日誌（竹子） — Tue, 27 May 2025 00:38:54 GMT

我覺得 auto layout 某種層面就模擬了 CSS Flex box 的特性，真的大幅改變了 UI 設計稿的生態。

在過去畫設計稿，大家都以為是畫圖，大家常用 Illustrator, Photoshop 來畫出介面，甚至有的直接給你 PDF或 JPG 等等。但身為前端工程師的我體驗到那個世代各種恐怖的溝通地獄，和設計師吵不完的架，永遠雙方僵持不下。

有了 Auto Layout 的世界，這條溝通橫溝被打破，有了一個可以被溝通的語言。雖然還是有些詞彙不相同，但終於有了可以被對等交談方案，設計師開始理解「網頁佈局」這件事。

剛開始我聽到的是⋯⋯

「Auto Layout 太花時間了，不可能都用啦！」

「為了效率，我覺得我部分使用 Auto Layout。」

很有趣的，現在設計師圈之中出現了歧視鏈。

「蛤？為什麼這個沒有用 Auto Layout 包！」

「Auto Layout 很麻煩嗎？那是你懶」

看著這個現象的變遷，我真的覺得很有趣⋯⋯

前幾年因為某間公司不重視設計，身為前端的我強迫要學習 Figma，因為他們認為「畫面都是前端的事」。當時惡補了 Figma，規劃了整個 UX Flow，希望可以為產品提供價值。到現在這些都是我和設計師可以平行溝通的語言，雖然時間有限，但我持續吸收關於設計的知識。

大家都會要求設計師學一些工程，也會要求設計師做點專案管理和產品規劃。然而，為什麼從來沒聽過有人要求工程師去學點設計呢？設計價值真的這麼不值嗎？我覺得這些都是藐視產品價值，設計價值也是最大體現前端價值的地方。不是什麼單純讓介面變漂亮，而是要創造更好的體驗其實要仰賴設計與前端。

元件拆分

竹子日誌（竹子） — Tue, 27 May 2025 00:09:58 GMT

剛開始寫程式不太久的人總認為「Code 太多就拆另一個元件」，稍微哪裡的業務邏輯一多就拆，很快就充斥著不知道幹嘛的元件。

明明放在共用區，卻有很多特殊判斷要處理被哪邊使用的特例，結果為了判斷行為寫了好幾個 if 處理特例。

明明放在共用元件，卻只有一個地方使用它。

明明是抽象模組，卻到處都有Router、i18n、API 等等功能。

這些都是急切著抽出共用的結果。

拆元件的目的不是因為大而拆，而是為了更容易理解、更好的渲染效益、更好的共用。

我知道這些對於經驗不足的工程師很困難，特別是 Vibe Coding 當道的今天，AI 是沒有人性的，它們只是數據比對的結果，沒有場景、沒有環境、沒有想法，只是數據堆疊的結果。你知道為什麼 AI 這麼拆分嗎？你不會知道的。

學習的方法

竹子日誌（竹子） — Fri, 23 May 2025 00:38:47 GMT

我覺得大多人都被「學習」的既定印象給綁架了，遇到了一些事，讓我認為需要重新說說關於「學習」這件事。傳統上，大家會認為學習就是在教師的底下傻聽著知識的輸出。到了現在，線上影音平台興起，所以看影音課程的學習方式成為了主流。但是… 學習真的是這樣嗎？

但事實上，學習存在多種形式，除了單向的「輸入式學習」外，其實還需要「輸出式學習」，這也是現在大多數的人缺乏的。在你不斷輸入的同時，沒有足夠的輸出是無法內化技能的。

輸出方式有哪些？

實際做一次：學了東西就要實際用看看，管他對或不對，用了就會有錯誤與失敗的各種反饋。最差最差，依樣畫葫蘆跟著做，也會培養出肌肉記憶。
費曼學習法：簡單講就是把你會的東西再去試著教另一個不會的，你會重複驗證你是否會了，在這嘗試輸出過程中，你會質疑自己，內化知識
想像做一次：對於有一定知識和能力的人，突然間吞下別人複雜的解決方案，不如想實際走一次坑，然後去看別人的做法，才能快速理解用意。
AI 學習法：搭配 AI 可以輸入可以輸出，這個先不多做說明，以後再聊。

真要講，太多可以說的啦，還是留一個懸念吧～

到處都有人想白嫖你

竹子日誌（竹子） — Wed, 21 May 2025 10:14:59 GMT

身為一個長期的的技術工作者，商場上遇到不少妖魔鬼怪，有不少自稱「創業家」都想跟你用免費凹一點技術勞力，都想用空手套白狼的方式跟你索取付出來「實驗」他的想法。

這時候資源是不對等的，其實技術工作者這時是站在談判中有利的那邊，不需要賤價去販售自己的技術與勞力。這個實驗不是免費的，如果沒有利潤和機制上的保障，其實你就是被白嫖而已。

除了這些創業者，更沒天良的是打著「尋找熱誠的技術人提供公益服務」，實際上只想滿足自己的成績需求，而不思考自己做的事帶給對方的兌換價值。

人類啊⋯⋯

Service Worker

竹子日誌（竹子） — Mon, 19 May 2025 13:04:48 GMT

這是一個可以註冊一些 JavaScript 讓瀏覽器背景運作的功能，知名的 PWA 就是基於這樣的系統架構達到這樣的效果。

它可以解決很多你意想不到的東西，包含著長期快取、Web Push、攔截請求、背景長連接。就像是一個開在瀏覽器的伺服器，做各種長時間的背景工作。甚至不卡住瀏覽器主線程去背後做各種運算也沒問題，可以說是相當好用。

最近工作用到，隨意紀錄一下。

AI 的東西不要照單全收

竹子日誌（竹子） — Thu, 15 May 2025 11:33:01 GMT

我要認真強調，使用 AI 吐出來的結果絕對不要全盤接受，一定要閱讀、理解、驗證。AI 可以讓你 0 到 70% 飛快完成，但最後那 30% 依舊要你自己去補足。

人都會出錯，你怎麼相信 AI 給你的東西不出錯？得到一個新的結果時，不是無腦複製貼上收工，要理解、要驗證、要測試、要微調，因為交付出去的程度是你負責啊！出問題了，事後一句「那是 AI 產生的」，聽在耳裡的主管心裡怎麼想？

Refresh Token

竹子日誌（竹子） — Sun, 04 May 2025 06:06:05 GMT

相信寫一陣子的前端都對這個機制感到熟悉，這是我做過所有前端需求中，不但通用，而且困難度相當高的機制。有的系統會直接放棄實作，有的系統是有做跟沒做一樣。

這個機制有很多知識點，比方說非同步處理、閉包、重試限制機制等等。

這也只是基礎的處理。

如果要考慮完善，可能依賴反轉、解耦等等，難度可以說三級跳。

如果你是 Server Side，甚至要熟悉 Cookie 機制、前後端溝通、記憶體洩漏處理。

Refresh token 機制，我幾乎沒看到有什麼業界統一的做法或標準化套件。就算看到套件，大約超過一半的邏輯還是得自己實作。甚至都有節點介接與事件攔截的問題，沒有看到一個通則做法。

如果是我孤陋寡聞，還請大家多多分享一下文章和做法。

Design Token：設計與前端之間的溝通語言

竹子日誌（竹子） — Fri, 25 Apr 2025 00:25:21 GMT

這是一個近年流行的一個前端設計之間的溝通語言，雖然不算普及，但大部分會理解為變數的應用。

雖然早在 sass 流行時期已經被廣泛應用在各種 UI Framework 上面，但實際上被應用的比率依舊不高。

Design token 帶來最大的價值是對於應用的 CSS 實施規範化的共用，讓這件事不單單是開發的事，更讓設計師參與了開發流程。相對的代價，就是知識的門檻，沒有一定的知識量沒辦法把控這套系統。

Design Token 按等級區分排列有 System Token, Seed Token, Alias Token 三個大項，依照團隊需要會再變種。

嗯嗯⋯⋯實務上⋯⋯⋯

其實會使用的工程師和設計師真的不多⋯⋯

造一個 UI 輪子 ep1

竹子日誌（竹子） — Mon, 21 Apr 2025 16:40:00 GMT

最近暫停了 UI Library 的專案，覺得一群人走的好疲憊，我想一個人做。重新回到自己火力全開的開發，琢磨各種架構和 UI 元件底層。

說到開發 UI 元件，從基礎元件來說肯定就是 Button 了！很基礎，應該⋯⋯很簡單吧？

但基於 Design Token 去寫才發現，Variants, Theme, Size, Shape … 等等參數寫一波，才發現 Token 的關聯性、色彩的平衡感、權重配置ㄉ等等⋯⋯

真的不是普通的麻煩，超級複雜啊啊啊！

State management

竹子日誌（竹子） — Wed, 16 Apr 2025 13:50:26 GMT

問我最好用的狀態管理機是哪一款？

你會說 Redux? Zustand? Vuex? Pinia?

確實在每個時代都帶來巨大的價值，我覺得他們都不錯用，但我更喜歡 Proxy base 的狀態管理機，方便直覺又單純。

那別賣關子了，我覺得最好用的狀態管理機是 vue。

蛤？你沒聽錯，就是 vue。

useEffect 要 Cleanup

竹子日誌（竹子） — Wed, 16 Apr 2025 13:45:28 GMT

分享一下前陣子工作上遇到的感觸

我們寫那麼久的 React，從 functional component 寫都知道 useEffect 要 cleanup，講的大家都知道。聽了任何事件要清除，改了外部狀態要恢復。

但 Promise 的 callback 嚴格來說也是一個 event callback，那是不是也應該 cleanup？

不管你認不認同，我覺得只要在 react component 裡面去做了任何 Promise 行為，那就應該要用 useEffect 去更新狀態和清除事件。

官方寫了一個案例：

https://react.dev/learn/synchronizing-with-effects#fetching-data

雖然這麼說極端了點，但常態的 useEffect + fetch 要這麼寫應該沒毛病了吧？

不過最好的方法還是 tanstack query 治百病XD

分享我使用 AI 的方法

竹子日誌（竹子） — Wed, 16 Apr 2025 00:10:39 GMT

前置聲明，面對巨大而混亂的系統，AI 幾乎難以幫上什麼關鍵。

現在開發 side project ，我開始採用 AI 來幫我逐序產生出東西。

最初從 user story、核心需求開始分析，搞清楚產品方向。

再來產出架構文件，挑選技術選型、規格等等，閱讀審核精修一些小地方。甚至 AI 沒考慮到的要補上去，這個是全部流程中最困難也最關鍵的地方。

接著就可以逐步產出架構程式碼，這時要費的心力會開始增加，你要不斷回頭修正文件。

此時再把這些架構實作再寫回去架構文件，作為 Context 的核心。並且可以產生單元測試，確保後面的動作。

接著可以依據每個業務需求開始撰寫頁面文件，設計、規劃各種使用者實際的場景。

最後再以前面所有累積的文件再去產生程式碼，如果有不合口味的再追加專案準則規範與最佳實踐案例。這個步驟可以依序從資料庫、API、頁面逐步作，吐出來後確認沒問題放進專案。

這每一步都幾乎可以讓 AI 幫忙做事，基礎大量的東西全部是 AI 產生，真的省掉一堆時間。穩定性也很好，可以不斷依照「文件」當基礎去產生結果，有時候 AI 也會採用意想不到的做法。

這個方式也不是完美，因為所有的效益跟穩定歸因為「架構考量」，如果架構階段的考量不夠，那麼後面也會整個歪掉。但這真的有種管理大型團隊的感覺，非常有趣。

你都怎麼使用 AI 呢？

到底要了解多底層？

竹子日誌（竹子） — Sat, 12 Apr 2025 05:44:22 GMT

資深的總是會告訴你，「要多了解底層」。

但你不覺得這個「底層」到底是要多「底層」？

專案架構了解完要看框架函式庫原始碼。

原始碼看完要看協定實作。

協定看完要看組合語言記憶體操作。

組合語言看完要看⋯⋯⋯

何必呢？

我的想法

其實只要穩定且被統一的東西

都不需要了解實作細節

你需要了解的是「要做什麼」、「規範」、「特性」

不是操作介面

不是實現實作

更不是工具

追求的是「本質」

版本迭代，介面和實作會改變

趨勢改變，工具會改變

這些學習逐漸不管用

現在的技術更迭和變化快到不可思議

不斷去追求「底層」其實非常有限

花了很多時間卻沒有效益

CommonJS 前往 ESModule

竹子日誌（竹子） — Sun, 30 Mar 2025 02:58:04 GMT

ES6 ESModule 的模組化協議橫空出世，當時被 Node.js 的標準霸佔的 CommonJS 近年被社群逐漸蠶食，慢慢大家都只寫 ESModule。但事實上，大家寫的 ESModule 並不是真的上了瀏覽器還是用 ESModule 的標準在運行，而是透過打包工具如 Webpack, Rollup 之類的工具在進行處理，再透過如 Babel, ESBuild, SWC 之類的工具進行語法轉譯，端看最後跑出來的結果。

然而，隨著大家轉往 ESModule ，舊專案也開始要遷移，雖然大部分情況可以採用語法轉譯處理，但就是有一些麻煩的東西。

一個是 ESModule 多了 “export default” ，這是 CommonJS 沒有的概念，和 “module.export” 的物件是不同的結構概念，需要針對不同的應用方式去修正轉譯方式。

而最麻煩的莫過於「require」這個語法，轉換到 ESModule 肯定不少人吃過虧吧？如果裡面還去組裝 dynamic path，那可以說是非常難以遷移。也從 sync 變成 async，邏輯上就得採用截然不同的策略。這個部分修改起來可以說是頗爲費工，甚至會牽動很多邏輯。

常常聽到有人認為這單純可以靠轉換解決，但他們不知道的是，這兩種模組化並不是等價的，依照轉譯和撰寫的邏輯不同，就有不同的結果。但現代 ESModule 的 Tree shaking 是很誘人的價值，可以帶來的成效可見一般。

CSS In JS

竹子日誌（竹子） — Sat, 29 Mar 2025 10:32:51 GMT

styled-components 終止更新，進入長期維護階段，這件事社群沸沸揚揚。

有人說，這件事代表的是一代技術的興衰，隨著 Atomic CSS 的興起，逐漸大家捨棄了原本 cssinjs 的方案。也有人說，與其使用 runtime 的 CSS 手段，應該採用 Zero runtime 的方案。更甚至有人說應該採用 CSS Module 的方式。

但是⋯⋯真的是這樣嗎？

沒有哪個方案「應該被淘汰」

其實所有的解決方法都有其存在價值，我認為沒有一個方案是「應該被淘汰」的，而是基於業務場景評估技術的價值和優劣。

以其他技術來說，相較 cssinjs，你會發現它依然有很多無可取代之處。

拿 Atomic CSS、CSS Module、Zero Runtime 來比

Atomic CSS 來說，它非常原子化的去拆分 CSS，也造成閱讀上 class 命名的冗長，最後依靠 apply 去重新 merge 多個功能，最後依然走回最傳統的 css 使用令人詬病的老路。

CSS Module 來說，一組 module css 綁定著一支 css 檔案，你放不開這組綁定關係。撰寫時使用方式也是頗費勁，需要宣告長長的 class name。css module 因為經過打包，也有蠻多頗麻煩的運行問題，當發生 bug 時不容易排查。

Zero Runtime 來說，目前主流的 Unocss 也是 runtime ，但體驗也並不差。有人說對於 zero runtime 是為了求更快的初次渲染速度。不過 cssinjs 是可以有辦法做到靜態分析，也可以在伺服器渲染時去分析靜態的 css 直接渲染到 html 上，更也能同時兼容進入瀏覽器上去水合(hydration) 整個CSS，所以彈性反而比追求 zero runtime 更高。也有人詬病 bundle size 的肥大，但除了 styled-components 外，好比 emotion，可以做到 css merge，它可以整併一模一樣的 css string，進一步去共用重複的 class。

cssinjs 不是該被淘汰，是還沒被做完

我想說的是，你認為的 cssinjs 並不是該被淘汰，而是還有許多需要完善的地方。它目前還有很多改進空間，也很多 library 嘗試去改變。

好比 antd/cssinjs，它大幅改善渲染效能的缺陷，大幅度去共用底層 cache 的共用，讓整個 css system 達到更精確的 css 使用效率。

好比 jss ，透過 AST 的分析，提供豐富的 API 延展，潛藏社群圈無限的可能。

一個套件的消亡，不等於一個時代的終結

最後，styled-components 一事並不是 cssinjs 時代的終結，而是代表一個套件的興盛消亡。任何生態系和套件一定會隨著時空背景改變，最好的方式是做好合適的抽象和版本更迭計劃，為專案業務需求寫好文件和測試，為每一次的重構做好保障。

專案能永續經營，這才是軟體開發的真諦。

Tanstack Query：它不只是打 API 的工具

竹子日誌（竹子） — Sat, 29 Mar 2025 00:40:09 GMT

當今不管是 react 還是 vue，tanstack query 可以說是劃時代的解決方案。但我發現很多人對於它存在有著很大的誤解，我就想特別來分享一下。

許多人會把它定義為打 Backend API 的工具，但如果這樣定義它就太狹隘了。從 Library API 來看，我會從各個常用方法來說明它是什麼。

QueryClient

它是有個快取實體，具備 key value storage 的能力，它可以是很便利的 memory store。

useQuery

最容易有誤解的 API 之一，它並不是「打API 的方法」，我的理解是「Resource 的非同步狀態同步機」。resource 的定義很廣，包含 Backend API 、Browser Channel 、Index DB、Service Worker State⋯等等，我都覺得它是可以被拿來作為同步對象。也可以拿來同步「跟前端框架沒有綁定的 store」，因為它採取非同步的惰性更新，優點是不會卡線程，缺點是會延遲一個 Event loop queue。而它也可以應用做到更新響應，搭配 invalidateQueries 就可做到主動響應，可以很完整的做到事件流資料同步。

useMutation

一樣是很多人誤解的 API，並不是「專門打 Backend API」，更不是「data mutation methed」，它單純是「非同步方法的狀態管理機」。所有回應 Promise 的 function 都可以透過它來管理非同步的狀態生命週期，精準有效的控制非同步副作用的狀態。應用場景除了 Backend API，包含所有跟 I/O 互動的行為都可以透過它去管理渲染上不同階段的顯示。

結論

我覺得 tanstack query 並不是 api fetcher，而是一個 state management ，可以用來取代當近大部分 store 的職責，解決 90%以上的狀態管理需求。它應用多種設計模式和技巧來達成資料流管理，不管是 react 或 vue 都可以使用，是一個容易進行跨框架的狀態管理機。

你真的知道自己在寫什麼嗎？

竹子日誌（竹子） — Mon, 24 Mar 2025 05:54:00 GMT

最近幫幾個新手看 Code，發現在 AI 的時代，不知道究竟是幫助還是害人，許多新手真的一點也不知道自己在寫什麼，就像過去大家每次都複製貼上一樣，完全不知道自己的程式是怎麼動的。

你真的驗證過 Tree Shaking 嗎？

竹子日誌（竹子） — Thu, 20 Mar 2025 14:03:50 GMT

在現在極端內捲的前端生態裡面**，每個都計較怎麼打包****，要多小，要多快****。BundleSize** 可以說是非常有價值的優化項目，但你真的有驗證過，你自己的****專案 Tree Shaking 有作用嗎？

Webpack**、Rollup** **這兩樣主流的打包工具****，針對package****.json** 各種設定進行了處理與判斷**，多如牛毛的設定、極端複雜的插件生態、各種不同的模組價格****、牽扯各種機制的打包特性。一個弄不好****，讓你辛苦規劃的bundle** size縮減計劃付之一炬**，但有可能你卻渾然不知****。**

最近發現舊專案 Tree shaking 完全沒有效，早期 ESModule 標準並不明確，其實有蠻多問題的。至於怎麼解決的，就是另一篇故事了⋯⋯

不是學就好這麼簡單

竹子日誌（竹子） — Sat, 15 Mar 2025 10:32:52 GMT

說說以前的事好了。

有些事情驀然回首，真的是百般感慨。

以前剛開始碰到是所謂的「網頁開發」相關技術知識前，天真的以為「學習技能」真的是像網路遊戲這樣點點點就學到一個技能。殊不知，我學了一堆「基礎魔法」，好像掌握了各種屬性的魔法，覺得自己無所不能。

有一次，我遇上需要寫「會員系統」這樣的需要，對當時的我，根本像是突然遇到高階魔法，但初階其實前置技能都還沒點齊。拼命花錢、花時間去補點技能，但卻不知道其實離我還很遠。最後當然是請別人幫我做，我認知到自己很不夠，更懂了「專業技能是需要時間淬煉的」。

真的只有「不懂的人」天真認為「不會學一下就會」，但很多東西真的要花很多時間教導、嘗試、淬煉。

開發後端的感受-2

竹子日誌（竹子） — Thu, 13 Mar 2025 10:38:23 GMT

玩後端一個月了，利用空餘時間嘗試去配置各種微服務架構，嘗試使用不同的開源服務，慢慢有更多體驗。

我開始懂「寫出來這件事並不困難」這件事，後端要寫出能動的 CRUD 非常容易，在框架的幫助下，差不多的複製貼上，東西就寫出來了。後端沒有像是前端的「CSS 門檻」，在既有的東西下，可以很容易的製作出來。甚至我感覺到，資料的組裝幾乎是資料庫在做的事，前端的資料組裝複雜度可以說是超高，後端幾乎資料處理都有既定的處理方式，資料流單純很多。

這些容易都建立在初期的後端架構，但進入微服務架構之後，依賴管理和資料流控管就開始指數上升，架構橫向拓展的問題複雜度高速增加。

但真正難的是各種複雜的系統架構問題，需要各式各樣的系統元件與架構設計。請求太多怎麼辦？流量太大怎麼辦？兩支 APi 如何相互溝通？狀態的生命週期要如何管理？API 給的參數是否有安全問題？多個儲存服務狀態如何同步？

種種問題逐漸浮現，有種另一個世界的感覺。腦袋的運轉方式完全與前端不是同一個概念，開始懂微服務基於後端的價值與地位，功能拆解上越來越重視「職責」的分別。

不知道再挖下去有什麼呢⋯⋯

開發後端的感受

竹子日誌（竹子） — Wed, 26 Feb 2025 04:55:09 GMT

我是一個實打實的前端工程師，過去幾年90%都在前端相關領域努力，近期玩了一下後端的開發有一些體感。

要更在意事件併發問題，因為不保證所有進入點都是單一執行處理
非同步併發整合不多，大部分都可以單線完成處理
記憶體不會輕易被清除，要習慣性把多餘的快取清除。
進入點很多，但外部依賴相對單純。一個進入點的 Context 單純，不會像前端的外部耦合嚴重。
測試超好寫，固定的介面 Mock 之後，大部分複製貼上就可以滿足60%情景。
依賴的服務很複雜，要建置一個基礎的開發環境特別費功夫。但環境隔離反而容易，對外接口單純。
更在乎抽象介面，而非實作行為。
有資料庫服務，容易進行儲存狀態確認與測試。

不知道接下來還可以體驗到什麼，過去都是粗暴的滿足需求寫後端，這次認認真真把功能細化處理。

問 AI 就好了

竹子日誌（竹子） — Thu, 20 Feb 2025 00:31:38 GMT

日前聽到有這麼一個老闆，覺得 AI 不會唬爛他，所以什麼問題都問 AI。不會罵他，不會辯解，不會說做不到，無所不能的答覆。

但是不懂的終究跟實務有落差，依照對知識的理解，回答的內容天差地遠。他拿著答案要跑去找自己底下的技術主管吵，覺得「這個一定是可以的」。

然而三兩下就被識破，「你這個不是自己實踐，你去哪抄來的答案？」。這老闆只能摸摸鼻子，發小孩子脾氣。

AI 很強大很好用，它幫助許多專業工作者提高數倍的生產力。但依舊無法取代真正的專業工作者，它取代的只是那些「半桶水」的人。

最近很愛問 AI 的問題

竹子日誌（竹子） — Wed, 12 Feb 2025 09:14:44 GMT

自從 AI 興起後，一堆面試官都會問「你會用 AI 幫你工作嗎？」，但另一面又很常上機考「禁止使用 AI」，這我真的覺得是一件很奇怪的現象。

使用 AI 幫忙工作，用到最後像是呼吸一樣，你會去引導 AI 告訴你答案。時常也可以請 AI 幫忙做一些模糊且失誤了也不會有太大的問題的工作。更甚，需要去時常檢驗 AI 是否亂回答，請它發想、實作、提醒，伴隨著驗證、修正、引導，這是一個與 AI 協同的時代。

但奇怪的是，很多面試會禁止「google」和禁止「AI」。

真實工作都不能使用這些工具嗎？

不使用這些工具的人真的是「很優秀」的人嗎？

其實我是抱持蠻多疑惑。

當然你可以說很多理由

有些公司環境不能連外網、這是要考工程師本質實力、這只是簡單篩選出人才、面試官沒空設計題目…等等理由

那我可以更激進的說，這就是生態，大家就是這樣。

沒錯，最近半年來的面試生態就是這樣。

你真的熟悉CSS 嗎？

竹子日誌（竹子） — Wed, 12 Feb 2025 05:10:38 GMT

曾經聽過，「CSS 是前端工程師的基本」，但真的是這樣嗎？

應該沒什麼人敢說「我精通 CSS」，這是一門博大精深的語法。

然而現實是，一個 CSS 很強的工程師並不是一個多有商業價值的技能。甚至在面試時，幾乎沒有面試官能問出很有鑑別度的 CSS 面試題。

大多時候，如果單獨是一個語法問題，那麼「查一下」就可以解決。但如果牽扯複雜的佈局條件，他組合可以說千變萬化，在特殊組合下會有意想不到的效果。所以多數情況的問題在於「知道不知道」，而不是單純的「熟練度」。

你有遇過可以堪稱具鑒別度的CSS題目嗎？

希望你能與我分享

滾動吧難題
過度 0 到 auto
三角形
Stretched link
16:9 的 video or iframe
標準 Layout

每個階段的求職

竹子日誌（竹子） — Wed, 12 Feb 2025 00:36:34 GMT

剛踏入軟體這個領域時，其實當時沒什麼選擇權，基本上就是工作挑你。除了技能無法說起來就起來，也沒有任何工作經歷，真的只能跪求一份工作。這時的「作品」是唯一的聲量，你非常有用的求職利器，願意收留這種程度的人大概率要靠自己的作品說服別人。

入行一陣子，都已累積了實際工作經歷，但並沒有感覺到選擇的增加，仍然覺得實力不夠。這個時候其實是紅利最大的時期，你可以投資各種技術、軟實力、作品集，做什麼都容易被看見，其實這時的薪資水位大部分都在射程範圍，多方嘗試都是最好。

有些人開始往其他職能走，有些人深耕自己專項，這個時候有很高的潛力和發展。

此時面試開始大量出現「八股題」，面試的準備變得明確，累積好這些就有不差的表現。

累積大概2～4年，而且過去幾年積極累積軟硬實力，也認認真真在公司做出琳琅滿目的成績，那這個時候市場不會虧待你，此時可以朝向大家羨慕的「年薪百萬」前進。

這大概是最快樂的階段，好像每個機會都可以嘗試看看，也很多主動的面試邀請。面試的類型多樣化了起來，作業、刷題、八股題，準備起來也開始覺得麻煩。

最後你薪水到達還不錯的水位了，大概是現在我的情況，此時開始想要認認真真挑選職涯最後一哩路，想要開始深耕或是再次跳槽往天花板邁進，然而情況慢慢不一樣了。

隨著你應徵職務的薪資和難度指數提高，面試官的期許開始變得刁鑽，期待你掌握他們所以擁有的項目。但技術已經不是這個階段的關鍵，因為都要上升到那麼高的預算了，每個面試官都希望可以找到最頂尖的人才。

其實也不用想那麼多，很多時候只是「喜好問題」，知道自己的強項和弱項，慢慢補足或拓展就好，本來就沒有什麼都會的人。

Tanstack Query：近年最超乎預期的套件

竹子日誌（竹子） — Thu, 06 Feb 2025 00:46:15 GMT

Tanstack Query 大概是我近年用過最超乎預期的套件了。（這篇是當時隨手記下的一句話，完整的心得寫在工程實務分類那篇。）

都是因為你不夠努力

竹子日誌（竹子） — Wed, 05 Feb 2025 08:21:36 GMT

很多時候，我們都會想多練一下技術。像是我們前端領域，日新月異，你必須不斷努力下去。所以常常有人說，技術這條路，活到老，學到老。

我靠著非常龐大的學習時間，我一路從非資訊產業的人累積技術和經驗。也一路到現在爬到人人羨慕的 PR90，都是靠努力。

如果你的薪資還沒上來，那就是你不夠努力。

你以為我只是要講這些廢話？

不⋯⋯直到近年我才懂⋯⋯

「努力並不是公平的」

（留言續⋯⋯）

時間上天平等給了24小時，

努力是大家平等的權利⋯⋯嗎？

事實並不是，階級不公平、財富不公平，連努力都不是公平的。

有時遭遇挫折，情緒來了，沒有足夠的心力和專注力努力。因為每個人從小被訓練到專注力是不同的，不全然是天生的。你無法專注於努力。

有時家庭環境許多無奈，有父母問題、兄弟姐妹問題、老婆丈夫問題、小孩問題，很多時候扒走你的「努力時間」。

有時候身體健康不是公平的，貧窮的飲食讓身體更差，貧窮的家庭讓生活品質更差，到致身心問題，你的身體不允許你努力。

別去跟別人比較了

也不要去教訓別人不努力

重要的是，不要後悔

自己要做的就是調整好自己的心態，先認知到不存在公平，不要跟別人比較，只要跟自己比較，每一天確保進步一點點就夠了。

是時候，你的機會會敲門

關於前端架構

竹子日誌（竹子） — Sat, 25 Jan 2025 01:55:38 GMT

多數談到架構多半只會想到後端的系統架構，但前端也是有所謂的架構，但要注意什麼東西？多半大家認知的前端架構不過是使用 Builder Tool 建構一個專案，一些資料夾結構和粗略的資料流。

但實際上前端的課題和後端、服務系統等等完全不同，自然要關注的焦點也截然不同。前端的介面是一個 context 很複雜的地方，會有各種狀態和事件的交雜，如何去管理這些就是前端架構要煩惱的。

前端架構要關注的重點：

易被進行測試，有明確的測試節點，也具備可被測試的互動性
不同狀態的資料，都可以在 UI 上被良好被顯示
多國語系在不同的語言上，顯示不會導致含義曲解與破版
相同業務邏輯下，利用參數與狀態來達到不同的樣式版面
使用者做了任何動作或發生任何事件都不阻礙畫面操作，正確引導使用者下一步行為
跨 feature 的溝通能很好解決耦合問題，模組之間的 API 能清楚表達
每一個功能命名的規範可以區分不同功能的性質，能在不了解細節前初判用途

以上也只是隨口提及，其實還有很多。議題上雖然都覆蓋在軟體工程領域，但不同於以往後端所在意的東西，前端關注點截然不同。

產值衡量

竹子日誌（竹子） — Tue, 14 Jan 2025 00:52:42 GMT

很多人都喜歡用「產值」來計算這個人的價值，然而，何謂產值？

工程師完成一個功能，產值多少？

客服解決一個客訴，產值多少？

設計師規劃一個功能，產值多少？

架構師規劃一個專案，產值多少？

排除市場上浮動不確定的報價，其實這些根本無法被衡量。最容易衡量的只有業務賣出的產品，但營業額最高的業務就是最有價值的嗎？

那帶著團隊沒有賣產品的業務主管呢？

做好客戶服務的業務呢？

整理好客戶文件的業務呢？

收集最多潛在名單的業務呢？

這些看似「沒有產值」的工作卻是幫助團隊很重要的齒輪，一昧追求產值只是一種膚淺的行為。

每個職位有每個職位可以追求的指標，而非靠產值來談價，因為一個產值背後的龐大成本和複雜度並非是一個人的成果，那是背後付出努力的每個人貢獻所帶來的結果。

團隊不是你想怎樣就怎樣

竹子日誌（竹子） — Tue, 14 Jan 2025 00:22:06 GMT

在軟體的世界常常講到技術為王，但真的很強大家就會聽你的？坦白說未必。團隊是講究和諧、合作、統一，即使是你認為的最佳實踐，也未必可以實施於團隊。

曾經有人問我：「這個專案是你主導的，為什麼不OOO這麼做？」

坦白說，在團隊中，所有的決策並不是你說了算，多數還是需要有上層、夥伴等等因素去做技術決策，可能是權力大的說了算，可能是多數決，但主導不代表擁有絕對的實權，溝通協調取得共識的解決方案才是團隊。

對於某些技術高強的英雄類型工程師他們不理解這件事，他們認為你技術厲害當然決策出來的結果應該是最佳實踐。然而團隊有時候決策是取決於「最低水平者」或是「平均值」，還真不是想怎麼做就怎麼做。

WebConf

竹子日誌（竹子） — Mon, 30 Dec 2024 00:46:11 GMT

常常大家都會說 conf 都是一場大型拜拜活動，甚至有的人認為付這些錢都不知道在幹嘛。實際上去到活動，也不少人是公司贊助，甚至請公假去閑晃。但也有人認真把握時間去享受活動，為自己帶來豐富的體驗。

我認為這種大型活動有幾個目的和體驗。

關心最近開源技術圈的技術發展
可以找到很多求職資源
可以與熟悉的社群朋友聯絡與交換資訊
能多認識一些原本不認識的人
和不同人互動，得到不同的看事角度
有機會近距離與偶像互動（？

我覺得這個錢很多時候能打開視野，而且願意付出自己的假日去參加活動的人，其實對工作的熱情可想一般，這些人也是熱衷於讓自己更好的人。

2024 WebConf

竹子日誌（竹子） — Sun, 29 Dec 2024 07:49:19 GMT

===========

為什麼要這麼在乎細節？

峰值體驗

用戶只會記得最後的體驗和結束的體驗

===========

中度使用，商業影響大

先找中等程度影響的，對使用者影響不大卻有體感

===========

Design Token 是設計掌握開發節奏的工具

但其實很需要工程師支持與推動

最花時間的是命名定義

===========

Q: 我覺得吼，應該是… A: 請問這是決議，還是個人建議？

Q:這個很急，要趕快好

通常沒有一件案子是準時的
越級越慢
承辦會換，換了就不趕了
時間不會是一個 issue,因為現在不做的，之後就會變成負債（設計負債）
教育訓練通常沒有用，來上課的人通常沒有決策權

Q:你變了，你以前很好的 A:所以我公司撐不下去了啊

Q:你有沒有學過商業對話？ A:你看過川普跟人家講話客氣嗎

不要浪費時間，要好好討論

Q:你憑什麼那麼貴？ A:品牌、得獎光環

===========

設計能力來自基礎

基礎來自一些長年不變的設計知識

===========

不要直接貼文章或是 GPT 的資訊

那只會吵架

要拿出對方的信仰來溝通

通常工程師的信仰都是官方文件和規範

===========

如何估時程？

竹子日誌（竹子） — Mon, 23 Dec 2024 00:50:51 GMT

估時程這件事對於老闆、主管、專案管理者都是非常重要的事，但這件事其實並不容易，很多人也苦於這樣技能。

對於一個做過的東西要估其實相對容易，其實只需要「刻意練習」就好，每一次執行工作前給自己一個一個壓力時限，每一次去驗證自己執行過程實際花掉的時間，慢慢就可以抓住手感。這也是培養估時程這個能力的基礎，從基礎累積必要的能力。

然而工作經常要面對不熟悉的東西，甚至經常你連目標圓的還是扁的都沒有概念，怎麼估？

通常你需要一個「前哨戰」，先估一個「需要多久能估出總時程」的時間。甚至如果你是實作的技術人員，可以執行一個POC(概念驗證) 的行為，先估出這個概念驗證需要的時間，不需要細節調整，只需要確保「與想像的相符」、「複雜度確認」、「成果預判」等等必要評估。那麼對於不確定東西的掌握感會更精準，自然可以抓出時間，如果是成本過高的東西要及早止損。

讓一切有一個時間可以預期，對管理者來說，有一個預期會讓事情更好做。

好的經歷

竹子日誌（竹子） — Thu, 19 Dec 2024 00:46:47 GMT

最近面試下來體驗到一些東西，以中小型企業為主。以一個資深前端工程師來說需要的技能與經歷分享這樣的感受，希望對於抉擇工作有幫助。

常常在找工作時都期待每一份都可以成為下一份工作的跳板，但到底什麼是好的跳板呢？

有名氣的公司，最少是喊出來「客戶群」都認得出的公司。不管是本土有名或是世界有名都是，都可以為你的履歷加分。
開發流程完善的公司，完整的敏捷開發流程，齊全的 CI/CD 機制。這些實質的經驗與分工會讓你看到不同的視角，你也很有機會參與這些機制優化的工作，接觸更深都是難得經驗。而且在制度完備的情況下，也會很重視人與人之間的溝通，因為可以深度挖掘問題，才能進一步完善制度。
工具完備的公司，不管是 SSR、GA、Sentry、Storybook、Test ⋯⋯ 都是前端軟體開發的重要工具，這些東西的導入成本都不低，維護成本更是高昂，願意導入這些工具並長期穩定維護運行，都代表著公司有相對合理的開發資源。

或許大家工作都想選薪水高的，但這些經驗都有幫助你更穩定往上爬薪資。不想要成為十年用一樣技術的工程師吧？那每一個環節都可以是你需要的。

題外話，如果你只是想年薪破百，英文可能不是必要。如果你想年薪破兩百，那英文可能是必要。

給前端了解的 Design System

竹子日誌（竹子） — Thu, 12 Dec 2024 01:14:40 GMT

我們在網頁開發時，都會從 UI 設計師手上拿到 Design System ，對於許多前端來說很重要，它會是一個歸納的重點，也是加速工作的標準。可惜，這種工作方式只「有可能」在「產品開發」這個性質，如果是接案公司幾乎無法初期定義。

工程師在工作會基於經驗把固定的行為「抽象化」，然後共用一些行為和樣式。事先做好這件事，開發真的會加速很多，你可以很有效率的完成工作。但我們歸納樣式的基準是什麼？其實也是仰賴設計稿去統合的結果。

但設計師工作並不是這樣的，很多時候也是拿到模糊的 Spec，在「與客戶 try catch」的過程中尋找客戶想要的「感覺」。人很犯賤，看到東西才知道自己要什麼，意見都是等你做完才有。如此一來，那個設計系統根本無法被定義，就算做出來也是修修改改。

會想要寫這個其實就是看到有人在河道討論設計師交付的東西，但我覺得不同職位本來就有不同職位的難點，不要自認自己很懂邀請對方，因為他面臨的困難不是你可以腦補的。每個工作環境、產業、上司⋯⋯等等條件都會造成不同的結果。可能你前份工作可以怎麼配合不代表現在這份工作也可以這樣，多去理解你的夥伴面臨的難點，好好的坐下來談談吧。

說說 Vue 的問題

竹子日誌（竹子） — Fri, 06 Dec 2024 00:40:47 GMT

網路上清一色是捧 react 踩 vue，一派說法是 vue 比 react 用的人少，一派說法是 vue 是中國人寫的，還有一派說法是 vue 黑魔法多。多半我會護航 vue，因為許多人噴的都不在點上，我覺得只是框架優越感而已。但今天我要平反一下，vue 相較 react 有什麼使用上的不好用？

模板語意和腳本語意不一致。常常在寫 setup 和 render 時會錯亂，常常遲疑在要不要寫 “.value” 這問題。
設計 HOC、extends 非常不方便，它並無一套簡單卻能完美繼承，需要手動為 slots 加工。不像 react 直接解構賦予給 children node 上層的 props 就可以解決。
當你想封裝一個功能或元件，需要為 vue 多種功能與多個生命週期進行邏輯處理。
因為功能太多，寫法過於自由，生態圈要跟上相關功能的延展經常需要比較長的時間。
對於 jsx 的語法支援和提示未能完全跟上 template 的便利性。對於喜歡 jsx 的人，常常無法體驗到更好的提示和效能優化。
對於元件型別的定義過於複雜，學習成本過高。3.3 之後的泛型寫法對於 setup script 以外的原生寫法不支援，需要比較大的心力去定義。

我完全用「使用者」立場去看這件事，我也是 vue 的支持者，但事實的問題是我會因為我支持而不在，這不是「主觀問題」，是確實存在的問題。

你有什麼看法呢？

開發要不要寫文件？

竹子日誌（竹子） — Wed, 04 Dec 2024 00:46:41 GMT

很多人都常常掛在嘴邊，公司沒有文件、開發要寫文件、寫文件很浪費時間⋯⋯

我的觀點不一定套用在你身上合理，也不是非黑即白的對錯問題，只是我想分享我的想法。

我認為接案性質或是產品用過即丟的不需要寫文件。但凡需要長期維護、使用、敏捷追加功能等等，都非常需要文件。

很多工程師會有迷思，何謂開發文件？

難道要寫「這段程式幹嘛」這樣的描述？

我認為不需要，真正需要寫的是「這裡要達到的目的」，怎麼做？不重要。因為程式碼是會重構和迭代，你現在覺得最好的方法不見得永遠是最好的，那這樣的文件價值很低。真正要寫的的「目的」和「規格」，特別是「你解決的邊際問題」。

所以我認為最重要的是 Spec。

但 PM 表示，文件大家都不看，寫心酸的？

文件不是給當下開發的人看的，當下大家都用「溝通」的，因為比較方便和快速。但文件是給「後手」和「未來的自己」看的，人類的記憶力真的沒有很好，隔一段時間就會遺忘，人員也是會流動的，這時候文件就可以發揮作用。

但何謂 Spec?

不管是客戶需求的紀錄、功能的需求規格、UI 的設計稿、套件的 API 、服務的 API等等，但凡你的產出需要跨部門、跨職能、跨團隊溝通請另一方實作產品某個環節，那就需要的文件。

你怎麼看呢？

重構的故事（一）

竹子日誌（竹子） — Fri, 29 Nov 2024 00:34:03 GMT

前面說到要講講重構的故事，先講票選最高那一篇。基本上就是一個從 Vue2 轉換成 React 的專案，雖然沒有全程參與，但前期的配置算是頗有趣。

這是我來到這間公司第一個主要任務，它是公司的主力舊專案，所以商業定位有一定的重要度。但因為使用的技術線是 Vue2，而其他專案全部都是走 React，所以CTO 希望能將公司技術線一統使用 React。大致上他提到希望可以架構一個微前端架構，透過微前端去 migrate 到另一個框架。

看起來這個重構不難，只不過跟大部分的重構一樣，分析商業邏輯，逐步逐頁去重新打造。首先要先解決「微前端」的問題，接下來就是拆解商業邏輯，最後就可以執行核心任務。

當然，想的簡單。

超乎我預料到事情即將到來⋯⋯

重構一個前端專案

竹子日誌（竹子） — Wed, 27 Nov 2024 05:22:31 GMT

前一篇談到重構和重用迴響蠻大的

這次來談談我過去經歷到現在的三次比較大的重構。

A. 是相對簡單但功能多的系統，技術使用 Vue2，高達 80多組 Resources 要管理和整合。但細節體驗差，資訊架構不明確，要從 PM 角色、UI 角色開始重新規劃來重構。

B. 這是一個 Vue2 專案，因為公司技術線想要統一，規劃採用微前端逐步重構成 react。專案品質相當高，程式碼重用率高達70%，但耦合性非常誇張，極難拆解。

C. 這是一個中國冷僻打包成 app 的技術，要重構成 Nuxt3，功能雖然不多，但一套後端要對接 25 個業務邏輯相似且畫面截然不同的網站。多達 31 組的多國語系，沒有整合 i18n。程式品質非常差，無論是命名、拆分、邏輯排列都遠低於平均水平。

大家對哪幾個比較有興趣呢？

程式碼越少越好？！

竹子日誌（竹子） — Wed, 27 Nov 2024 00:30:13 GMT

幾乎每一份工作主管都會交派我進行重構，所以對於重構需要的技能，我可以說是意外點齊，重構這件事比起開發，我可能再熟悉不過。

重構首先關注點是閱讀和理解程式碼的能力，關於這部分改天再談。

另外一個就是拆解程式碼，將功能盡可能抽象後單獨模組化。通常公司願意重構的專案都是「有在盈利」、「足夠複雜」的專案，但這種專案品質一定好嗎？可能千百種情況都說不準。

但重構過各種類型網站後最強烈的感受其實一反許多人的想法。可能大家都會說「聚合性要高，程式碼能越少越好維護。」但我接手多個需要重構專案的經驗卻告訴我，程式碼複用率越高，相比幾乎不複用的爛專案來得更難維護。

通常維護專案什麼最難？我認為是「理解程式碼的意圖」最困難，你要充分理解上下文表層目的與深層目的，它需要非常驚人的時間去理解與分析，特別是要重構的專案「通常沒有文件」這件事很習以為常。

我曾經遇過一個寫的還算不錯的專案，它用極端少量的程式碼，透過超高比率的重用完成龐大的業務邏輯。但接手的人的感受其實是⋯⋯整個專案黏踢踢的，根本無法執行部分重構，單一模組的依賴非常不明確，都吃到大範圍約定式依賴註冊，你很難去解耦後單獨重構和現有系統一起工作。它的封裝也是考慮到效能、重用性，但其實非常難以快速閱讀理解。

我體驗過這件事後，我再也不迷信所謂的「程式碼越少越好維護」，那其實帶來的是另一塊維護黑洞。我體驗過讓我好閱讀的都是「簡單」、「直白」、「獨立」的系統。雖然需求終究會遇上很噁心的功能，會遇到不得不全域溝通的上下文，但宣告明確清晰很重要，可能會大幅拉長「開發時程」，但確實回頭追蹤時簡直明確容易多了。

關於 SASS/SCSS

竹子日誌（竹子） — Sun, 24 Nov 2024 03:36:09 GMT

過去大概4, 5年前，當時是 bootstrap 的天下，當時最流行處理 CSS 的手段是 SASS。要嘛是 global 注入後手動管理，要嘛是採用 CSS Module，各大框架甚至有自己的一套。

近年來趨勢逐漸都開始向 Atomic 的設計靠攏，開始淘汰 Global CSS 的寫法，因為這種做法的反查難度實在太高了。

近期看到的新人對於 SASS 熟悉度越來越低，也坦白說會用到的功能越來越少。包含，迴圈、判斷、函式，而常用的變數和巢狀也隨著原生的支援使用率越來越低。

你現在都是用什麼 CSS 解決方案呢？

CSS 的解決方案

竹子日誌（竹子） — Fri, 22 Nov 2024 01:30:49 GMT

Vue

HOC
Sass @Mixin
Global sass
Component Wrap

最誇張的多語系

竹子日誌（竹子） — Sun, 17 Nov 2024 03:56:54 GMT

這大概是我最真震撼的專案，當初看這個專案功能不多，都是些簡單的互動和資訊顯示。直到⋯⋯我看到它 i18n 的功能，真心嚇到⋯⋯

宏偉的 28種語系！！！

（結果需求是再加 3個語系）

超級超級害怕多一個詞彙，每當你多一個詞彙，你要去修改的 json 有多少。

我是決定重構這個 i18n 系統了，但這應該是一個艱難的任務⋯⋯

討論議題不想要得到廢話

竹子日誌（竹子） — Sat, 16 Nov 2024 10:36:36 GMT

有時候常常在網路上要求一個政治正確，其實蠻累的。

這將不是一個教學為主的帳號，也不一定都有硬核的知識點，我只想當作隨筆寫著每一日的點滴。

其實過往我發過不少工程師議題，比如框架選用、依賴循環、設計模式、前後端分類… 等等，但總是有人會在留言區說「哪個都好，重點是解決問題」。這聽起來就像是你問「我的職涯該怎麼選擇？」，我回答你「怎麼選都好，能賺錢就好」。這無疑聽起來就是幹話，因為能解決問題和賺錢確實受選擇工程師這條路的必然理由，但議題之所以是議題就是有一個兩派人馬爭論不下才可以是議題，提出立場和想法才會讓議題有趣。

發文一段時間，其實也有點疲累。很多東西是來自於生活與工作的靈感所撰寫，但有時也會疲累，慢慢的覺得寫作也很累。選擇發文這種方式，無非也就是想取得一些回饋感，但回饋感總是不好也會疲累。

會發文都是遇上了許多讓自己震撼感受的瑣碎事，如果你覺得我講的是理所當然的廢話，只能說還不能體會而已。每個人生涯有許多歷練，那都是剛好他人生的體悟，我只是當作網誌去記錄每一段心情。

碎碎念

竹子日誌（竹子） — Fri, 15 Nov 2024 00:32:13 GMT

一段時間沒有更新⋯⋯

近日工作上發生很多心累疲乏的事，真的可以說，很多東西是會消磨心性的。很多時候，工作不只是賺錢，可以帶給人自信、成就感、生活動力。但遇到一些鳥事卻無能為力時，真的會強烈感受到崩潰感。

近期算是調適好內心狀態，覺得應該繼續更新哩～

造一個輪子

竹子日誌（竹子） — Thu, 31 Oct 2024 13:23:30 GMT

想要造一款輪子之前

首先你要了解別人的輪子解決了什麼問題？

了解別人的輪子使用上極限在哪？

最後發現有致命缺陷的問題，你決定選擇刻一個輪子。

這個思考脈絡和功課要做足。

如果沒辦法參透別人輪子的精髓，那代表你造輪子的功力還不成氣候，那你造出來的是個方輪，使用它只會帶來災難。

當你覺得「做不到」時，先思考一下是你不夠了解別人的工具？還是真的需求非主流？或是你正在開創一個別人沒想過的解決問題思路？

有感而發⋯⋯

前端系統要設計什麼？

竹子日誌（竹子） — Thu, 24 Oct 2024 00:41:14 GMT

最近因為周杰倫的演唱會，軟體工程師圈又掀起一波討論大流量系統設計的討論熱度，這大概也是工程師們樸實無華的樂趣與成就感吧！但話又說回來，前端沒有什麼所謂的微服務設計，那對於一個企業來說，資深前端架構師到底要設計什麼系統？

首先，我們要先定義前端有什麼獨於後端的問題，然後再來討論解決方案才有意義。

那前端會遇到什麼問題呢？

前端要關心每一包套件的 package size 和整個應用程式同步與非同步的 bundle size，以確保不要有太多流量造成企業和使用者流量的負擔。
前端業務端應用程式不容易被拆分，不像後端可以靠微服務去區分功能，前端很難去將功能給拆解縮小，造成管理上很大的困擾。
前端 UI 不是單純基於輸入輸出，所以會夾雜極大量的 Context 和體感問題，也是需求改動最為頻繁的地方。這也導致測試難度極高，但換來的效益卻不明顯。
是第一步接觸使用者的地方，任何操作細節的實作對於使用者都尤為明顯。特別是牽扯畫面渲染與動畫時，每一點點的時間差都會造成使用者困擾。
瀏覽器操作是前端獨有的手段，對於瀏覽器的安全、效能、版本管理相關調效與控制是前端在規劃時必要的考量。

字數有點太多了，後面再來聊聊解決方案。

你認為前端要關心的細節中有什麼我沒有提到的嗎？

年資迷信

竹子日誌（竹子） — Wed, 23 Oct 2024 01:05:57 GMT

年資和能力是「相對關係」，隨著不是「絕對關係」，對於不同的個體，年資完全無法比較。

現在在外面試還是不少面試官會拿「年資」

Code Review

竹子日誌（竹子） — Fri, 18 Oct 2024 10:53:22 GMT

Code review 是一件很重要的流程，但很多人會對於這個流程有很多意見。它既是管理程式品質的重要流程，也是讓團隊相互熟悉風格的方法。同時被詬病的消耗很多時間，也會造成很多團隊紛爭與爭吵。

Code review 的目的是什麼？

我並不認為它能管理品質，也不是審核誰寫的好或不好，更不是拿來對風格指指點點。

Code review 我認為是這樣的：

檢查有沒有粗心的問題。比方說錯字、沒有清乾淨的 log 等等。（如果有資源在 CI 檢查更好）
互相了解彼此的撰寫邏輯，並詢問與說明設計理念。
多一層防呆機制，避免不小心直接點擊到合併。
確認是否有改動到不屬於的 feature 範圍，或是主管確認是否改動到專案主體架構功能。

但是我覺得並不是這樣：

檢查撰寫程式的風格閱讀性（這種東西要嘛用 ESLint，要嘛團隊要自己定義規範）
確認與討論解決方案（這種事要嘛在開發前就要討論，不然就等後續優化重構再說）

如果是有足夠資源的團隊，那或許可以 Code review 去管理品質。但多數團隊太過於小，需要逐步優化，花大量時間在 Code review 上無疑是浪費有限資源。

但如果因為認為 Code review 是大團隊才需要做的，我認為大錯特錯。只要是 2 人以上需要協作，那就需要 Code review 去維繫協作。

關於事件匯流排

竹子日誌（竹子） — Wed, 16 Oct 2024 00:48:57 GMT

JavaScript 是一個 Event Drive 的程式語言，大量底層實作都會利用 Pub, Sub pattern 去設計一些邏輯實作。對於單掛載事件則是使用 callback 來達到相似的結果。經典的案例是 EventTarget，大量的網頁實作都用到，後來為了可以兼容 Pure JavaScript ，實作了 EventEmitter 。

事件這個設計對於解耦有著無比強大的特性，大部分你所看到的各種 Callback 都可以仰賴 Event 重新封裝達到相似的結果。事件也不會慢一個 Event loop queue ，可以自由封裝並達到一致或不同的結果。雙重事件相疊也可以做到相似於同步的 Promise 效果，可以說是非常好用。

然而，我發現多數前端非常不喜歡應用 Event 這個設計，甚至不少資深前端還「反感」這個設計。認為「多餘」、「複雜」、「難維護」。但我覺得這是封裝特性問題，並不是不好。

你呢？怎麼看 Event Bus?

React Router

竹子日誌（竹子） — Sat, 28 Sep 2024 05:09:07 GMT

看似自由的 react 技術圈，目前使用 router 功能的市場仍然被 remix 的 react-router 佔領，目前除了 Next 自有的 router system 外，還沒看到其他間居上的 router library 。

用過 vue router 後，我目前再無其他滿意的路由系統，其他的我只能說⋯⋯難用⋯⋯

近期在觀察 tanstack/router……

你問我 react-router-dom 哪裡不好？

（以下以 v6 config api 為主）

Router 實體，官方直接「不建議」操作（很多功能和資訊直接跟你講不要用）
不提供路由完成的 Promise 提供非同步完成確認
不提供 before router change 的攔截
不提供針對 route id 來導向
不提供對 routes 修改的方法（可以做到，也不止一種做法，但文件並沒有交代做法)
沒有提供一個可以在 React Component 之外拿到 location 或 navigate 的方法。
原始碼的品質很差⋯⋯⋯⋯

當然你可以說 Route Component 很自由啊！

但沒有規範使用這樣的 API ，真的超容易迷路啦⋯⋯

但對於輕型專案來說，其實還是頗好用，設計邏輯還是蠻符合 functional programming 的概念，也或許某方面是想強制使用者用特定的方法使用，而不是「不好用」。

AI 能解決的問題深度

竹子日誌（竹子） — Wed, 25 Sep 2024 00:42:20 GMT

在 AI 的浪潮下，許多人害怕被 AI 取代，但 AI 究竟取代了什麼？就今天我從軟體工程師的角度來談談這件事吧！

現在只要依靠 AI 就可以讓什麼都不懂的人快速做出成果，近期經常聽到「X歲搭配 AI 寫出來」，也常常有「用 AI 寫程式 XX 分鐘做出 XX程式」。哇！真是強烈感受威脅啊！

然而我實際上工作確實也是，我只要給予一點點引導，AI 就可以幫我寫出我要想很久的程式碼，經過我的檢查之後沒問題就會採用。坦白說，AI加快我「寫程式的速度起碼2倍」。

但是，被取代的危機感來自於「日常工作的被取代性」。雖然「寫程式」變快了，但其他工作卻沒有減少。包含著架構設計、抓程式Bug、找到問題本質、業務邏輯理解與溝通、處理人與人之間的協作問題⋯⋯這些真正繁瑣的事情根本無法靠 AI 工作，需要人類的判斷力去操作和達成。

或許，AI 取代人類10年後不好說，搞不好又有另一番變化。但我敢說，5年內這種事情只是危言聳聽，因為發展還沒有進步到那個程度。保持學習心態持續精進，這才是生存下去的不二法門。

技術強弱

竹子日誌（竹子） — Fri, 20 Sep 2024 00:57:06 GMT

很多工程師很喜歡比較誰比較強，誰比較弱。但其實走到 mid level 以上時，我覺得很難去比較出誰強誰弱。甚至有時候是專案際遇不同而有不同的感受，會有出現不一樣的想法與觀點。

小專案和大專案的規模差別。

快速開發和高度客製化的需求差別。

有個性和重規範的團隊文化差別。

等等因素會產生出來的人就會重視不同的東西，自然而然會誕生出不同的想法。

對於一個技術解決方案的觀念可能就會發生改變，可能就有千變萬化的想法，自然也會產生出截然不同的風格。所以其實沒有最好的做法，只有在不同場景環境可以找到儘量合適的做法。

有時不需要去質疑另一個人「這種想法有問題」，應該去了解誕生這種想法的「時空背景」，或許也可以開開眼界。

你想解決什麼問題？

竹子日誌（竹子） — Wed, 18 Sep 2024 00:39:32 GMT

我其實是懂「不要執著技術，要專注解決問題」這件事，但技術其實也很常是為了解決某個問題而誕生。有鑒於前篇談「全端工程師」這件事，不少人一直想告訴我「Title 不重要，重要的是解決問題」，我只能說很多人完全搞錯重點。

這邊談的是對某個 title 的職位他的專業尊重，不要去 PUA 一個人說「你應該會”OOOO”才是正確的」，這樣套路味的說服。很有可能他是會某些東西，只是他「不願意」交出這些會的東西。可能是什麼原因？尊重、機會、報酬等等，每個人的理由可能都不同。

解決問題大家只在意「公司想解決的問題」，但這個角度我覺得太基本了，我覺得可以用更宏觀的角度。你想解決的問題除了主管或老闆的問題外，也有可能是眼前工作的問題。這些我相信告訴我「Title 不重要」的人都知道。

我想說的是，如果是想解決生涯規劃的問題呢？

怎麼樣才能更快速的高薪？怎麼樣才能更快擠身稀缺人才？怎麼樣更快累積被更容易看到履歷上？

一般來說，沒有背景、沒有超級專業、沒有權杖這種普通的求職者，最快的方法就是「工作上專注在自己Title 的職能」，包山包海到處學只會更加緩慢，專精是變現最快的方法。

求職者向來與資方是對立的，相互尊重取得共好，雙方取得最大利益，不要總是用著資本主義的黑暗兵法。

面試作業

竹子日誌（竹子） — Mon, 16 Sep 2024 10:45:14 GMT

日前在面試時面到一間公司，一間有臉有頭到金融大公司。我送履歷後，分別兩次寫了面試前考題，一次就簡單的問答題，另一次是要刻一個簡易 Date Picker。雖然一個面試前題目花掉的時間不多，但兩個對我來說確實讓我花掉不少時間。

直到前幾天，因為我已經找到新工作，其實有沒有上我已經無所謂，但我還是想知道結果。於是乎我追問了獵頭，結果如何？

獵頭說：「對方回應，審核 CV 未通過，原因是您年資不足。」

蛤？原來我「5年」的前端有年資不足的問題？

等等⋯⋯啊？如果年資不足，剛開始審核履歷時就不通過就好啊！為什麼我寫了2次面試題目才跟我說「年資不足」？我花那麼多時間寫題目當作我是塑膠的？沒有在尊重求職者膩？

真心覺得對這家金融公司滿滿的不爽⋯⋯

全端工程師

竹子日誌（竹子） — Sun, 15 Sep 2024 09:58:59 GMT

我向來都會說自己是「前端工程師」，全端工程師對我來說是「貶義詞」。

但我會不會後端？

我能夠開 API
我會下 SQL Query
我會資料庫設計
我懂分層架構
我會物件導向設計
我會利用 ORM 工具
我會 Migration 管理資料庫
我會容器化部署
我知道如何設計可觀測系統
我知道怎麼用 Socket 去串接 http 之外的協定
我會設計微服務，如何才能橫向系統拓展
我知道 MQ 在微服務可以解決哪些議題
我知道憑證加密傳輸如何運作
我會權限設計，基本的如 RBAC

⋯⋯等等（再寫下去好像有點硬要寫

硬幹我還是都幹的出來，但我從來不敢說我懂，真的都是淺淺的略懂。我自豪花了很多時間學習前端，我也都把時間投資在 JavaScript 這門語言，我一直都是走專精路線。

其實有時候挺受不了有人這樣對我說：「你前端學那麼久了，該學後端變成全端工程師了！」這句話充滿著說教感，我不知道他這個是基於什麼底層邏輯，我只能說術業有專攻⋯⋯我可從來沒聽說過有人會教育：「你後端學那麼久了，該學前端了」，但不少人卻喜歡反過來教育前端。

這不就是雙標嗎？

你的世界不等於我的世界

竹子日誌（竹子） — Sun, 15 Sep 2024 04:04:17 GMT

日前我還在找工作時跟一個老工程師的公司主管面試，真的是越聊越生氣。只能說每個人認知的世界不太一樣，不需要把自己世界的認知強加到別人身上。

原本問到我的生涯目標，我表示我是以「管理職的規劃在找工作」。被質疑我都是做前端，想上管理職必須要「做後端」才行。其實也沒實際深聊過任何後端技術，只是看看經歷就拋一句「前端還是要熟悉後端才能當主管」。喔！你當我下班後都是在發酵嗎？

但我覺得管理職未必要懂全部的技術，

你要一個後端背景的主管下去畫Figma設計稿可以嗎？

你要一個維運背景的主管下去規劃前端系統架構可以嗎？

你要一個設計背景的主管下去伺服器裡面部署應用程式可以嗎？

我自稱前端工程師並不代表我不懂後端，只是我會很自豪的說「我都很會」，術業有專攻，擅長的領域中就有差。跟我談特定的框架、語言、資料庫是不是太狹隘了？

雖然時隔一段時間，但遇到這種自以為是的老人回想起來還頗不爽。

關於 RestfulAPI

竹子日誌（竹子） — Thu, 12 Sep 2024 00:29:55 GMT

很多人以為 restful API 只是把行為區分成 GET, POST, PUT, PATCH, DELETE 這些不同的 mothod。然而，如果真的這麼簡單，有什麼好了解的呢？其實不只是 restful API 的規範，更要知道 http 規範和瀏覽器規範。

前端的你是否曾經接過以下奇怪設計的 API？

GET, DELETE 的參數帶在 Body
URL Search Query 需要帶 Array 用「,」當作分割符號
PUT 和 PATCH 的資料格式是multipart/form-data ，而且要帶 Blob file

或許你可能不覺得奇怪，但如果設計出這種API 肯定很快就會踩到地雷了。有些是套件的實作行為，有些是瀏覽器限制⋯⋯如果對這些不了解就會有很多溝通上的問題。

你遇過什麼奇怪的問題嗎？歡迎一起分享喔！

軟體架構這件事

竹子日誌（竹子） — Tue, 10 Sep 2024 00:45:34 GMT

如何設計一個軟體架構可以說是軟體開發的超級難題，有人說架構一開始就要開好開大，有人說有需要再開大就好。我只能說，都正確，但你會怎麼做？很好笑的地方，曾經有一個老闆希望我幫他開一個超屌的架構，可以扛上超大型專案什麼。我認真反問，你真的確定嗎？

首先定義一下這邊談的「架構」，包含在系統架構、職責分層、撰寫設計等等小細節。

當架構開的越大，確實可以降低「改動成本」和「承受更大的負擔」，但相對的會造成更多「架構維持成本」。

舉例來說，「多國語系」這件事情，如果一開始並沒有這項需求就把這件做好做滿，如果有一天要做，確實可以「大幅降低」重構消耗掉的成本。但說真的，要維持「多國語系」這樣的架構，需要消費掉的成本也非常高昂。包含資料庫、翻譯表等等各種東西的維持與管理。如果實際需要，或許不是問題，如果是「事先規劃」，在維持過程中的討論、撰寫、處置⋯⋯等等維持成本都是額外負擔。

但我的經驗經常是，一開始先開一個剛剛好需求的架構，想要等需要再擴增。結果，遇上的需求時上頭不會給你時間重構，而是不斷不斷增加需求，疊床架屋。最後就是小架構卻臃腫，一隻動則千行萬行的檔案，因為改不動而出現各種獵奇的設計⋯⋯

你認為架構要事前開好？還是需要再重構呢？

關於開發流程這件事

竹子日誌（竹子） — Tue, 10 Sep 2024 00:42:08 GMT

很多公司都會說：「我們團隊那麼小，不需要什麼開發流程，產品先做出來就好。」

這句話，對，也不對。團隊小，不需要大公司複雜的開發流程，真正需要的是「精簡必要的開發流程」，而不是亂無章法。而何謂是精簡的流程是建立在豐富的開發流程基礎的成果，而不是隨口說說的結構。

開發流程不只是一種形式，而是制度的象徵，小至2人，大到數十人，只要牽扯團隊協作就有開發流程的問題。不會不需要，需要的是有一套制度防呆、保護、避免失誤，當有足夠的機制保障失誤，重構、優化、升級才可以大膽執行，軟體團隊的進步和應用程式的可維護性才可能不斷得到提升。

不是只有理想

竹子日誌（竹子） — Mon, 09 Sep 2024 23:57:28 GMT

或許你有很豐富的創意，或許你有想達成的目標，或許你有偉大的理想。

我看了許多老闆、朋友，有著豐富的理想和期待，期許能創造出不一樣的產品。但現實是非常骨感的，不是你有滿腔熱血就可以推動。常常看到各種偉人傳記都是充滿夢想，領導人不斷努力往前邁進就會有一群人跟上。

事實上其實就是一個人乾著努力，不會有人莫名其妙跟著。想法和創意是不值錢的，因為無法有任何東西去證明想法與創意的價值，剩下只是打嘴砲而已。有價值的是執行力、整合力、解決問題的能力。

何謂「熱愛挑戰」？

竹子日誌（竹子） — Sun, 08 Sep 2024 10:27:47 GMT

很多菁英人才很喜歡說「熱愛挑戰」，也很常說換工作的原因是「沒有挑戰」。

很多公司都想招募「熱愛挑戰」並具備「特破自我」個性的優秀人才，希望團隊是熱血上進的。

然而，一個「熱愛挑戰」在不同的立場中，會有不同的解釋。

一般的人才追求的挑戰是「專業上的困難挑戰」，他們想要追自己能力再更突破自我，而不是朝朝暮暮做著一樣的工作，相似的工作內容。

而公司想要的熱愛挑戰的人是「解決疑難雜症問題的人」，並不是單單指「專業上的熱愛挑戰」，而是綜合對於人的問題、時限的問題、客戶的問題方方面面帶來的麻煩進行解決。

問題就來了，很多資深員工說希望工作能得到更大的挑戰，其實希望被交付更複雜更有深度的工作。但許多老闆與主管都會誤會，單純調高工作的「時限」和「限制條件」，以為是給予挑戰，殊不知是誤會的開始。相對的，不了解這個生態的初心求職者就會誤入這樣的公司，做得心累疲累。

關於 Vue 的碎碎念

竹子日誌（竹子） — Fri, 06 Sep 2024 00:37:05 GMT

我很喜歡 Vue ，它自由、限制少、出錯率低、自動又聰明、官方提供超級豐富的 API 來掛鉤底層各種行為。

但正因為它超高容錯率，也導致它超級容易被寫出「很多問題」的程式碼。因為太容易學習，導致新手可以搞不清楚狀況就上手，也誕生許多非常可怕的程式碼。

網路上經常許多人形容 Vue 很多黑魔法，對我來說，那些工具本質就是 JavaScript ，沒有什麼魔法，魔法來自於「不了解」。很多人都稱之那些「神奇又方便的功能」叫魔法，我會說⋯⋯當你還當它是魔法的那天，你更應該知道它的意義是什麼，而非當它是解決你眼下問題的萬靈丹。

各種 API 是讓你開發上能做出彈性更大的設計，而不是「濫用」。我認為「業務元件」絕對用到越少的 API 越好，用最少的功能做出最豐富的設計。

Component 卸載，非同步要清理

竹子日誌（竹子） — Thu, 05 Sep 2024 00:38:28 GMT

不管你是寫什麼前端框架，你一定有一些行為是 Component Mounted 的時間點要執行。執行時也很常會有「非同步」行為。

常態來說，可能要打 API 行為，可能有一些 IO 建立的行為，凡是所有你需要使用 async 或是 Promise 都是。但大家很常做的事情是⋯⋯直接就接著非同步的 callback 直接執行。

但有一種狀況，就是元件被掛載馬上就要被卸載。就像是 React 的嚴格模式，或是使用者互動進去元件後馬上跳出⋯⋯諸如此類。但我發現很多人不會去「清除非同步的 callback」，那很常埋下一些潛在的風險。因為元件卸載後 callback 並不會中止執行，它們依然會把非同步執行完成，程式中就會執行「沒有需要的行為」。

趕快檢查你的元件是不是常常在元件掛載後執行非同步，確認一下卸載有沒有好好清理！

負擔

竹子日誌（竹子） — Wed, 04 Sep 2024 00:28:03 GMT

前日因為一篇學習的文章，有所感慨，家庭真是最甜蜜的負擔⋯⋯

成為一個軟體工程師，除了上班八小時，下班後還需要花很多時間去精進自己。但不是每個人都做得到，有的人有年邁的父母要照護，有的人有年幼的孩子照顧，常常時間都不是自己的。

努力是一種美德，特別是剛轉職的軟體工程師，前3年左右是非常需要淬煉的，要爬升到某個高度單單靠工作實在很有限。要嘛要有背景，要嘛天資聰穎，要嘛抽到幸運的公司能在職學到很多。不然普通人，想開開心心轉職，開開心心生活與工作平衡，有這麼好的事？

我前日跟社群上的朋友聊到這個話題，有家庭的負擔沒辦法下班額外貢獻在學習，這不是種錯誤，是種「選擇」。下班沒有學習沒有錯，但下班付出代價精進成長的人呢？升職、加薪、跳槽等等機會當然是留給願意付出更多的人。（這裡不包含慣老闆邀求加班）

總結來說，用自己的時間付出是一種選擇，把時間留給家人是一種選擇，人一天只有24小時，想要過什麼樣的人生是自己必須去投資和調配。

寫 Class 有什麼問題？

竹子日誌（竹子） — Mon, 02 Sep 2024 16:08:25 GMT

現在的前端非常不流行寫 class 這樣的語法糖，但實際上 class 就是 function 的進階應用而已。過往盛行的物件導向程式設計大家想導入到 JavaScript 使用，但各種水土不服問題不斷誕生。另一個原因就是物件導向的設計模式其實要學習更多的語法，躲避更多的坑，成了一個大問題。

以我最熟悉的兩個框架，Vue 和 React，從過去 class 滿天飛的時代到現在也算有天翻地覆的改變。後來 functional programming 的興起，漸漸的大家越來越朝向這個方向去撰寫。但 class 消失了嗎，其實不然，它只是往底層移動，比較不會出現在業務層。

如果就是想寫 class ，要注意什麼東西？

當 function 被解構，this 會消失。現在大家很習慣解構 property ，但在 class 很依賴 this 溝通，所以需要手動去處理 bind 這件事。
使用 this 修改狀態不會響應。因為它是內部執行修改，框架是不會進行響應的，要去通知外部框架狀態更新。
目前流行 functional programming ，在特定 API 的設計下，需要設計 immutable 的更新手法。

最後我想說，OOP 和 FP 絕對不是對立，它們之間的差異關鍵在理念，任何能讓程式更容易被閱讀被管理都是好方法。前端們也別看到 class 就排斥，其實融入在架構中或許也是一個好選擇。

學習方法

竹子日誌（竹子） — Sun, 01 Sep 2024 02:31:12 GMT

不少人問我

我怎麼待前端五年就卷到現在這樣

或許我的方法不一定最好

但希望分享給你，讓你有收穫！

下班持續學習：下班後人家懶人家廢，我回家逮到空檔就開始學習。我最高強度時，扣除上班一個月付出上百小時在學習。
上班做有價值的事：工作大部分都在工作，但多多少少有閒的時候，不要浪費時間，做一些提升團隊工作效率的事。寫一些工具、串一些功能、重構一些程式、補一些測試。
除了輸入也要輸出：工程師每個人都拼命學習，但看了就忘記。學習後不管是你要自己寫 SideProject、寫部落格、跟朋友分享，這都是輸出的一種方式。
先深再廣：技術推陳出新，不用一直追。解決方案先學一種，然後瘋狂學深，挖原始碼、理解原作者應用的技巧，接者嘗試模仿去體驗作者解決的問題。等到讀懂了，你會發現同類型的工具理解的很快。
不要逃避：專案中，你一定會遇到「好像不是很懂」的部分，那麼多程式碼和工具，不懂就看，不了解就挖，不要放過眼前的任何可以學習的機會。包含⋯⋯你所有用的工具背後所有的API和原始碼。

還有什麼值得分享的小 Tips 嗎？

歡迎與大家分享！

今天是我在現在公司最後一天

竹子日誌（竹子） — Thu, 29 Aug 2024 23:45:32 GMT

一年九個月，這段十日大概是我在軟體業最幸福的日子，這裡完善的環境讓我很快樂！

這段時日，我花了很多時間在設計、實作、克服各種微前端議題，學習各種軟體設計模式與版本管理技巧。這是一個相對完善有趣的體驗，也讓我學習到一個複雜的軟體開發需要體會的很多東西。

這裡有尊重專長的技術主管、有技術知識的 PM、平均能力很高的夥伴、舒適完整的開發流程。在各種快樂的因子聚集的同時，我享受到這一切帶來的美好。

希望，現在的公司與夥伴能繼續成長～

我也即將要往下一條道路前進了！

今天是我在奔騰最後一天

竹子日誌（竹子） — Thu, 29 Aug 2024 23:29:26 GMT

一年七個月，這段十日大概是我在軟體業最幸福的日子，這裡完善的環境讓我很快樂！

希望，奔騰網路能繼續成長～

我也即將要往下一條道路前進了！

關於共用這件事

竹子日誌（竹子） — Wed, 28 Aug 2024 00:40:54 GMT

大部分的工程師都知道，在撰寫程式時把邏輯拆小，並且共用，可以縮減程式碼量、提高複用率、加速開發效率⋯⋯等等優點。這也是一種提高程式內聚性非常重要的策略與手段，幾乎可以說是必要知識點。

然而，我對於這件事抱持不同想法⋯⋯

我認為共用這件事在越大的專案越需要謹慎思考⋯⋯

因為一旦共用就會產生「依賴」和「版本」的問題，而這兩個問題會產生的麻煩更是讓日後建立更多麻煩的元兇。過度的共用造成閱讀的困難，甚至重構時完全改不動。

所以適當的複製貼上我覺得是反而可以讓程式更好閱讀與重構。一旦共用，那就得要對版本進行嚴格的把關，向下相容與抽象等等設計均不可忽視。

Vue 的優缺點

竹子日誌（竹子） — Sun, 25 Aug 2024 02:16:27 GMT

應該不少人看過我護航 Vue，我講過很多 Vue 的優點與缺點，今天我想要說說我寫 Vue 過來的感受。以主流的前端框架來比較，它的優劣到底在哪？

本篇預期會有砲火，我會選擇性開戰XD

以下我針對當前最流行的前端框架作為對照組，身為多個框架都體驗過的人來談。

優點：

Template 容易理解與學習語法，初學者上手容易。
官方提供完整的解決方案，不需要花很多時間了解套件選型。
撰寫自由度很大，開發者可以選擇 Template, JSX 不同的方案。（關於自由度可以對照這篇 https://www.threads.net/@f2e\_willy/post/C7SmbRCPr4\_/?xmt=AQGz8gmb-H\_0CCaS2hxE2BbSsTbdL4gizCDVZeqPOsks1g）

缺點：

生態相對小，套件庫數量和豐富度相對少
套件開發難度高，需要整合許多 API 的處理。尤其要支援 template 的難度尤其複雜，降低開源開發者製作意願。
內部進行依賴收集和響應，沒有明確宣告的程式碼，對於不熟悉的人理解意圖相對吃力。
型別架構複雜，自定義 TypeScript 的 Component 相對上手難度高。

特性產生的雙面刃：

因為容易學習，導致新手多，生態圈素質落差巨大。
因為仰賴模板語法，所以有很多背離 JavaScript 的語法出現。
官方已經提高許多固定的解決方案，所以相對套件生態圈不太去發展其他選擇。
官方提供過多的組成方案，套件作者為了符合各種情境去處理會吃盡苦頭。比如說支援 template 的解析。
因為過多自動化處理依賴和響應的功能，寫的時候很開心，很容易寫出不易維護的程式碼。

這篇無疑我就是想站在另一個角度，我不是完全覺得 Vue 沒有缺點，我只是想講，每個框架都有優缺點，不必去吹捧特定框架很棒、最好用、必學。工具就是工具，時代會變遷，工具會變化，吸取精髓才是不斷精進的不二法門。

生氣

竹子日誌（竹子） — Fri, 23 Aug 2024 00:35:28 GMT

這話題熱度延燒，也讓我看到一個令人生氣的文章，但想想覺得不要直接在版上噴。

「前端工程師為什麼不能完美重現設計稿」

如果一個有想要教設計師如何自己搞定網站，都什麼時代了還在要設計師一條龍？最要命的竟然說出要「工程師腦補」？現在開課都喜歡煽動情緒引發話題？

一樣的議題，河道上很多設計師發言是有水準的，我覺得很棒。但竟然有人出來賣課程將這種鬼話？要不要讓底下團隊看看他在講什麼？

實在不懂為什麼可以教育人，RWD 需要工程師腦補，工程師不腦補設計師要花 10 倍的時間溝通？這是什麼神奇的邏輯？難道工程師腦補的結果會比較好？不是說工作完全不存在通靈腦補，是願意去通靈是想要把事情做好而付出的努力和嘗試，但不是應該的⋯⋯

是不是慣老闆直接講：「你們設計師要自己幫客戶腦補？」聽起來很開心？

Pixel Perfect

竹子日誌（竹子） — Wed, 21 Aug 2024 21:57:26 GMT

近日看到版上有人在抱怨前端工程師為什麼不能完美重現設計稿，關於這個議題其實我有蠻多想法，先撇除不願意用心的前端，我先建立在前端有不錯的基礎實力和意願，依然能完美重現嗎？

首先是 RWD，大多設計師認為我都出到3個版了，應該可以很好的重現了吧？事實是：如果設計師的 RWD 沒辦法做到「每一個 pixel 」和「每一個變版」都考慮到，那即使你出10個版都做不到。

接著是 UI Framework 的使用，如果沒有 Guidelines 的概念，天馬行空創造各種獨特的元件，雖然不是做不到，而是曠時費力。如果不是用現有的 Library ，而是另外需要刻一個獨特的元件和流程，那勢必要花相當多的時間。為了時辰的壓力，普遍工程師應該會權衡輕重放棄刻出來。

還有是可執行性，經常會聽到奇怪的需求。

「這個字可以幫我調整到8px嗎？」

「這個文字可以隨著 RWD 自動縮放嗎？」

「這裡我希望可以自動按照高度”…”」

「我想要這裡可以自動長高並填滿」

「還沒滾到底時可以有陰影嗎？」

我只能說做得到，但有很多前提。真的了解這些需求其實是要動一些特殊手腳嗎？

最後是「魔術數字」，其實前端常常會看到 47px 之類的神器數字，它可能不是什麼百分比或填滿，只是「剛好被下了這個數字」。或許前端願意很細很細的幫忙對照，但大量這種情境真的會疲乏⋯⋯

說個好笑的，最近問了一個設計師轉職前端的朋友：「你覺得設計師要求前端 pixel perfect 合理嗎？」這位設計師面帶哭笑的搖搖頭，並回答我：「真的只能儘量⋯⋯⋯」

完美的版型是基於設計師和前端工程師共同打造的，並非前端獨自一人就可以做到。我跟每一位合作的設計師夥伴多半關係不錯，只有少數實在無法合作。我們都想要打造一個令人驕傲的網站，設計師與前端是夥伴不是死對頭。

伺服器渲染 (SSR)

竹子日誌（竹子） — Tue, 20 Aug 2024 01:29:00 GMT

前日我聊過前端已經不再是那個前端，我覺得可以稍微聊聊現在前端架構上發生什麼變化？為什麼跟過去不一樣了？

關於伺服器渲染，我要來講講在 SSR 如何實作登入機制。這邊先釐清，我這裡講的 SSR 不是傳統純 Server Side Render，而是指 Hydration Render，由伺服器提供 HTML 渲染後再由瀏覽器執行 CSR。

做過一般「前後分離」的系統都會習慣把 Token 放在 LocalStorage 來完成持續登入。但如果到伺服器渲染，先排除不打算做「混合式前端」，以純粹的伺服器渲染架構來說，首先就得面臨如何在 Rendering Service 進行Token 的存取。因為 Client 的 LocalStorage 在伺服器是拿不到的。

解決方案其實說穿了就是靠 cookies ，但不是說直接打 API 把 token 存進 cookies ，而是指以 http only 的方式去儲存 secret 或 token 的資訊到 client 端，再拿這組 secret 在 Server 換回 token。這樣就可以趕在渲染 HTML 之前就能拿到 token 去打 Backend API 取得渲染資訊。

當然不只一種做法，我也可以提出近十種不同的架構做法，但這是一種還算主流且容易實作，並在安全性策略來說還算穩定的做法。

我一直以來都不支持全 SSR，不管是對於工程師要求、專案要求、還有架構要求，相對提高很多實作上的複雜程度。我所見過 90% 的網站並沒有那麼「即時的」SEO需要，就算即時更新也未必爬蟲可以即時反映。因此我都是推崇採用 PreRender 這個解決方案。

下班接案

竹子日誌（竹子） — Fri, 16 Aug 2024 01:02:55 GMT

我其實在從事軟體開發之前就在接案

接案本身這件事跟「技術」不是絕對關聯性

只是有技術你可以賺你熟悉部分的技術與勞力

但它不是必要

我接案一路做了3年多左右

直到近期已經不太喜歡去接開發需求

因為純粹開發的勞力利潤實在很低

甚至回頭想

浪費時間在接案真的不是很划算⋯⋯

接案通常會做有80%把握的工作

所以靠接案學習的成分本身不高

開發案的開發勞力很難在接案市場拉高價格

除非開發模板化去降低開發資源

但背後的成本投資更遠遠難以回收

以平均每小時回收可能都不如時薪工

近期都是接教學或顧問工作

相對能換到的工時產值高很多

也能處理更複雜的商業問題

我希望有限的時間投資在更有價值的事務上

現在的前端已經不是你想的那個前端

竹子日誌（竹子） — Thu, 15 Aug 2024 00:41:16 GMT

或許有些公司還在用舊技術

或許有些公司還在努力轉型

最近不少朋友來諮詢我關於前端架構的設計

在溝通過程中最要命的問題是「團隊或主管對前端的不理解」

明明已經是成熟的軟體產品

功能大巨大到跟巨獸一樣

但對前端的認知還在「寫寫HTML檔案加上一些CSS和JavaScript就可以出現的技術」

或許你的產品不需要這麼複雜的前端

但如果是需要的

那請改變一下認知了⋯⋯

我自稱純前端，但我還沒學完

以我來說，我自稱「純前端」

對，我一直做前端，我也只關心前端

曾經有人跟我說「前端沒什麼好學的」，現在我只能黑人問號❓

我怎麼覺得我還沒學完？？？

那些「前端不用懂」的東西，前端都要懂

經常舊時代的軟體工程師覺得

必須要懂 Web Service, Database, Performance, Cloud Service, Micro Service, Infrastructure, System Design, Container Management …

前端都不用懂，弄好畫面就好，太簡單了！

前端要學 Web Service ，現在的 SSR 就是一個 Service，它不再是靜態檔案。

前端要學 Micro Service ，只是我們關注的是 Micro Frontend 的 Service 應用。

前端要關注 Performance ，但它關注的是 Rendering performance 。

前端一樣要學 Deployment ，如果不懂的前端，怎麼會覺得SRE會懂怎麼部署？以為扔扔靜態檔案就是前端部署？還有容器開發和容器管理、CI/CD⋯⋯

前端一樣要學 Database ，在瀏覽器上一樣能玩SQL Lite, IndexDB…

還有一堆只有前端才會碰到的知識點

除了上述這些，還有各種知識點⋯⋯⋯

瀏覽器和設備特性差異，這個排列組合遠遠比在伺服器的差異更多也更不可控。

使用者體驗並不是單純UI/UX 的事，前端經常也會需要懂，處理很多程式測試測不出來的微小感受。

動畫處理的非同步和極端的渲染議題，只要有一定規模都一定會遇上渲染難題，如何減輕使用者設備負擔。

打包議題，比 Compiler 更麻煩的問題，複雜的工具鏈和生態系，只為了盡可能縮小下載的程式總體積。

真的是⋯⋯求不要更新，學不動了⋯⋯

你還想到什麼我沒提到的嗎？

或是有什麼鬼故事能與我分享呢？

再來講個「老人」的發言

竹子日誌（竹子） — Mon, 12 Aug 2024 00:47:27 GMT

也有不少「老人」會說：「我們以前前後端都要自己做，你們現在很幸福了，還分什麼前後端。」

其實我蠻認同「使用者互動不複雜」或是「架構單純」的網站不要找前端，其實 MVC 寫一寫可能都比較快。或是那種一頁式網頁、簡單的官網什麼義大利麵寫一寫真的比較快。

但⋯⋯

以前的前後端全包？所以現在工程師素質比以前差？

那有沒有打算我拿以前網站製作的水準就好？

我覺得大家瀏覽體驗被 google 養壞了。要接受以前的水準恐怕很難，那種瀏覽體驗真的差了一大截啊⋯⋯

老人之所以老人不是年紀，是言行舉止，我們家 CTO 年齡雖大，但技術線依然在線，這種老工程師才令人景仰。

「交接」這件事

竹子日誌（竹子） — Sun, 14 Jul 2024 05:16:30 GMT

關於做交接這件事，我過去每一次換工作不管勞基法，我都會給自己的公司1個月的交接期，不會太長也不會太短。但這麼做每個人都有對於這件事的看法，但這是我對自己工作的態度。

如果是你，不考慮勞基法，你覺得應該多久足夠交接呢？

或許以資方角度，1個月根本很難馬上找到替補位置的人，別說人員交接。但對於新公司要等一個月也嫌太久，很怕人選突然 No show。

但如果換到勞方角度，我慢一點離開單位，如果新工作薪資更高，做一天虧一天。但大家都想要好好與同事道別，想要為自己努力一段時間的產品做好善後。

此時最討厭的是什麼？我想好好交接，但一直找我去開發新需求，沒有時間好好整理交接需要的東西。最後一天又急急忙忙要寫交接報告，因為來不及處理，又要求事後要跟同事交接。

其實我聽到很多這樣的案例，這個案例也真實發生在我的身上。那⋯⋯似乎給自己公司勞基法推規定的預告期就好了吧？多給的好像也會挪作它用，因為資方還是要付你薪水，這些成本不如拿來開發。

軟體工程師的薪資

竹子日誌（竹子） — Fri, 12 Jul 2024 05:28:44 GMT

這篇大概率會被戰，不過網路就是這樣XD

大家紛紛擾擾吵薪水高薪水低，其實是市場一直很公平，重點是怎麼操作。

為什麼軟體工程師的價格會偏高

軟體最大的優勢是「可迭代」、「容易跨地域」、「容易傳播」，正因為這些優勢讓科技大廠不斷投入，帶來單體驚人的產出。現在的軟體工程師確實是價格偏高，原因在軟體市場的變化與型態。科技巨頭們高速改善這個軟體市場，也開出夢幻福利，他們搶著最頂級的人才。但也是這樣價格被錯估，美國矽谷帶來新的一波失業潮，這就是現在的軟體產業衝擊。

大家看著夢幻薪資，加上軟體公司一間一間開，許多企業也在數位轉型，需求的暴漲這正讓每一間公司不斷爭相挖角人才。很多公司生怕找不到人，「人才不是即時需要，但我擔心我很快就會需要」，現在很多工程師頂著莫名奇妙的高薪，但沒有提供對應的產出，也沒有解決相對等級的問題，逐漸的產生冗員。這樣的趨勢導致市場錯估，逐漸高估薪資，也讓軟體工程師薪資一躍成了新寵，大家都想轉職進來。

缺口補上之後，門檻開始往上提

人多了，這個缺口慢慢補上，似乎不這麼缺人了。從資深工程師中釋放出來的人因為求職困難，開始往下走，逐漸壓縮中階工程師的生存空間。慢慢的，「入行門檻」便會開始提高，以篩選掉「還不能成為戰鬥力的新手」。過去因為實在找不到人，只好把「還不太行的找來自己教」，但現在則是「直接找能到位的人」。如此就會暫時取得一個平衡，這也是為什麼轉職難度暴增，但為什麼工程師薪水不會雪崩下跌。

資方立場當然是找到最划算的員工，既能帶來公司最大價值，也會是找同等價值中最便宜的。但找人才永遠不是這麼簡單的事，其中參雜的變數可以說是非常多，真的很難衡量。很多老闆真以為請一個新手，差不多差不多就可以聘僱，事實上這只是在埋藏禍根。很多工程師以為不斷追求高薪就是提高技術，其實隨著這股裁員浪潮，規則正在被改寫。

培養一個有基本戰鬥力的工程師有多難

但說實在話，培養出一個「具備基本戰鬥力」的工程師真的是一件蠻困難的事情⋯⋯

我學過不少領域的技能，也教導過很多轉職者，看一個什麼都不會的人到真的學會帶來生產價值這件事。以「軟體工程師」來說，真的是非常非常高的轉職門檻，這也造就這行能夠永遠樹立一道薪資高牆的原因，也是為什麼那麼多人趨之若鶩。

人為失誤

竹子日誌（竹子） — Wed, 10 Jul 2024 00:38:49 GMT

過去我經常被主管和老闆責怪，「你怎麼那麼粗心？」、「你怎麼經常寫出 Bug？」、「怎麼又讓系統出問題？」。其實我一直很內疚為什麼總是會犯這些毛病，也很討厭這樣的自己。但性格著急的我，總是想趕快端出成果，可以讓主管滿意。隨著我的資歷增加，一次次換工作，我並沒有變得不容易失誤，但我的失誤卻逐漸對專案造成的影響變小了。

你可能覺得奇怪，一個會經常失誤的人，怎麼可能會突然減少了對實際工作的影響？其實關鍵就在「QA 機制」和「CI/CD 的 Workflow」。

有很多公司都是「深怕動到一點點導致東西壞掉」，也有很多主管「責怪底下的人經常失手搞砸」，做什麼事都戒慎恐懼。但奇怪的是，他們也經常講「我們公司小，不需要搞那麼多機制」，卻很喜歡經常檢討「為什麼犯錯？有沒有辦法改進不要再犯？」。其實我覺得這就是矛盾的行為，又不希望投資在增加機制保護，卻又覺得底下有人犯錯是罪不可恕。其實人都是嚴以律人寬以待己，當自己犯錯的時候都不願意承認，逃避錯誤，但別人犯錯卻大張旗鼓批鬥。我不認為公開指責是錯的，但這屬於文化問題，不要有「找戰犯」的文化，並不是每個團隊都適合。

回過頭想講，有 QA 機制與負責 QA 的人員就是一道堅強的產品品質保證，不能將風險降低至零，但確實能有效防堵細節失誤。而 CI/CD 機制也是大幅減少人為的粗心失誤，因為伺服器操作和分支合併檢查都自動化，就不存在人為失誤，可以徹底杜絕。

其實透過好的團隊機制可以減少缺點，一個優良的團隊才能最好的放大一個人才的優點，而非凸顯人才缺點。隨著時間成長，經驗也確實讓我避開很多問題，但我也更重視這些基礎設施的建置。

設計系統到底是誰的責任？

竹子日誌（竹子） — Tue, 09 Jul 2024 09:11:51 GMT

溝通這件事並不是單方面，設計師和工程師都有自己的課題，只是儘量建立一致的溝通語言。過去沒有對應的工具和規範，設計師隨便畫，工程師隨便做。現在各種工具輔助，Figma 就有 AutoLayout, Variants, Variable, Component，近年興起的 Design Token 也是希望建立一致語言。工程師生態出現 Martial UI, Ant UI, Headless UI，有對應的 Theme System。

但工程師和設計師卻開始覺得「以前好好的，我幹嘛學這些工具？」

工程師說：那是設計的問題

工程師開始表示了， Design Token、Design System、RWD 是設計的問題，我程式怎麼寫跟設計無關吧？反正我就按照套件給我什麼再去改，改不動就改不動。花一堆時間學底層的 theme system，換了一套不都沒用？反正我按稿施工，差幾個 pixel 又沒差，哪來那個美國時間 pixel perfect？你功能做的有問題，畫面調整到完美都沒有意義。

設計師說：CSS 是工程師的問題

設計師也很不滿了，CSS 是工程師的問題。RWD, AutoLayout, Variants, Variable, Component, Design Token, Design System 我花一堆時間做，但也是方便到工程師，我也沒比較輕鬆，工作也沒比較少，反而花時間建置設計系統就飽了。

這些東西本來就只是溝通工具

其實也吵不完，這些東西就是溝通工具，不外乎是建立工程師和設計師的溝通橋樑。讓工程師不要碰設計稿，讓設計師不要碰程式碼，使用可以文件規範而且有邏輯性的東西，兩邊都不想學就只能繼續這場誰也不讓誰的戰爭。

坦白講，不要講設計師，我根本沒看過幾個工程師懂「Design Token」的使用，大多以為平常用的 theme 和 css variable 就是 design token。

那這些工具真的有必要嗎？

你可能會問：「這些工具和方法輪真的有必要嗎？真的有提高效率嗎？」

我也會直白回答你：「沒有必要啊～」

敏捷開發、Figma、UI框架，其實沒有這些東西都可以開發，學習這些東西也很辛苦。其實只要找到讓團隊「有效溝通」的方法就好，這些不過是軟體開發的方法論而已。

一般情況，單論「效率」，我可以講「幾乎沒有」。要產生追加效率有很多前提，比方說多人設計師合作、有多產品使用同一套系統、工程師技術線一致。

但⋯⋯蠻難吧？

最有價值的是一致的設計語言

我覺得最有價值的是「一致的設計語言」，不管是設計端或工程端。當有人員流動時，有一個通用的框架及標準會更容易交接、上手。

AI 幫忙寫測試

竹子日誌（竹子） — Mon, 08 Jul 2024 00:26:21 GMT

前段時間跟主管聊天時說，老闆希望導入 AI 提高工作效率。我心裡其實瞬間黑人問號⋯⋯導入 AI 需要等到現在？不管是 GPT 還是 Copilot 我已經使用很長一段時間了，提高我的生產力這點確實無庸置疑，我是等不到公司自己提出來啦～

接著聊到測試，這就更讓我有感。技術長希望可以提高測試覆蓋率，看能不能用 AI 協助幫忙寫測試。這個問題我的答案是「可以」也「不行」，確實只要提供必要的 context，AI 可以很有效提供好的解決方案，但我實在覺得當今 AI 對於寫前端測試的成熟度實在不太夠。

我已經使用相關工具一陣子，如果輸入輸出明確的，大多沒什麼問題。但前端元件真的是一個參數量十分噁心的地方，各方資訊參數灌進來畫面上，會產生的副作用、互動、事件、體感問題、樣式問題⋯⋯都是對結果有莫大影響，簡單的或許可行，稍微複雜一點，要靠 AI 產生測試明顯還有一段路。

常常寫前端測試就是各種 mock, spy… 想要分離好單元真的是格外痛苦⋯⋯很難真真實實做到「單元測試」，一個不小心都是在寫「整合測試」。整合測試像在前端測也很難達到 100% 覆蓋率，因為前端的「渲染時間差」會造成很多明顯問題，然而很難在測試工具中被驗證。

常常說，AI 要取代工程師了，拜託，快來取代我，我等你XD

Mock Server

竹子日誌（竹子） — Thu, 04 Jul 2024 00:28:00 GMT

前端常常在開發時，未必能保障後端或是外部資源都能是良好運作，很怕任何開發環境資源掛掉導致無法開發，又或是根本還沒完成開發就要先動工。這時 Mock Server 就很好用，模擬一個伺服器環境，通常可以用 nodejs 或 service worker 起一個仿後端的環境，模擬所有預想的行為。

當然也有一派人不認同這種作法，明明後端要開發一次，前端又要開發一次，無非就是拉高開發與維護成本。

你前端開發會起 mock 環境嗎？

還是會等後端寫完才動呢？

Side Project 宣傳

竹子日誌（竹子） — Wed, 03 Jul 2024 00:35:29 GMT

因為沒有留言和愛心去頂流量，其實觸及真的蠻有限，但仍然有許多人願意私訊我與我聊聊，希望能再進一步擴大這個觸及率。

歡迎有興趣的幫我留言 +1

這個計畫你可以當作從頭建置一個 antd, mui, vuetify, element-ui 這樣的 UI Lirary。

其中我並不會基於什麼 UI 框架去打造，而是「造輪子」從頭打造，從基礎設施自定義 bundle script，到每個元件細節的功能完成都嘗試去製作。

我們會與 UI 設計師配合，依照他們所製作的Design Guideline 準則進行開發，不是單純只給工程師用，而是包含設計細節都得考慮。包含 i18n, Dark mode, container RWD, theme system, CSS inject等等考慮各種應用場景並實現。

希望做出可以通用在 Server side render 和 Micro frontend 兩種架構下都可以運行的 UI 框架。如果心有餘力我希望把核心邏輯抽出讓跨框架也可以去使用，而非單純整個綁死在特定框架邏輯上。

初版會先以 React 架構作為主體，如果你是擅長 Vue 的也可以協助建構相關基礎建設功能。

我這邊目前會使用到的技術包含：

TypeScript, rollup, webpack , storybook, monorepo … etc.

團隊氣氛很隨性，有空做，沒空講一下也沒人逼你。不會派任務，自己找自己有興趣的部分提出設計，然後實作。每兩週的週日晚上會進行會議同步大家的情況，像是分享會一樣一起討論一起分享專案與工作上的點點滴滴。

我這邊不希望有「人家做得很好了，我們做不贏」的心態，而是「人家做得很好，但我們要研究模仿後比他做的更好」。目前我只考慮使用通用的基礎套件如 dayjs, lodash 這類型的，而非使用現成解決方案。我希望集結眾人力量去把每個細節打造的更好！

UI Framework Side Project

竹子日誌（竹子） — Tue, 02 Jul 2024 00:38:27 GMT

我今年大概大部分的心力都在這，年初時開了這個 side project 一路做到現在，總算是看到了點成果。為了讓一群相互不認識的願意貢獻參與不是容易事，畢竟讓大家下班後努力付出不是容易事。

這個計畫你可以當作從頭建置一個 antd, mui, vuetify, element-ui 這樣的 UI Lirary。其中我並不會基於什麼 UI 框架去打造，而是「造輪子」從頭打造，從基礎設施自定義 bundle script，到每個元件細節的功能完成都嘗試去製作。別問我現在那麼多 Library 為什麼還要再造輪子？如果要說理由，那什麼也不用做了！

其實 UI 設計師相對容易找，我找到很多很棒的 UI 設計師參與，許多都是在國外的台灣人，一個比一個卷。我現在仍然在找前端，能夠參與的前端工程師真的是少之又少⋯⋯

好啦，講這麼多，就是來 threads 上面找戰友，歡迎私訊我詢問詳細訊息！

隔行如隔山

竹子日誌（竹子） — Fri, 28 Jun 2024 00:48:44 GMT

最近認識了一位藥廠的業務主管，與他促膝長談各種經營管理等等，我也不吝嗇分享很多軟體業的底層問題與解決方案，相談甚歡。

我們聊起了我們共同朋友要開發自己公司的軟體產品，他們都是科技硬體產業相關背景，但真的壓根不懂何謂軟體開發，路上也確實踩了不少地雷。這每一個事件抽絲剝繭都是傷痛，也燒了近千萬資本額去試錯。

剛開始想的簡單，做下去才知道水深。也許你認為可以便宜做、簡單執行，弄出一個差不多的東西，然後投放市場。但事實常常沒有那麼的簡單，很多時候你都有不得不面對的問題。

管理問題，營運問題，市場問題⋯⋯

創業面臨的都是這些種種挑戰，創業在享受超然獲益後的理由前往往是要承受驚人的壓力與風險，特別是軟體這種槓桿操作很高的行業別。我必須說軟體的程式碼本身根本不值錢，有時候真的跟一坨屎一樣，但有價值的是商模和解決方案，要賣的是服務不是冷冰冰的軟體。真的不要以為各種美好的偉人故事靠軟體創業翻身，首先你的市場評估呢？你的解決的痛點是什麼？

微前端系列（十三）

竹子日誌（竹子） — Mon, 24 Jun 2024 00:31:34 GMT

樣式管理問題

在前端來說，CSS 是一個非常重要的架構，影響著程式的呈現和畫面的呈現。但CSS 終究不是程式，能做到的事情是有限的。過去到現在有許多技術都想去解決這問題，形成現在生態圈大亂鬥。

微前端中，在選用這些 CSS 的解決方案就要更加小心，畢竟 CSS 是不分作用域的。

CSS Module

這是 JavaScript Module 時代開始後最常見的樣式模組化技術，靜態化打包 CSS，對於微前端應用處理非常友善，有效切割了各種獨立模組。但共用處理效果不好，因為預設是網 head 注入，如果沒有妥善注意設定，很可能就會造成副作用。

Component Selector

最主流的是 Vue 採用的 SFC 樣式注入方案，透過對相同的 Component 標上 hash attribute ，確保精準選擇到 className 對象。除了作用域明確切開，對於微前端共用 Component 效果也相當好。這種方式缺點是跨應用共享困難，hash 本身是難以溝通的。

CSS In JS

最主流的是在 JSX 體系，沒有樣式模板的支持下，想當然爾需要 JS 的動態注入，也是各項方案中同時滿足作用域切分和共享的方案。共享方式便是將 style sheet 當作 cache base 傳遞，這樣就可以共用樣式上的基礎。

Atomic CSS

當今最流行，且多生態都支持良好的樣式解決方案。在微前端中搭配動態渲染引擎，可以高效率去共用每一個樣式規則。但這也是所有解決方案中隔離性最不好的，他沒有任何作用域保護，一旦共用的 Config 設定被修改，就會帶來大範圍的影響。

作用域方案的三種模式

除了主流解決方案外，作用域方案大致也可以分門別類幾種模式。

全域作用域

傳統的 CSS 撰寫和 Atomic 基本上都屬於這種，複用容易。但問題在如果沒有嚴謹的規範，容易因為不同的客製化導致相互污染樣式。

Hash 選取作用域

如 CSS Module, Component Selector, CSSinJS 等等方式幾乎是預設採用這個方案，有明確的作用域，能有效避免污染問題。然而也正是因為這種隔離，導致共用不易。加上仍然屬於全域 CSS，如果有心依然會發生污染等可能性。

Document 作用域

如 iframe, Shadow DOM 都是這種解決方案，直接放棄共用的考慮，徹底執行作用域隔離，真正做到 CSS 作用域隔離的解決方案。不但幾乎無法複用，有些 Library 使用上也可能不支援這個情境，讓開發技術選用上邊的十分不方便。

轉型博弈

竹子日誌（竹子） — Thu, 20 Jun 2024 09:53:41 GMT

到底博弈多好賺？

我已經聽到好幾個案例都是公司老闆開始接博弈案子或是博弈的產品，從非博弈到博弈是很的轉型，但很多老闆只覺得我只是換一個賺錢的東西。

市場上的職缺有超過一半都是博弈職缺，但薪資卻不如過去的高，這種人才匱乏現象依舊沒有好轉。

很多人其實蠻抗拒做博弈產品，背後因素很多，但博弈產品確實不好找人，擺明大家都有所抗拒，特別是資深的人。

該造輪子了嗎？

竹子日誌（竹子） — Mon, 03 Jun 2024 14:38:13 GMT

該站在巨人的肩膀上使用開源套件？

還是該造一個合用的輪子滿足需求？

我也來分享一下我的看法。

我認為對於經驗不足的工程師，優先使用套件肯定不會錯，能夠用套件解決就用套件，這個階段造的輪子不可能寫的比套件好。

對於有經驗的我還說建議使用套件，但這時候你應該知道「套件做了什麼」。不要覺得套件是萬靈丹，你應該知道套件幫你解決了什麼問題？做了什麼事？用這什麼原理達到你的需求。適時在閒餘時去練習造輪子，可以加速自己對技術的理解和學習不同的技巧。

對於資深的人來說，我覺得應該是「有條件的造輪子」。相信現成的輪子已經慢慢無法滿足資深工程師的需要，難免會碰上需要造輪子的時候。我這時給出的建議是把知名套件的原始碼進行閱讀，了解別人在執行相同功能時怎麼解決問題的，充分的做好研究後再來造自己的輪子。

這個萬年吵不完的話題，你怎麼看？

慣老闆的奇聞軼事（一）

竹子日誌（竹子） — Thu, 30 May 2024 23:54:05 GMT

最近認識的老闆想找大學實習生來幫忙做一些事，我聽了真的搖頭⋯⋯

「我讓實習生免費幫我們公司畫 UI，看看成品裡面有沒有可以用的。」

其實如果有企業願意回饋社會來教導新鮮人，培養國家幼苗，我真的喜聞樂見。但真的這麼想的我覺得很少，大部分都是用「貪小便宜」的心態在找實習生，我覺得糟糕。

公司的角度來說，我並沒有覺得撿便宜。

實習生其實是沒有任何業界基礎，學校教育的多半是「學術性人才」，並無法立即投入實戰。所以實習生是需要前期的一部分知識教導，然後做出來的東西是需要做評估和調整的，這無疑是在提高內部人員的工作量。學生也是比較新一代的人，通常會在網路或同儕間相傳公司的清況，管理良好和風氣快樂是宣傳，處理不好等同宣佈大眾說「我們公司很爛，希望大家都知道」。

以實習生角度來說，我也不覺得是機會。

實習生需要的是與業界接軌的工作經驗，可以在進職場前就有業界的前輩提攜，得到良好的訓練。然而，貪小便宜的老闆多半是不會派人去手把手教學，甚至是自己就要自立自強學習，沒有人帶領。其實這樣的環境對於一個剛入社會的實習生來說，根本是挫折感滿滿。好一點學到獨立，慘一點是光速摧毀熱情。

我其實不知道這樣是否常見，只是剛好被我遇上？

你可能不需要 SSR

竹子日誌（竹子） — Thu, 30 May 2024 23:33:05 GMT

現今 SSR 框架當道，什麼都要搞 SSR 框架，Nuxt, Next, Universal，各種技術不斷興起。前後端花了近十年分離的架構即將又要融合為一塊，這就是現在網頁前端的趨勢。

先看 SSR 帶來的三個好處

我們先分析 SSR 帶來的好處：

能倚賴 Server 提供 HTML 結構，可以讓爬蟲能更快更容易爬到動態的資訊內容，以提供最佳化的 SEO 效果。
Server 端的運算力相對可控，能在有效率的情境下提供渲染運算，減輕 Client 的運算負載，提高 FP, FCP，讓使用者更快看到畫面。
減少 CLS ，讓畫面一開始就不會重複渲染。

但這些問題，真的是問題嗎？

但這些問題真的是問題嗎？

關於 SEO 的問題，其實真正需要的應該是建立 SSG Service ，提前預渲染 HTML，最快速提供 HTML 給爬蟲爬。有多少網站真的需要「非常動態」去產生 HTML 呢？其實跑個排程定期去 Generation HTML 就非常足夠，只有極少高頻率更新的網頁需要 SSR 這麼動態產出。

關於渲染效率問題，Server 一開始就提供資料雖然感覺上更快提供資料，但伺服器之間相互通訊也是得消耗一定的時間。換言之，當伺服器因為資料量過大而撈取過久的時間，對於使用者並沒有感到更快。反而如果先提供基本的 Layout Container，再以非同步方式去更新和追究資料，還能讓使用者更有預期的去等待資料完成。

關於 CLS 本身就不該是問題，切版本來就要考慮設計出來的容器大小，不要過度依賴資料撐出寬高，得考量更多更複雜的版面情境。

仔細想想，你的網站真的非 SSR 不可嗎？

再看 SSR 帶來的副作用

如果看看 SSR 帶來的副作用：

當架構簡單時，甚至要為了 SSR 多開一組 Service 的資源。
處理資料流更複雜，前端同時要整合伺服器和瀏覽器的狀態和資料流。
架構變得更複雜，原本簡單的 Client 議題可能到了 SSR 架構複雜度上升好幾個等級。包含多國語系、權限管理、使用者裝置判斷渲染⋯⋯
表面上降低初始載入資料量，實際上在傳輸過程中，SSR 要多承擔 HTML 的資料，和不亞於 CSR 的 JavaScript 綑綁資料。

不是沒有價值，是大部分情況真的不需要

並不是 SSR 毫無價值，完全不需要，但大部分情況真的不需要。有時實在覺得不需要追流行追技術，能更簡單容易的解決問題才是商業上更需要的。或許時空背景上，未來又有不同的結論，但現在來講，我還不是很認同過度追求 SSR。

微前端系列（十二）

竹子日誌（竹子） — Thu, 30 May 2024 00:29:20 GMT

路由器設計

在微前端架構中，路由器（Router）是不得不面對，而且情境極複雜的一個議題。

因為 browser history 的對象在整個前端應用程式是唯一的，不會存在第二個。但如果有多的前端應用程式產生出多個 history 的操作器，那高機率就要打架了。在整個運作系統之中，最怕的就是「改了不動」、「改了不知道」、「遞迴循環修改」等情境。

其實看過各大框架系統，都不太推薦微前端模組另外開自己的路由系統，多半鼓勵以「原子化元件」作為切分點。如果以元件切分，確實路由議題可以全然仰賴上層主應用控制，它本身的渲染控制便不在元件邏輯內。

但相信做過微前端的都知道，你每個微前端切分成本很大，會希望一個應用包裝更多功能而不要切分，這就延伸新的問題「路由器的狀態同步」。狀態同步議題其實回到上一篇講的「單例狀態管理」，解決方案是一致的。

說穿了，就是微前端應用「不要直接操作路由器」，那不操作路由器該怎麼操作與通知？其實是一樣的解法，採用單向資料流的方式統一管理，讓可以改變狀態的窗口全部一致在某個觸發點，不能全世界好幾個地方能改。當單向資料流徹底管理後，就可以很容易去攔截所有路由的副作用，如此一來就可以建構狀態管理系統去「取得」、「修改」、「監聽」，行形成一套資料流。

這個問題真的搞了我很久⋯⋯

自我介紹

竹子日誌（竹子） — Mon, 27 May 2024 01:21:28 GMT

前端工程師，社群的朋友都叫我竹子。

React, Vue 雙棲
專注在 Micro Frontend, Frontend Infrastructure
社群活躍者，喜歡參加與舉辦社群活動
發起 UI Library 相關 Side Project
樂於分享與提攜，喜歡幫助認真的新人

如果你想與我挖掘更深的前端，歡迎一起交流分享，我喜歡有深度的交流。

微前端系列（十一）

竹子日誌（竹子） — Sun, 26 May 2024 04:00:56 GMT

全域單例狀態，狀態管理器。

開始講到單例狀態就要稍微舉例一下什麼是單例狀態，其實就是泛指所有 Singleton 的物件。舉凡整個應用程式只有唯一的狀態，便都是這種狀態。比如「History Router」、「Locale Language」、「Browser Storage」都算是。這類的狀態不但可以進行微前端溝通，還會產生副作用。如果沒有良好的控制管理，都會引發許多狀態管理的麻煩。

那應該怎麼處理？

你會發現很容易發生「循環修改」，資料流的混亂。你根本搞不清楚誰先誰後，誰頭誰尾。

我其實最推薦的情境是，如果這個狀態修改是「同步」的，那就採用 Flux 管理，應用單向資料流去限制資料流向，集中所有副作用發生的節點。

但要控制好這個資料流並不簡單，因為很容易發生資料被到處修改的問題，所以做好攔截的通道口就是一門大問題。

沒有管理經驗怎麼辦？

竹子日誌（竹子） — Sat, 25 May 2024 03:25:11 GMT

不少人都想要往管理職爬，但遇到一個千古難題⋯⋯

上司：「你沒有管理經驗，所以沒辦法讓你升管理職。」

下屬：「但我沒有做過管理職怎麼有管理經驗？」

上司：「去做管理職就好啦！」

下屬：「那我要做管理才會有經驗啊！」

上司：「但你沒有管理經驗啊！」

⋯⋯⋯⋯無限循環

這其實也是很多人的通病，總覺得什麼都得在職場獲得。雖然職場實際的管理經驗對大部分企業來說是最重要的，但你沒有這個選項的同時，你退而求其次要往外部機會尋找。

什麼是外部機會？

其實就是指自己創造領導的機會，自己累積領導的經驗，自己培養領導者特質。有意識去爭取機會，學習把事情管好。最簡單的方法就是發起社群活動，開立 Side Project ，集結各方有志之士達到某種成果。大家為了目標而來，為了你的夢想聚集，如何把一群人心集結在一起做事，這就是領導。

過程中⋯

你要解決別人對於你思想挑戰。

你要解決團隊成員衝突的問題。

你要分配每個角色合適的位置。

你要激勵大家向前衝刺的熱誠。

這不就是領導？

但企業承認嗎？

試想，當兩個人選中，一個有「相似經驗」，另一個「沒有經驗」，真的要選時會相對偏好有近似經驗的。

自由的框架

竹子日誌（竹子） — Wed, 22 May 2024 00:21:55 GMT

網路上都說 React 是款自由的框架，但我在寫的時候並不這麼認為。

React 其實限制很多

hook 不允許改變順序與判斷，看似提供多樣的封裝，其實有有嚴格的規則。
React 只允許 JSX 和 jsx render function 兩種寫法，不會讓你看到太奇怪的。
官方已經慢慢放棄 class component ，新生態圈幾乎放棄這種寫法，逐漸統一使用 functional component 。
看似控制力強大的 dependencies ，其實並沒有給你選擇的權利，甚至直接出 ESLint 請你遵循。
提供的 API 看似稀少，但其實每個 API 存在複雜的職責和邏輯，甚至有些底層功能並不提供，鼓勵使用 Library 來滿足需求。
看似自由簡單的 functional component 對於 FP 以外的寫法並不友好，常常會需要避坑放棄而放棄一部分的寫法，正因如此更讓它有 Functional Programming 的味道。

純論自由，Vue 自由到很噁心

純論自由這件事，我覺得 Vue 自由到很噁心。

UI 的寫法無論是 html, pug, jsx, render function 都可以，甚至可能發生模板語法混 JavaScript Rendering 語法。
寫法上有 option, composition, class ，都可以交叉使用，讓你搞不清楚現在到底在用什麼 API，有時混著寫都可能發生。
大部分 api 基於 observable 延展，狀態不一定寫在 component ，可能任何地方都會產生狀態並產生依賴。
API 多達上百種，學起來跟認識起來極其崩潰。其中一半都說語法糖語法，出了 vue 圈不見的使用得到。
對於寫法的容納性超廣，OOP 、FP 都可能出現，甚至極端性交雜都有可能。
學習門檻低，亂學亂用都會正常運作，導致市場充滿新手和髒 Code。

我愛 Vue，但我現在寫 React

我個人認為 Vue 是我用過最自由的框架，根本是全套自助餐。帶來的缺點很明顯，就是太過自由導致市場上各種獵奇的風格。

因為自由，我愛 Vue，我喜歡用 Vue 寫小東西。

因為我被雷到超怕，我離開 Vue ，我現在工作寫 React。

設計一個 Design System

竹子日誌（竹子） — Tue, 21 May 2024 00:46:56 GMT

一個設計系統最關鍵的就是「一致性」，所以大部分的設計系統都是在現有的產品調性上歸納出「風格」，最後整理出相應的規範，這也是大部分設計系統的誕生。但如果本身企業或是產品就有所謂的「調性」，那這種隨性的作法就很有可能走歪。

在規劃一套設計系統的初期關注點不會是component，更不會是實現的可實作性，而是更加包容的「Design Language」。建立一個設計系統前期需要經過大量的資料翻找，並且有足夠的基礎知識認知，並建立一套規範性的「設計語言」，而非關注在實踐細節上。

近期執行的 side project 我總是想拉回設計師：

「我覺得一開始不需要關心實作問題，也不用去看元件。」

我認為從頭打造新的 Design system 時，需要更多的「發散」，尋找解決方案與獨門味道。不管是在 Research 或是討論，一開始先發散思考可以搜集到更多的想法與創意。

我只想吐槽⋯⋯

可以不要讓工程腦去叫設計腦「請發散一點」嗎？

微前端系列（十）

竹子日誌（竹子） — Tue, 21 May 2024 00:15:35 GMT

模組共用問題

模組共用是微前端在切分時，跟微服務最大的不同。前端是有流量上的消費，每一個客戶端都會造成伺服器一定的負擔，所以像是微服務單純的切分，微前端更要經常煩惱「共用」議題。

這又不得不提到 module federation ，MF 並不是一個套件，而是一種多模組的管理系統的思維，只是有套件實現了這種思維。

MF 的理念基本上貫穿所有「模組共用」的思維，使用多服務進入點管理多版本的 packages，具備版本識別與切分環境的能力，讓多個組態情境能良好管理各自的環境版本。

如果要細談 MF 可能完全可以開另一個篇章，所以就不打算在微前端篇章提及其實作與原理，還有其相關特性。

目前其實幾乎找不到比起 MF 更完善的其他解決方案，幾乎仰賴大量的基礎建設架構的實作實現，我個人還是建議就用吧。

但也不得不提及，一旦使用了 MF，模組化就會被綁定在特定的 chunk system ，遷移上變成整個架構的成本。微前端雖然有分散部署的優點，但架構面的部分仰賴一致的規範與協定，如果一致的部分發生變動，那就會根本性的需要大幅度調整。

UI/UX 設計的思維模型

竹子日誌（竹子） — Mon, 20 May 2024 00:36:14 GMT

最近的 Side Project 和一群 UI 設計師合作，開了幾場關於的 Design System 的研究分享會。有點感觸，覺得太多工程師總是教育設計師用「能不能做到」作為思考，常常在初期設計和前置研究階段就已經在煩惱「實作細節」。對於一個 UI 設計師來說，更應該去發散解決方案，而不是在初期去收斂思維來限制自己綁手綁腳。

所謂 UI/UX 設計師的思考模型是不容易培養的，通常看到的都是兩種極端。

媒體平面設計師的思考：

解決使用者的感受問題，讓視覺達到平衡。我就是一個打造成品的職位，產品猶如作品一樣需要自己不斷雕琢，利用發散思維讓產品豐富。

工程師的思考：

解決運行上實際的問題，讓產品能夠被誕生。控制各項開發成本與維護成本，避免不必要的延伸，利用收斂思維控制不必要的成長方向。

但 UI/UX 設計師呢？

使用者體驗產品過程遇到的許多困難和問題，我的職責是規劃產品能夠具備解決方案，以保證使用者體驗舒適。利用發散思維找出豐富的解決方案，利用收斂思維去控制不必要的開發與維護成本。提供完善的資訊以保證功能實現時可以符合規劃時期待的成果。

我覺得這種具備複雜左右腦並具的職責，同時要思考發散與收束，對一個人來說實屬的不容易。但充滿誤會的世界依然是如此⋯⋯

微前端系列（九）

竹子日誌（竹子） — Wed, 15 May 2024 01:30:05 GMT

微前端的溝通

在微前端中，跨應用溝通是一個非常麻煩的事，你沒辦法像平時習慣的一個 “import” 語法來傳遞共用。那到底在微前端怎麼做跨應用溝通呢？

其實我們可以知道，所有微前端其實都是運行在同一個 global 之下，所以只要在一樣的 global 就一定可以被溝通。

那這個 global 是誰？凡是在這個 website 下，singleton 的所有對象都可以是溝通媒介。舉凡，同一個 backend service 、同一個 window object、被定義為 singleton 的 object 都符合這個條件。

那有沒有具體方法呢？

其實我可以舉幾個常見的手法來說。

使用套件來協助溝通，這樣不需要維護複雜的機制。常見的方法是使用 module federation 共用同一包狀態管理器，由它的內部機制來溝通。
使用 browser 機制溝通。通過 EventTarget 來做事件派發，可以向 window, document … 等等物件來進行溝通。或是使用 broadcast channel, message event, service worker 等等方式觸發。搭配 localStorage, sessionStorage, cookie, … 等等方式進行資料傳遞。
使用後端串接 web socket 來溝通，以後端作為溝通橋樑，將資料存在後端，並使用 ws 進行事件觸發。

其實說穿了，每個方法都很像，其實原理顯而易見。如果是你，你用什麼方式呢？

每一種寫程式的呈現都是一種「風格」

竹子日誌（竹子） — Tue, 14 May 2024 00:44:42 GMT

網路上無盡的都在吵，這樣寫比較好，這樣寫比較合適，但我認為⋯⋯這都是「個人」的定義。你可以找千百個理由說服我怎麼寫才好維護，但你永遠不知道另一個人是怎麼想，每個人都有各自的想法與理由。

我其實蠻疲於爭執怎麼寫比較好，我知道我有我的風格，我也知道別人也有他自己的風格。但我想說的是，我不會想干涉其他人怎麼寫，只要符合說好的「規範」，那剩下純屬風格問題。

經常有工程師舉著「這樣比較好維護」的高旗說道，但其實並沒有什麼絕對的「證明」說比較好維護。程式碼閱讀邏輯時容不容易跟閱讀者的背景有極大的關聯，而不是一句「這樣比較好維護」，這其實相當主觀。

我個人觀點多半是「隔離」，我不想去強迫它人，每個人的確有很多背景因素，那只要做好責任隔離就好。

如果是你，你會怎麼做呢？

微前端系列（八）

竹子日誌（竹子） — Mon, 13 May 2024 00:36:24 GMT

很多人提到微前端，反射神經就會想到「Module Federation」，中文稱之「模塊聯邦」，以下簡稱 MF 。但 MF 並不是微前端「必要的」存在，甚至並不是一個 Framework ，它只是一種 bundle 的概念，也只是一個共享程式和共享記憶體的一種手段。

MF 是把各個套件的各個版本分散式存在每一個微服務端點，透過 entry point 的 map 確認是否曾經加載過，當曾經加載過特定版本的 module 之後，就不會重複加載，並且載入同一包被快取的 JavaScript 也可以共享記憶體。而這個機制便是 Webpack5 提供的一個打包機制，也是在微前端去解決「版本管理」、「模塊共享」、「記憶體共享」的關鍵機制，這也是為什麼很多人會把這兩個東西劃上等號。

反過來說，其實不使用 MF 也是能夠處理這樣的機制，但這就牽扯微前端的溝通框架，能否進行這樣的溝通和封裝。通常還是蠻仰賴 Bundle Tool 在預處理，否則處理起來實在是相當囉嗦。

你玩過 module federation 嗎？有什麼想法歡迎與我分享喔！

微前端系列（五）

竹子日誌（竹子） — Mon, 06 May 2024 00:39:09 GMT

接著就是以 Component 化的角度來看看微前端的實作方法。

iframe
WebComponent
Frontend Framework Component (react, vue, angular)

iframe

這是最古老最穩定的方法，副作用也是最少的，最不容易發生污染的解決方案。

但這方法的缺點卻也是最多的。

溝通麻煩，需要透過 Dom 取得後由外而內，卻不容易由內而外溝通，跨域時更甚至需要依靠伺服器端來進行溝通。

這方法也同時非常吃資源，它會消耗非常驚人的記憶體和運算資源，沒辦法進行大量掛載。

另外就是 SEO 的扣分，它可能比 CSR 造成的影響更大。

WebComponent

原生的組件化解決方案，對於各種環境與架構相容性較好。

實體生成與註冊不強制順序，更容易額外封裝。

具備 Shadow DOM 功能，可以隔離 document 的作用域。

優點很多，缺點也不少。

對 SSR 不友善，需要搭配 SSI 相關技術。

拓展功能不如框架的 Component 好用，需要基於 DOM 元件的基礎延伸。

Shadow DOM 也是一把雙面刃，徹底隔離也帶來一些麻煩，後面會額外探討。

Frontend Framework Component

使用框架的 Component 可以說是幾乎沒有學習成本，使用最直覺。

資料傳遞可以直接依附框架的機制溝通，處理起來更加容易。

建構時也可以大量縮小程式體積，有效降低總程式碼的大小，盡可能重複利用。

對應的 SSR 方案整合度高，容易被實作。

但對於這種解決方案，也有致命問題。

微前端應用被綁定在特定的框架、版本上，當要升版和整合時很容易因為版本不一致損壞。

因為溝通變得容易，元件和元件在開發上容易不自覺提高耦合度，採用很多不易反查的手法。

使用上會有種犧牲一些微前端的好處來換取架構上與撰寫上的便利，但又有點本末倒置，甚至有種不如別用微前端好的感覺。

微前端系列（四）

竹子日誌（竹子） — Mon, 06 May 2024 00:04:24 GMT

說到微前端執行方式，免不了談談優劣分析。以下針對服務應用端的三種解決方案來討論。

xhr/fetch
module-federation
use micro frontend framework

xhr/fetch javascript file to insert in script tag

說穿了就是直接插入 script tag 把 JavaScript 運行起來，注入 global 之中。或是引用單例註冊對象針對行為、元件、模組、資源來供給註冊。

這種方法可簡單可複雜，好壞上下限非常巨大。

module-federation

使用 webpack 或 vite 提供的 module-federation-plugin 來註冊，它屬於前一種方法的延伸，但提供了完整的解決方案和易懂的操作模式。

但因為吃到了打包體系，webpack 和 vite 並沒有完全通用，進而導致運作會發生異常。採用時必須讓打包工具一致化。

use micro frontend framework (single-spa, qiankun)

這是最省力的解決方案，事實上這也是基於前面兩種所做的更高階的方法，把維護問題交給套件方。

但同時你失去了微調能力，很多時候在微前端實作在乎的並不是單純實作出微前端，而是各種細膩的優化與調控。

微前端系列（七）

竹子日誌（竹子） — Sun, 05 May 2024 23:49:58 GMT

在進入解決方案篇章前，先來說說我身上發生什麼事，為什麼會開始玩微前端？剛開始是進入公司後，CTO 想要推行微前端，我就必須了解這一塊相關知識。雖然一直都知道什麼是微前端，但我還真沒有實際實作過。但也很開心有這樣的機會，我開始碰了這條路。

那可能就有人會好奇，為什麼公司會想要做微前端呢？

第一個原因，公司有多個前端框架同時運行。原本使用 Vue 2.6，但公司其他產品線都使用 React，長遠來說，其實是需要統一使用的技術線來降低維護成本的。但要一口氣重構轉換框架是一件曠時費力，而且成本非常高昂的工作。所以規劃後決定用 Migrate 的方式逐步重構，而這種重構方式，卻沒辦法做到換框架。基於這樣的麻煩背景，微前端就是一個解決方案。

第二個原因，我們很多產品在部分情境是要架在 Local 環境，所以依照需求不同的產品會有不同的功能組態，甚至可能因為很多即時的環境條件改變組態，如果全然依賴前端的 .env 作為判斷會需要重新打包，也沒辦法節約環境上基本的打包大小，甚至不容易管理落地核心的產品。

第三個原因，上頭希望能將產品打造成一個可擴充可延展的產品，希望能給第三方去追加功能。正因如此擴充性能是需要可以在客戶環境被動態掛載的，所以需要微前端這種極其動態自由的功能。

或許有人覺得這些原因都不足夠說服他使用微前端，但我就是接下這份工作了，也開始弄了。

微前端系列（六）

竹子日誌（竹子） — Sun, 05 May 2024 23:48:45 GMT

微前端面臨的議題

當要採用一個技術前，第一步肯定是要做充分的資料收集與測試。我剛接手這個需求時，我第一步先把公司前端前手的研究進度重新閱覽一遍，並且嘗試建置 POC 專案，確認技術理解。我整理許多要面對的問題點，但說真的…資源少的可憐，理論與概念相當多，但真的有更實務的實作分析資源尤其少。

應用與應用間的溝通
模組共用問題
全域單例狀態管理
樣式管理問題
CI/CD

這是我大致歸納的幾個核心問題，我逐一說明這些問題究竟出了什麼狀況。

應用與應用間的溝通

當你把前端拆成不同的 bundle 這件事，同時也代表你就無法使用你平常習慣的「import module」，跨應用模組間的溝通就形成問題。

那微前端可以有哪些相互溝通的機制呢？如果不採用 iframe 為前提，其實 Web Site 的 global 是相同的，所以你操作的所有的記憶體位置也是共享的。這樣思考下來，似乎簡單不少，但全部的東西往 window 丟，似乎也不是什麼好作法。

模組共用問題

在開發程式時，我們工程時都知道要去「共用程式碼」，透過模組共用來達到降低整體的程式大小，減少寫重複的程式碼。

然而在微前端開發時，因為模組被切開了，你無法確保你所引用的套件能夠被共用。當然大可全部採用 AMD 打包模式將模組注入在 global，但會另外衍生作用域和版本管理的潛在議題。注入的時機點也成了另一個問題，因為初始化要是舊加載全部的 package 就有點多餘，所以要等「需要時」才加載。

全域單例狀態管理

所謂全域單例狀態就比如 history, i18n… 等等均是，這些資訊是必須統一並同步的，不會有特定應用單獨改變。最容易出問題的就是 history router，目前大多路由工具都自成狀態管理機，但卻不具備面向微前端應用場景的處理。如何管理、通知、同步這些狀態成為微前端的難題之一。

樣式管理問題

CSS 樣式本身是全域，本身並沒有 scope 概念，經常會到處污染。當微前端被載入時，如果還注入 style 到 head 就可能有污染的危險，如何管理這些一不小心就血流成河的樣式成為一個複雜的工程。

CI/CD

微前端核心目的就是為了達到分散管理，讓每個應用與應用之間解耦。如何在 CI/CD 做好宣告與用和自動化版本管理成了一項繁雜的工程，要處理的基礎架構從打包到伺服器上跑的部署腳本都習習相關。

微前端真的這麼不堪嗎？

其實我覺得微前端確實很多問題，但其實都可以一個個問題各個擊破，選好方案，做好取捨，就可以有效管理。

工程師會不會被 No Code工具或 AI 取代？

竹子日誌（竹子） — Sat, 04 May 2024 13:04:57 GMT

這是一個前陣子很紅，但有點過時的問題。但最近發現又有點像月經文，好幾次都有人提出來問，不免又在意起來。

原問題如下：

目前市場上有：Gdaddy, Wix, Shopify等很多版型網站，都可以自行購買域名串接，bk, bt,banner 那些位置動畫都可以讓美編自己改，網站也會針對PC, pad ,mobile等不同端用戶自動調整UI介面，收費也不貴，等於老闆只要請個會套版修圖的美編即可。

那為什麼老闆還要請前端？

這問題看似跟 AI 扯不上關聯，但我覺得也有關係，一樣可以回到一樣的問題，「前端會不會被取代」。

坦白講，這個情境只能用在「官網」或是商業邏輯單純的網站，沒有複雜的資料互動，沒有絢麗的動畫效果，沒有客製化的使用者體驗規劃。所以我認同，這種簡單的網站根本不需要前端。

但如果你要極端優化使用者體驗，要處理很複雜的商業邏輯，甚至是功能性非常特殊的網站，恐怕 No Code 工具是滿足不了的。

舉幾個例子，這種工具做得了一個繪圖編輯器？這種工具做得了一個 ERP 系統？這種工具做得了一個聊天軟體？這工具做得了一個交易所？

很顯然答案很明顯。

你可能心想，啊這些網站那麼複雜，有幾個前端工程師信心滿滿說我做得出來？很明顯，它需要很多專業人員協作完成，也需要一定程度的專業知識支撐。

可想而知，最慘的就是底層的工程師，隨時可能被這些 No Code 工具和AI淘汰⋯⋯

微前端系列（三）

竹子日誌（竹子） — Sat, 04 May 2024 04:31:25 GMT

要實施微前端有很多解決方案，目前有幾種主流的方法大致上會有幾種。

以 Application 層級來說

xhr/fetch javascript file to insert in script tag
module-federation
use micro frontend framework (single-spa, qiankun)

以 Component 層級來說

iframe
WebComponent
Frontend Framework Component (react, vue, angular)

當然也不止我提到這幾種，但目前看到各種實作我認為相對常見的幾個方式了。你採用過哪些方法來實作呢？

物件導向只是一種設計模式的表現方式

竹子日誌（竹子） — Fri, 03 May 2024 00:32:51 GMT

身為前端工程師的我，我在職涯求職過程中許多面試官都會問我「Design pattern」，但奇怪的是前端圈並不流行使用 class 這樣的語法，我常常感到困惑⋯⋯

「真的有需要學習 Design pattern 嗎？」

隨著學習的道路，我依然技能樹是純純的前端工程師，但在學習過程中我逐漸體會到「何謂 Design pattern？」。原來設計模式並非是網路上看到的那些範例，而是一種程式碼使用的「精神」，並不限制於「物件導向」這樣的寫法。

隨著 React hook 和 Vue composition 的流行，前端逐漸開始走向 functional programming 的概念，這是和物件導向皆然不同的理念。我逐漸發現有很多設計方式是傳統物件導向設計模式沒有的設計，最經典的大概就是「Curry」，這種模式是物件不需要的模式。

但其實這樣說又有點武斷了，因為其實只是不同的設計模式產生的混合變體。我也逐漸發現太受到「程式碼的形狀」來理解設計模式，開始知道要學習的「精髓」在那裡了⋯⋯

你有學過 Design Pattern 嗎？如果不使用 class，依然會是你認知的設計模式嗎？

微前端系列（二）

竹子日誌（竹子） — Thu, 02 May 2024 23:59:47 GMT

微前端要解決什麼問題？

會出現一種架構，代表背後就有一個要解決的問題。通常有以下幾種問題時，都可以考量導入微前端來解決當前架構問題。

既然產生這種架構必然會產生一些好處，也相對帶來一些壞處，做個微前端的優劣分析。

首先是好處：

所有架構各自為政，也可以輕易插拔這些服務元件，首先是解耦。就算特定應用有破壞性損壞，也可以大幅降低對整個應用產生的影響，最壞的情況就是一個微應用為單位崩潰，而不會導致整個應用架構崩潰。
再來就是應付大型團隊可以很好的去拆分職責，每個拆出去的 Repository 都可以獨立運行，選用自己想要的技術，並且各自為政不影響運行。
因為是單一功能部署，所以 CI/CD 的運行更快完成。
因為每一個功能都是基於被拆分的專案去開發，所以沒有超大型專案的維護壓力，只有各自小專案的規模。這樣開發節奏更快速，也可以承受更多工程師同時進行功能開發。

當然，有好處就有壞處：

載入的 Application 因為都拆分好幾塊，所以基本的 Bundle Size 比較大
功能操作限制多，不能操作 Browser Single State，否則狀態會同步異常，所以需要比較完善的團隊規範
使用的函式庫或框架限制多，不能任意選用套件
跨微前端溝通方式複雜且麻煩

那到底什麼樣的情境會需要使用微前端呢？

當單一前端專案越來越巨大，已經影響編譯時間與開發效率。
單一前端應用需要跨部門多個工程師共同維護，同一個產品已經很進行版本管理。
單一產品需要整合多種框架或多種版本共存迭代。
有大量需要多專案共用的業務與介面需要外放提供時。

微前端系列（一）

竹子日誌（竹子） — Thu, 02 May 2024 00:40:54 GMT

最近要來寫微前端系列篇章

或許你聽過或是沒聽過以下詞彙，「微前端」、「微應用」、「前端微服務」。這些都是相同的東西，後面的文章我都會用「微前端」來稱呼。

你可能聽過微服務，這是已經行之有年的軟體開發架構風格，可以讓單一應用程式有自己的開發、部署、執行的生命週期，透過網路通道來達到相互溝通的能力。微服務是一個很好的切分單位，可以更容易讓更大的團隊溝組織通協作開發。

那什麼是微前端呢？

微前端就是把微服務的架構概念套來前端，將前端需要的模組分散在不同的服務上提供，而不是將所有資訊塞在同一個單體式架構中。所以可能在同一個前端應用程式中，有好幾個儲存庫與分出數個團隊一同開發與維護，並每個團隊都各自管理自己的部分，透過架構去組裝整個應用程式。

比較容易被誤會的是把服務切分這件事包成「npm package」並不算微前端，因為不滿足「獨立開發與部署」這個條件，依然仰賴架構核心去打包與部署。

你有玩過微前端嗎？可以一同交流經驗喔！

Ref: https://github.com/eastmoon/research-microfontend

微前端

竹子日誌（竹子） — Wed, 01 May 2024 23:55:23 GMT

或許你聽過或是沒聽過以下詞彙，「微前端」、「微應用」、「前端微服務」。這些都是相同的東西，後面的文章我都會用「微前端」來稱呼。

那微前端呢？

微前端就是把微服務的架構概念套來前端，將前端需要的模組分散在不同的服務上提供，而不是將所有資訊塞在同一個單體式架構中。所以可能在同一個前端應用程式中，有好幾個人一同開發與維護，並每個人都各自管理自己的部分，透過架構去讓程式溝通。

微前端要解決什麼問題？

會出現一種架構，代表背後就有一個要解決的問題。通常有以下幾種問題時，都可以考量導入微前端來解決當前架構問題。

當單一前端專案越來越巨大，已經影響編譯時間與開發效率。
單一前端應用需要跨部門多個工程師共同維護，同一個產品已經很進行版本管理。
單一產品需要整合多種框架或多種版本共存迭代。
有大量需要多專案共用的業務與介面需要外放提供時。

微前端的優劣分析

既然產生這種架構必然會產生一些好處，也相對帶來一些壞處。

首先是好處：

所有架構各自為政，也可以輕易插拔這些服務元件，首先是解耦。就算特定應用有破壞性損壞，也可以大幅降低對整個應用產生的影響，最壞的情況就是一個微應用為單位崩潰，而不會導致整個應用架構崩潰。
再來就是應付大型團隊可以很好的去拆分職責，每個拆出去的 Repository 都可以獨立運行，選用自己想要的技術，並且各自為政不影響運行。
因為是單一功能部署，所以 CI/CD 的運行更快完成。
因為每一個功能都是基於被拆分的專案去開發，所以沒有超大型專案的維護壓力，只有各自小專案的規模。這樣開發節奏更快速，也可以承受更多工程師同時進行功能開發。

當然，有好處就有壞處：

載入的 Application 因為都拆分好幾塊，所以基本的 Bundle Size 比較大
功能操作限制多，不能操作 Browser Single State，否則狀態會同步異常，所以需要比較完善的團隊規範
使用的函式庫或框架限制多，不能任意選用套件
跨微前端溝通方式複雜且麻煩

常見的為前端解決方案

要實施微前端有很多解決方案，目前有幾種主流的方法。

iframe
Frontend Framework Component
WebComponent

後面會針對這些方法做討論。

我怎麼看微前端？

剛開始我接手時，其實根本沒有成功建立任何的微前端，我是從頭建制這整個架構。而建構微前端的過程也是經歷許多坡折，但既然面對了就必須做好，作為公司主推的一項主軸技術，我就有責任把它處理好。

後面我會把這來龍去脈和心酸血淚逐條逐項分享，讓想嘗試這架構的你可以少走點彎路，其中也包含很多就算不是實作微前端也會遇到的前端基礎建設問題，讓我們各個擊破吧。

(二) 前期資訊查找與準備

當要採用一個技術前，第一步肯定是要做充分的資料收集與測試。我剛接手這個需求時，我第一步先把公司前端前手的研究進度重新閱覽一遍，並且嘗試建置 POC 專案，確認技術理解。

微前端第一個麻煩點，那就是溝通。

那微前端可以有哪些相互溝通的機制呢？如果不採用 iframe 為前提，其實 Web Site 所有的

依賴循環：重談 circular dependency 與打包的關係

竹子日誌（竹子） — Tue, 30 Apr 2024 00:12:57 GMT

可能寫前端寫了一陣子開始就慢慢會感受到，模組和模組都是互相 import 來 import 去，可能用的很開心時，在自己一個不注意就發生「circular dependency」

可能這議題在前端不會是很嚴重的問題。資料依賴循環確實會是個問題，它會造成程式本身的崩潰，因為這樣存在強烈的「不合理性」。但模組循環卻是經常發生，而且本身可能是存在合理性的。或許有些人無法理喻為什麼發生模組循環卻不會有任何問題？其實緣由是 JavaScript 在經過打包後的 ESModule 運行下，會先塊狀每個模組，但卻不會直接運行。透過打包和運行引擎會講模組綑綁在一塊，此時都已經加載完成，只要不發生「資料循環」，自然就不會觸發循環現象。

那前端是否就可以忽略這件事？關於這件事就見仁見智，既然不會發生問題，許多人選擇視而不見，以「方便就好」的心態在維護專案。但也不是完全不會有問題，當你完全不經過打包的方式把程式運行起來時就有可能會出問題，因為 JavaScript 的運行本身不允許發生循環引用的。

我個人對於這問題在意的並不是「會不會動」這個問題，而是認為對於程式的架構與邏輯的依賴關係不清楚才有這樣的現象。任何 Domain 都應該有優先次序與層次高低，邏輯切分應該是更明確並有樹狀關係，而不存在環狀關係。

你在寫程式的時候回去在意是否發生模組依賴循環嗎？

當想起過去

竹子日誌（竹子） — Sun, 28 Apr 2024 22:55:47 GMT

多次夢裡回憶起過去，二十多歲時工作種種回憶，真的是年輕時各種⋯⋯

入行軟體業是我人生轉折，我現在有價值的生命是這幾年努力出來的，我很感謝當時的自己讓我走到現在。我現在珍惜眼前的一切，我很重視，我不會輕易放手。

前幾天社群聊著轉職前過去種種，不知不覺感到內心波瀾起伏，勾起每一段時期的回憶⋯⋯真的有種黯然的惆悵感。

祝福還在浮浮沉沉的朋友，相信自己能熬過去，好好沈澱自己的情緒、技術、人脈，會越來越好的。

急著有成果是不會有成果的

竹子日誌（竹子） — Sat, 27 Apr 2024 05:21:10 GMT

Side project 對我來講不是一個為求職而準備的東西，所以我不會因為我想找工作才開始準備。

很多人都覺得 side project 是一個「我為了求職要準備的專案」，或是「我希望可以創造商業潛力」的專案。但很實際的是，大部分這些都不是吸引我做 side project 的理由。我要的是，我能夠在這個專案中玩到、學到、體驗到什麼。

我會踏實做好我覺得有價值的事情，一點一滴把每個細節都做好。

總會有地方搞得很複雜

竹子日誌（竹子） — Thu, 25 Apr 2024 00:43:33 GMT

我向來設計的風格是，我寧可底層邏輯很複雜，我也要業務層看起來簡潔好用。我不願意為了底層少了幾行讓業務層看起來更加複雜或難懂，業務層越好用越好。原因很簡單，因為業務層經常被改動，所以更要簡潔。

當今所有函式庫的原始碼大概 80% 都在服務 API 介面，核心功能其實佔比極少，為得就是讓使用者能舒服的使用。我不能認同「為了讓元件更好維護，業務層出現幾行多餘的宣告是必要之惡」，難道包成開源套件才有資格複雜嗎？

如果大家有想法可以跟我分享唷！

奇葩的求才思維系列（三）：找便宜的潛力股自己訓練

竹子日誌（竹子） — Mon, 22 Apr 2024 00:49:01 GMT

有些公司真的沒那麼多預算請 Senior ，我可以諒解，畢竟不是每間公司都有這麼好的盈利。

客戶：「能力到位的工程師太貴了」

我：「我會用你的預算找到能力最划算的人才」

客戶：「那能不能找便宜一點的潛力股自己訓練？」

我：「可以啊，我幫你找潛力股，但是誰要教？」

客戶：「你啊！」

我：（你在找我碴嗎⋯⋯）

我：「教學教材製作可能會花過多的成本，我可以幫你規劃要教學的 roadmap 給你家的 XXX，讓他比較有脈絡能帶。」

客戶：「是喔⋯⋯那還是算了。」

我：（要出動自己人力就不願意了⋯你知道教學是多昂貴的事嗎？）

不要覺得人自己教就比較便宜，自己教才是最貴最貴的！

奇葩的求才思維系列（二）：徵才預算「越便宜越好」

竹子日誌（竹子） — Mon, 22 Apr 2024 00:42:20 GMT

前些陣子幫客戶公司招人，先幫他把 104 的文案修一修，不要找來都是一些技術方向不符合公司現況的人，所以要寫一份新文案。

首先我要確定客戶預算：

我：「所以你這次徵才預算多少？」

客戶：「越便宜越好。」

我：「痾⋯所以你最貴願意用多少請人？如果能力很 OK，年薪 200 可以嗎？」

客戶：「我沒那麼多錢，最多月薪 OO 」

我：（是不會早講喔⋯⋯）

奇葩的求才思維系列（一）：沒預算，卻要找主管職

竹子日誌（竹子） — Mon, 22 Apr 2024 00:36:08 GMT

又要提一下奇葩的顧問經驗了。

前些陣子幫客戶公司招人，我幫他審核 104 上一堆履歷海，我正用飛快的速度翻閱履歷。

我：「這個人我覺得不錯，你要面試嗎？」

客戶：「喔喔，這個是主管職欸。」

我：「主管職有什麼問題？」

客戶：「沒有預算請啊！」

我：（那你把這職缺掛在 104 上幹嘛⋯⋯）

對不起，我就是資方打手

竹子日誌（竹子） — Sun, 21 Apr 2024 03:04:49 GMT

很多次在跟朋友聊天時，他們都覺得我喜歡站在老闆那邊，覺得我老是替老闆們找各種理由。

其實我應該講我比較反骨一點，舉個例子，我看到別人都在講「遠端好棒棒」，我自己雖然也覺得好棒棒，但我就是想噴一下。然後很有趣的是，就超多人想來護航遠端，其實我本身也沒特別反對，但就很欠扁想反一下。

我經常回去思考，反對的那一方是什麼心情，為什麼要反對，我不會否認他的觀點，因為他的世界觀裡面確實是這樣。其實我討厭的是極端站到某邊跟我吵，覺得都是我的問題，對啦XD確實是我的問題，我不該跟你吵。

我是故意站到另一邊去看風景的

一樣舉遠端這個例子，通常能不能遠端的關鍵在高階主管和老闆，所以我只是在想，他們在遠端這件事遇到了什麼問題？為什麼都不願意推行時下流行的遠端呢？其實原因和問題不重要，我模擬了他們可能的想法，我也問了很多主管職和老闆，給我了蠻多想法，然後我過濾表一些「慣老闆」和「慣主管」發言後整理了一篇文展，故意使用犀利的字眼產生這樣的結果。很好玩的是引發了不少人來批評我的觀點，我其實超懂他們心裡想什麼，因為我真正的個人立場跟他們一樣，只是我站到另一個世界看到那個世界的風景。

包含各種勞基法議題、社會福利議題、公司文化議題⋯等等，我有很多想法想要在這跟廣大脆友交流。但我用居中立場其實超沒有討論度，大概會被視為「廢文」。但稍微煽動情緒就能引發很大的交流，觸及成倍擴張。我也必須承認這不是什麼好手段，我可能以後要慢慢收斂⋯⋯應該了啦XD

「如果我是企業管理層，我會怎麼想？」

當我看到這些議題我總是第一個想：「如果我是企業管理層，我對這件事有什麼想法？」

我用這樣觀點出發跟身邊好友討論，立馬引發熱議，他們開始為他們的想法護航，提出各種反對意見。大概因為我也是打工仔，身邊朋友也是打工仔多，我提出資方立場時，他們覺得我的想法太偏激。不開玩笑，我過去到現在已經不少人罵過我「資方打手」，覺得為什麼麼我總是要幫慣老闆講話？大概他們根本聽不懂我的言下之意，更聽不出我的目的，覺得我的立場非常危險。觀點立場跟實際立場絕對是可以分離的，起碼我是做到了，完全讓別人可以覺得我的立場是另一邊的。

沒關係，我就是慣老闆潛力股。

面試問什麼？（三）

竹子日誌（竹子） — Sun, 21 Apr 2024 01:52:38 GMT

「公司使用哪些技術線？」

這題就是做我個人的最終篩選，其實能曬出蠻多東西的，結果上來說會很有趣。

大部分都會很籠統跟你講什麼 Vue, React 之類，但魔鬼藏在細節，如果你去追問可以發現很多東西講的不是那麼清楚。以下任何問題只要面試的用人主管任何一句「不知道」或「不清楚」就很嚴重了。或是跟你說「忘記了」、「不是我在處理」你要提高警覺去追問。

其中最常見，談到「MVC」、「jQuery」都是危險訊號。現在不使用框架要找前端工程師，這都很高機率前後端不分離，最怕一隻檔案看到 SQL Query 和 HTML，整個結構真的很噁心。

再來可以問採用什麼 UI Framework？如果回答你手刻，你就必須追問管理方式。有沒有使用 storybook？採用什麼方式對 component 測試？有沒有 API Documentation？如果都沒有肯定是混亂而已⋯⋯那還不如用 headless ui ⋯⋯

鑑別團隊架構能力也可以問打包方式，有沒有拆分功能型 package？用什麼打包？版本控管方式？

鑑別團隊流程能力可以問 CI/CD 流程，CI 什麼時候觸發？檢查哪些項目？CD 什麼時候觸發？有哪些流程？

鑑別團隊規範也可以問蠻多的。ESLint 會採用哪些 plugin？團隊規範會使用 Linter rule 來規範還是只依賴文件？PR和 Releases 流程？有執行 Code Review 嗎？通常 Code Review 看什麼？如果很趕，Code Review 會有什麼調整？

其實隨便一說就很多，通常你把自己對技術的渴望問出來就會問出很多。如果對方剛好是很優秀的公司，對於你問的問題深度能深深感受到你的程度，也可以變成很棒的加分項目。

面試問什麼？（二）

竹子日誌（竹子） — Sun, 21 Apr 2024 01:52:27 GMT

來到第二集啦！

我會從我是一個前端工程師的觀點來說我會問什麼。

「請問你們的開發流程？個部門是如何互相溝通？」

這件事就是在問敏捷開發與跨部門的協作，這個就可以問出「超級多」東西。

大部分公司會很流水帳交代「PM 會先規劃，然後設計會畫 UI，前端先刻畫面，然後後端開發 API ，完成後會給前端串接，然後 QA 會驗收」

其實這就是講了跟沒講一樣，根本沒交代細節。難道PM 完成需求不需要跟工程師溝通？難道前端永遠要等後端開發完成才能串？QA 只有驗收成果的功能？還很多細節，這個以後我再分享現在工作的開發流程，你會知道很多公司多麼隕石。

PM：用什麼工具管專案、怎麼寫 Spec

首先是關於 PM 部分：

是用什麼工具去管理專案？

PM 會交代要做的工作。（都不需要 Task board ?????）

現在那麼多專案管理軟體，jira, trello, clickup等等，不要再像原始人一樣用嘴巴派任務。

使用軟體什麼去撰寫 Spec?

會給 UI 和文件檔。（言下之意就是給你一個寫不清楚的 Word 和 UI 稿看圖說故事？）

UI：用哪一套軟體、有沒有 Design System

再來看 UI 的問題：

你們使用那一套 UI 軟體？

我內心能接受的大概只有 Figma, Sketch, XD 這三個答案，其他的我幾乎無法接受。我要是聽到 PS, AI，我白眼都翻到後腦勺了。

有沒有在使用 Design System？有沒有在使用 Design Token？

了解設計團隊的專業水平，是不是真的懂什麼是「UI」，還是說只是一個畫圖仔。雖然這樣講很嗆，但業界就是充斥這種現象。

平常設計師會經常支援做圖做簡報嗎？

UI 是一門專業，平面是一門專業，兩個繳在一起只會更亂。什麼？你說小公司沒辦法請專職 UI？那我會更傾向聽到 UI 兼 PM ，因為他要知道自己在畫什麼，不是找一個「畫圖的」來兼差。

後端：API 規格文件長什麼樣

再來是後端：

使用什麼工具來了解API 規格？

最雷的大概是「打了就知道」，那種憑感覺開發真的很糟糕⋯⋯最差最差也要有 swagger, postman json，但也沒有很理想就是了。

以我來說最理想要有文件，文件必須登載以下：URL, Method, Parameter, Response DTO Scheme, Error Type。最討厭看到貼了一個 Json example 跟我說這是他的 response ，連type, enum, 什麼都沒交代。

QA：用什麼管 Issue

最後是QA：

用什麼去管理 Issues?

最少要有使用專案管理功能，最差用個 GitHub or Gitlab 的Issue board。通常 issue 卡片要交代 Bug ，通常要內容、圖片、復現步驟。絕對不是給你一份 Excel 跟你說這個是 Bug 清單。

一般溝通：從工具就看得出專業度

一般溝通：

通常這一行主流還是依賴使用 slack 這類的團隊管理工具，對於各個平台的擴充性好，能串接 CI/CD, CLI 各類型問題的工具為首選。有的公司也會開發內部溝通軟體。但最糟糕的是用 Line 之類的，那種使用跟你生活綁在一起的軟體，只會讓你生活混亂。

其實從溝通工具就可以了解到團隊很多基本的狀況，如果連工具挑選都很隨便，代表專業度不足，很容易開發到變成隕石。

面試問什麼？（一）

竹子日誌（竹子） — Fri, 19 Apr 2024 05:22:29 GMT

很多時候面試差不多的時候，面試官都會問「你有什麼問題想問的？」，常常不知道問什麼嗎？我其實也不知道要問什麼，但我經常會問幾個問題，然後我就有很奇妙的答案。

這篇可能很長，我覺得我分幾天連載好了⋯⋯

面試是一個雙向的過程，看起來是公司在面試你，但你當然可以反過來用一些技巧去面試這個主管和這個公司。大家都一樣，只是想找一個待得開心的公司，你當然要好好審核這個公司和團隊。

第一篇來熱身一下，從我是前端工程師的立場來看。

「最近一個月主管大多都是幾點離開辦公室？」

這題主要是問「加班文化」，大概這麼問，敏感一點的大概也知道你想問會不會加班，也會開始避重就輕的回答你，但這樣你很難辨別到底會不會加班。

但基本上可以先看幾種回答：

我們團隊很扁平，沒有主管這個位置。

不管如何，公司不可能沒有管理層，沒有管理層的公司大多會是一盤散沙，除非是草創公司，直接對老闆。但沒有任何技術管理層是一件非常可怕的事，這個以後我再分享。不用說，大地雷！

不太一定，有時候早有時候晚

大概率就是「沒聽懂你在問什麼」，但意思就是會加班，可能不會常態加班，但你要有意識這件事。

主管大多待蠻晚的，但其他人都準時走

他知道你在問加班，想避重就輕。如果你有一個「很愛加班的主管」，那大概率會養出「愛加班的團隊」。

主管都準時走，要去接小孩，做不完可能會在家做

這種回答我很喜歡，代表公司是很有彈性的公司，主管也不會悶在公司加班製造加班文化。其實大部分的軟體公司多少會遇到上線前加班，但怎麼看待很重要。

那你可能會問，萬一主管不加班，其他人加班呢？我覺得真的這樣他們死都不會告訴你他們有這個現象，這時你可以先問下班時間，在面試公司附近待到下班時間，然後看燈是不是還亮著。但也許是別的部門？不重要，你要看的是文化，隔壁組的加班文化也會傳染啊！

交流活動

竹子日誌（竹子） — Fri, 19 Apr 2024 00:41:22 GMT

前週我辦了社群活動，大概有 30多位來賓參與，也是我多次辦活動再次刷新最大人數。隨著人數增加，確實活動難度不斷增加，我也努力控場，希望讓氛圍變得更好。我辦的並不是像技術年會那種演講風格，而是更像「商務場合」那種，交流知識，為自己打廣告。

不過我特別想提的是，在這種場合讀空氣很重要。交流本身的意義就是相互交換資訊，絕對不是單向的。

一種情況是顧著講自身的情況，忘記要留給其他人發表的空間。

一種情況是只聽沒有回饋，會有種對空氣講話的感覺，扔東西出去沒有回應。

也有要種情況是上述兩種人在一起，那好像沒問題？但我覺得也可惜了「交流」這件事，既然叫做交流就是要有來往。

如果下次有活動我再丟上來，希望大家不要關在家裡，多出來跟這個社會產生一點連結。這世代需要點溫度。

關於最近的前端求職市場

竹子日誌（竹子） — Thu, 18 Apr 2024 00:42:36 GMT

這兩天看到前端求職市場的情況，發現現在大約最甜蜜的等級是 80～120 這個區間，機會特別多。

低於這個數字想當然是超級競爭的 junior 市場，而這範圍是機會多但相對競爭少 mid level 的市場，而在更上面是貴但是機會不見得多的 senior 市場。

最近帶出來的學生剛進入這個區間的底標，很明顯感受到他近期的面試機會多出很多。其實在 middle 的市場裡面，你不需要很強的演算法，也不需要很強的架構力，更不需要很強的產業經驗，你只需要紮實的基礎知識和一般般的 coding 能力就很吃得開。

但古怪的是，過了 120 之後，到200前。現在大量在這區間幾乎是菠菜業，可以說是求職荒漠⋯⋯近期身邊朋友聊到很多都是卡 200 上不去，就卡在150 之前。

以上近僅資訊分享，如果跟你的宇宙不一樣純屬巧合。

遠端工作一體兩面

竹子日誌（竹子） — Mon, 15 Apr 2024 23:57:36 GMT

上一篇說了一些遠端的缺點，意外引起很大的迴響，有認同的，也有來爭一口氣的。本來就有一些案例不符合我敘述的情境，討論分享我覺得很棒，刻意爭對與錯我也只能歎一口氣。

我曾經一年的遠端工作，其實我講的問題都是我真實面對的，問題勢必都能克服。我一直有管理遠端團隊，處理過各種遠端團隊的問題，但必須說制度和管理方式可以降低遠端團隊的問題，不代表完全不存在。這絕對是可以被比較出來的，特別是混合型的上班模式時更加明顯。

許多人也很極力為「全遠端工作的價值」護航，我看到很多很優秀且成熟的回應，不乏也有只站在「自己爽」的立場，卻絲毫沒有去站在團隊、管理、營運角度去看待這件事。很多事情面向看自己得到什麼和失去什麼很容易，但站到另外一個立場並不是容易事，我用鋒利的語氣與直白的事實點出大家必須面對的。

遠端當然爽，我不想嗎？

每天眼睛張開拉電腦到面前開始工作。
吃飯吃家裡不用人龍排隊買飯。
節省每日1～4小時的通勤時間。
享受不被打斷的工作節奏。
出遠門不會因為工作時間而受限制，在外面可以同時玩和同時工作。
使用個人最習慣最頂級的辦公設備
可以滿足照顧家人的需求

但對於管理層和老闆來說實在沒有足具說服力的好處，有好處，但不明顯。除非商業模式和營運模式的條件一定要仰賴這種遠端團隊去運行，那我覺得非常合理，普通以「資訊軟體業」來說，遠端可能還是要多加評估。

一頭熱的提倡遠端，那叫跟風。

我認為應該先採取混合遠端，發現問題，修正制度，逐漸轉為合適於遠端的運行方式，讓這兩個手段在需要時都可以順利轉換。遠端和辦公室是兩個不同節奏和文化的管理模式，需要花很多心力去建立。

你問我，支持全遠端嗎？

我當然支持啊！有哪個社畜不想要享受這些好處呢？但你不去正視這些管理和營運問題、歷練這些東西，你永遠在遠端的粉紅泡泡之中。

或你會說管理和營運不是我的事，那個是主管和老闆的問題，會有這種想法的人⋯⋯唉唉唉⋯⋯真是怠惰啊⋯⋯

ESModule 的載入特性

竹子日誌（竹子） — Thu, 11 Apr 2024 00:45:17 GMT

我們前端每天都在寫 ESModule，但你真的懂它是怎麼運行的嗎？這篇談它的載入特性。

不要再每天想著全遠端了！

竹子日誌（竹子） — Wed, 10 Apr 2024 00:45:16 GMT

實在看到太多人每天都在追求全遠端了！

我曾經待過全遠端的工作一年，那年的工作經驗讓我確定這不是我要的。

全遠端意味著什麼？

先思考對公司的意義，不外乎是「節省辦公室開銷」、「應徵跨地區人才」，似乎也沒那麼多明顯的好處。但缺點卻很多，包含著：溝通成本上升、人員主動性意願下降、時區管理問題⋯⋯

但對於求職者來說，我不說優點了，直觀談缺點。

你和同事溝通難度會上升，要找一個同事他未必會積極讓你找到人，很可能會訊息後等1～2小時才理你。
你理解需求的難度會上升，你對於每個需求會費更多心神了解這個需求到底想幹嘛。
如果公司不是「全公司全部門」都全遠端，那你的升遷機會和加薪機會肯定會比進公司的人還要低。
對於 junior 來說，資深同事會主動教導你的機率大幅降低。
對管理者來說，團隊主動提出意見的頻率起嗎下降30%以上。（這是保守估計）
對管理者來說，有緊急事件聯絡到相關人員難度會上升。

對於比較資淺的，傷的是你賺到團隊溝通和前輩指導的機會。

對於比較資深的，傷的是你的升遷發展機會。

對於管理者來說，你的管理難度不但上升，底下更不太可能對你「盡心盡力」。

對於老闆，你省了辦公室和人事成本，賠的是團隊向心力與產出。

如果不是家累或硬需求，如果你沒打算當核心事業，如果不是你連出門都有困難。我誠心建議你選擇要進公司的工作機會。我個人覺得，最甜蜜的是混合遠端。不但可以享受部分遠端的好處，也可以降低遠端的傷害，那我覺得才是好的！

奇妙的顧問經歷

竹子日誌（竹子） — Tue, 02 Apr 2024 00:37:49 GMT

我其實長時間幫某公司做顧問，雖然不能張揚說是哪間，但真的有很多感嘆。

剛開始只是單純想幫忙在這個公司的朋友，也想體驗各種管理嘗試，一路幫忙很長的一段時間，但最近真蠻心累。老闆的心態經常是「我要用新人的預算請到資深的技術」，也經常要「要快、要好、不要重工」，但現實就是沒那麼好的事情。

我可以理解中堅主管很可憐，既沒有資源也沒有權利，都被老闆把持。但幸運的是「老闆願意請主管」，這是我覺得不幸中的大幸。最糟糕的是老闆是外行人，也沒有任何技術管理層，卻搞技術生意，依靠拿著基層薪資的工程師扛著所有技術難題。

我因為這間公司看了數百份履歷，體驗到許多 HR 內心各種難題，這種奇妙的經驗讓我深刻感受這個市場的現實。大部分的資方只會把員工視為成本，他們會前方百計去提高企業權益，想盡辦法在合法範圍降低勞方產生的「成本」。實際作法我也不太想分享，大多吃相都蠻難看的，我只能說勞方自立自強吧⋯⋯

當然不能都說資方壞話，勞方也不少舉著勞基法的護盾，每天想盡辦法壓榨出所有的福利用好用滿，第一天就安靜離職的真的不少。有的人根本沒有經驗和能力，也沒有想要為企業盈利，用自己的個人觀點對管理層指指點點。

不過這大概就是一種體悟吧～透過這件事讓整件事情變得有趣。

瀏覽器快取

竹子日誌（竹子） — Mon, 18 Mar 2024 00:33:44 GMT

最近實作多站點登入和SSO登入，真的是坑山坑谷⋯⋯我們家前後端和PM 大家踩這個坑真的踩的不要不要的。瀏覽器快取並不是一個只有工程師要知道的知識，因為它非常深度的影響了系統設計的實現，所以有什麼知道有什麼快取機制非常重要。

首先對於快取機制有幾個關鍵的項目，分別是 cookie, sessionStorage, localStorage。

首先是前端目前最主流的 localStorage，它可以直接保留在瀏覽器上，只要使用者不操作「清除快取」這個功能，或是關閉瀏覽器背景運行，基本上會永遠保存。

再來是 sessionStorage ，如果不重新開出一個全新分頁，包含重新整理、複製分頁，都會保留儲存的資訊。

最後是讓人又愛又恨的餅乾🍪⋯⋯欸⋯⋯我說的是 cookie。它能夠隨著每一次跟後端的請求把即時的 client 資訊帶去後端，可以讓後端辨別是哪一個使用者。缺點也很明顯，就是「不安全」，很容易變成攻擊破口。通常習慣上會讓 cookie 作為純給予「後端操作」，不要把 cookie 當作是前後端溝通資料和狀態的手段，瀏覽器逐漸也朝向這個方向去規範使用。

上面聽起來像前端的知識點？

但我必須說，如果 PM 不懂這些應用，那可能很難設計出「多域名的應用程式」。因為跨域後前端程式快取就會消失無法溝通，此時一定要仰賴後端去辨別是哪個 client ，不然無法相互辨別與通訊。不然也得要有「SA」的角色協助需求設計，否則需求只能說充滿理想卻無法被實現。

當然也不是每個團隊都要這麼硬，其實系統複雜度通常是因應需求與規模來決定架構的複雜度，如何更好管理就是不同的議題。但不要設計超出自己能力可以掌控的系統，不然光是維護上的精神耗損就會讓你人仰馬翻。

帶領不同領域的人

竹子日誌（竹子） — Tue, 05 Mar 2024 00:35:01 GMT

最近開始我的 Side Project，我的主題是做一個 UI Framework 。這並不是一件容易的事，不管是在「工程面」或是「設計面」都是門檻相當高的議題，但我覺得是件非常有趣的事。

除了我本來的專常外，我還得帶領多名設計師。起初找了約略7名 UI 設計師，我想從提案開始執行，這階段其實是在測試是否有意願。這時候許多人提出很多質疑，有人覺得不現實、有人覺得目標不明確、有人覺得無法協作。但事實證明，該陣亡的就會陣亡，只是想走馬看花的其實我也沒想要花時間在上面。

隨著我多次強調中心思想，大家慢慢理解我的目標，大家開始做了很多嘗試。我感覺到大家觸及到我的目標，我開始把主導權交付給具備統合能力的人，團隊慢慢開始獨自運轉起來。

我覺得放手交給團隊人員運轉很重要，過多的控制會使人感到疲倦。side project 陣亡率之高也不是什麼奇怪的事，又沒有強制力，初期也沒有成就感。不過我確實學到了很多領導上的經驗值，特別是領導一群比自己還專業的一群人，有很多技巧。

瀏覽器路由

竹子日誌（竹子） — Mon, 19 Feb 2024 00:33:30 GMT

又來到微前端踩坑分享，這次是 browser history router。經過多種方案的路由器方案研究，每一種方案都看似完美，但都會在進入實作時發現新的坑。其實，路由器製作看似很簡單，卻也很複雜，背後運行上有很多想不到的小細節。

路由器的資料流裡面有幾個關鍵的 Action，分別是 history.pushState, history.replaceState, history.forward, history.back。其中除了 push 和 replace 是常見的「靠 JS 主動換頁」外，還有 forward, back, go 三種方法是瀏覽器換頁。製作最麻煩的大概就是「監測換頁」這件事，因為主動換頁是無法單單靠事件來監聽到所有換頁。你可能認為不是有「popstate」這個 event 可以監聽嗎？但事實上它只能監聽 forward, back, go 三種操作，而 pushState, replaceState 的行為是沒辦法監聽的。

我其實很想要重頭刻一個 router library ，但想到背後踩坑和維護成本，不禁想像覺得還是先不要，畢竟每一行程式都是維護成本。加上我花了很多心力研究 open source 的 library 評估其複雜度，包含它的實現原理和實作原理，確保我設計方式不會與其產生衝突。

最後我得出的結論很簡單，就是「整個應用能操作 history 的只能有一個」，其實原理就是，多狀態要相互同步，主狀態只能有一個，這樣才能確保資料流穩定。

其實實作各種微前端開發，我漸漸發現要處理資料流同步都離不開一個道理，就是「單向資料流」。不要依賴任何雙向同步的架構，要讓整體資料流採用單向移動，減少「相似判斷」， isEquel 絕對是超級耗能且不穩定的設計，我非常不推薦這種操作手法。

不知道下次又要踩什麼坑，不過留著給未來的自己煩惱吧。

元件真的別亂自己刻

竹子日誌（竹子） — Thu, 25 Jan 2024 00:41:01 GMT

經歷多份工作，和各個團隊合作，也多次面試時詢問各家公司情況，和驗證各大函式庫，慢慢有一個造元件的思路。

以前能力還不成熟時，經常夢想可以自造元件庫，能夠打造一個好用、多元的UI元件庫。但隨著經驗累積，自己嘗試打造多次元件之後，發現造一個元件庫面臨的問題真的是多如牛毛，還有許多問題得面臨。

光一個 Custom Select，就有八個坑

以前我常常會舉個例子，使用 div 製作一個 Custom Select Component ，會遇到什麼問題呢？

用什麼方式讓選單浮出來？
展開動畫要怎麼做才不會不自然？
內容過多該怎麼顯示？
點擊了空白處要怎麼自動收合？
滾動了外部的滾動吧是否會被跟著移動？
如果元件放置在外部有 overflow 的容器上，該怎麼處理會被切掉的問題？
當下拉選單打開，如何讓報讀器知道下拉選單被打開？
當操作者使用鍵盤時能被操控嗎？

簡單的一個元件就有數不清的細節，如果沒有充足的製作經驗，就會做出很多缺陷的元件。

手刻元件，是在製造高昂的開發成本

我聽過的不少公司都手刻了自己的 UI 元件，也不是基於某個 UI 庫，而是為了自己的樣式與行為手刻。我認為這樣其實會埋下很多問題因子，無形在製造高昂的開發成本。

另一個隱形成本：維護與使用

另外一個自製元件的隱形成本，就是維護和使用。

元件是需要被反覆使用的，如果元件狀態不穩定是很容易發生大範圍問題，需要足夠的單元測試和整合測試維持。
元件製作後是很多互動細節的，需要密切和 UI 設計師協作，這時是需要有 UI Preview 工具，如 storybook 之類的工具來便利於溝通和細節確認。
當元件數量上升，以及不斷有人員流轉，慢慢元件當初設計的資訊就會遺失，也很有可能不斷發生元件重刻的情況。最好有元件文件，標示所有元件的列表，也要知道元件功能上有哪些 API 可以被使用。
元件為了方便給跨 Repo 使用，也為了確定完全與業務邏輯解耦，這時必須把元件整個包成一個 package ，相對需要把所有元件程式打包整合。

或許是因為並不需要每一個細節都做到，但相對也需要規劃設計，並長期把這些基礎建設完成。如果沒有處理這些細節，也是長期積累下技術債，未來終究需要人來償還。

面試都是一種洗禮

竹子日誌（竹子） — Thu, 25 Jan 2024 00:08:02 GMT

我還是定期會去面試，驗證一下自己的能力和市場價值，但我不得不說，還是在各種點吃盡虧。認真講，我是一個基本功不太穩的人，英文不好、演算法不好、CS 知識不足、學歷不亮眼，在許多人眼中並不是一個人才。

我滿鼓勵人可以多多去外面面試，驗證自己的市場價值，一來可以防止自己被 PUA，二來也可以防止自我膨脹，因為市場價格是最殘酷的。他會真實反映你的價格，也會真實去考驗你的面試功底。

雖然不得不說，我很懶惰，我真的不太愛把這些基本功底打好。但近期因為閱讀跟 AST 有關的功能，好幾次被打到，我開始重視這些關於演算法和CS 的基礎。書到用時方恨少，大概就是在講這回事吧？

另外就是經常被問倒的英文。

我必須說自從我成為工程師後，英文能力可以說是飛躍進步非常多，但仍然低於一般人認知的平均水平。我也深知這領域英文的重要性，一次次把這個痛打入內心，一次次讓自己感受英文的重要性。

今天就是一些個人的碎碎念，沒什麼乾貨，不過就是一些心情記事。

軟體開發是難還是簡單？

竹子日誌（竹子） — Tue, 16 Jan 2024 00:38:14 GMT

過往我是從船舶相關行業開始我的人生第一份職業，過程我經歷機電、媒體設計、物管、業務、行銷，直到現在我在軟體業找到屬於自己的發展。

各行各業都會自己講「活到老學到老」，都說自己行業很辛苦，但真的嗎？我以跨度各行各業的角度來說，我看到了一些事情。

先分清楚硬技能和軟技能

首先我要來談談什麼是硬技能和軟技能。

硬技能就好比：寫程式、剪輯、畫圖、演奏、修繕⋯等等都是硬技能，硬技能的特色是有「會」與「不會」非黑即白，雖然有程度之差，但有一個絕對門檻。

再來是軟技能：溝通、談判、寫文章、分析、協調、管理⋯等等都屬於軟技能，特色是不容易衡量，沒有正確與錯誤的標準答案。

硬技能決定薪資底線，軟技能決定天花板

我認為一般談的「活到老學到老」不是指軟技能，而是那些硬技能。市場上可以發現底端薪資高的職業都是硬技能難以學習的，如：醫生、律師、工程師、會計師⋯。但薪資天花板高的都是依賴軟技能，如：業務員、行銷人員、經理人、老闆（？）⋯

我曾經嘗試學習過多種硬技能，大部分都是卡在學到後期的軟技能導致程度上不去，大致上我就能歸類「硬技能決定薪資底線，軟技能決定天花板」。

但很多職業可以發現，硬技能沒有那麼多好學的，深度也就「這樣」，你一直擴充的是技能的水平發展而非垂直發展。但我們經常談的「技術職業」的特色是這個垂直深度有相當深度，不是你幾年就可以到「差不多」改成往軟技能發展，而是光硬技能就要花費大量時間堆疊。

我判斷難易的三個標準

我經歷各種需要學習的技能後，我才能夠去比較各種硬技能來說，哪些難，哪些簡單。我的評斷標準有「學習前置技能的複雜度」、「學習技能的更新率」、「學習技能的資訊取得難度」。

軟體開發可以說是要深可以一直挖深，很多技術都要「前置技能」，把對應的前置技能點完就快讓人崩潰了。類似於這種性質的技術像是電控、配電這類，前置技能很多。

再來是軟體更新很快，很多硬技能可能20年都不會有什麼變化，但軟體3年5年生態就整個大翻新。類似於這種性質的像是電繪、社群工具，沒幾年就翻新到都不認得。

但軟體來說取得技能資訊並不困難，大部份網路找找就成千上萬的方案和教學，相對來說是容易的。類似談不好取得資訊的諸如外科、配藥、鑄造⋯⋯這些鮮少會出現在網路上的技術，現實中也很依賴體系傳遞知識。

軟體不算頂難，但競爭很嚴重

綜合來說我認為軟體不是頂天難的東西，但因為資訊取得容易，造成行業競爭很嚴重。一旦行業競爭，你只能更努力去贏過別人，更努力去讓自己脫穎而出，找到自己能擺脫競爭的道路。加上它足夠深，可以往更深的地方鑽研，不會淪落成悲劇產業。

開發一個微前端框架

竹子日誌（竹子） — Wed, 03 Jan 2024 00:27:22 GMT

正式接到 CTO 的需求，要從零著手開發一套自己的微前端框架，這篇是動工前留下的紀錄。

其實你不會沒事情

竹子日誌（竹子） — Fri, 15 Dec 2023 00:47:05 GMT

大部分的人工作都期待所謂「把事情做完」，曾經看過一部日劇叫「我要準時下班」，有種錯覺是「我只要做完工作就能準時下班」，但事實上這件事根本不存在。

從管理面看：做完了就能早走嗎？

從管理面來說，如果今天你底下的人可能上班5個小時就把工作做完了，你能接受他剩下3個小時閒閒沒事幹？或是乾脆提早下班？如果他總是那麼快速，是不是應該增大他的工作量，而不是認為他動作迅速？其實這些都是很蠢的管理問題，但卻很多人在犯。其實根本不該為底下交派這麼細的工作，應該要依據這個人的做事性格來分派。

如果你請了一個螺絲釘性格的下屬，或是一個什麼都不會的新人。那你本來就不該期待他思考，或是超乎預期的產出。這種人能做到的事是能承受無聊的工作，可以穩定去執行業務。這時候你才需要鉅細靡遺去交派工作內容。

如果你請的是一個主動但不按牌理出牌的人，或是有相當經驗值的資深工作者。應該給他們「方向」，執行面讓他們去思考去策劃執行方式，這樣更能夠得到更大的效益。

但這不是我真正想說的

但這不是我真正想說的事情。

說真的，很多人都有把工作做完就沒事的心態。萬一你工作多到嚇死人呢？你不會有做完的一天，更不可能產生超乎預期的產值，就算產值超乎尋常，對於公司只是認為那是應該的。但如果你做得完呢？你做完了會做什麼？事實上我發現許多人工作上是「等待主管機關交派下一個工作」，更不然就是無所事事，因為他不知道要做什麼。

真的會沒事嗎？公司的事成堆成山

真的會沒事嗎？其實公司的事成堆成山得做，能為公司帶來產值的事很多，要成為公司不可或缺的關鍵角色，那你必須永遠知道下一步是什麼。不是你要成為老闆或主管的蛔蟲，而是在不被下令待命的情況，你能否持續找出公司需要的東西持續產出？任何事情，你依舊能先規劃，然後回報你的計畫，並詢問「是」或「否」之後去執行。這些計畫並不是別人交派的，而是你很清楚你自己在做什麼，你透過你自己的視野與專業提出的解決方案。

如果你的工作多到工作上無法喘息，工作多到天天只能靠加班解決，無法有餘力可以很好去思考如何讓工作做的更好，那不會是你的問題。然而如果你覺得你總是有空檔能喘息，也有點無聊，或是重複大量無聊單調的工作，那恐怕你得思考一下你下一步該怎麼做，不然你很難有更進一步的成長。

與其等下班，不如累積自己的戰績

與其浪費時間等下班，把握時間多努力一下增加自己工作上的「戰績」，並不是要你盲目的工作，而是一定要花點時間貢獻除了本分工作外更高價值的事。這些東西並不是單純為公司帶來價值，更多是增加自己履歷上的戰果，增加更多極有意義的表現。

到底架構要解決什麼問題？

竹子日誌（竹子） — Tue, 05 Dec 2023 00:38:29 GMT

許多軟體開發提到「架構」，也很多相關如「架構師」這樣的職務，究竟架構是要解決什麼問題？架構很常是由某個人或某些團隊負責設計程式寫作方式，透過 Code Review 或Linter 進行檢查，讓團隊與產品符合特定規範運作。

架構有什麼好處？

通常架構設計是建立於經驗值上的規劃，有效去繞過一些未來藏匿的風險，但不需要全部人去關注這些風險，透過規範去告訴所有人「請你這麼做」。好處很明顯是，繞過風險只需要規範，不需要對每一個人交代完整的情境。如果是團隊巨大或是成員能力和經驗不足情況，架構設計能帶來的價值更尤為明顯。

架構設計最常去處理的就是專案變大後帶來的維護心智負擔，常常找一個功能或模組會找的半死不活。雖然可以透過切分拆解去分類功能，提高維護性和閱讀性，卻也產生更多問題，這是就需要一套架構去解決。

架構設計根本想解決的是一些商業上更困難的東西，考量安全、效能、維護性、穩定性各個方方面面，如果每個細節都需要開發者照顧到肯定很容易漏掉或沒注意到。最糟糕是每個細節都需要新進開發者注意，那就很吃重開發人員的都基礎實力，但好的維護產品應該是能夠任用更多初階人才協助維護，不需要那麼多高階人才，更容易找人填補運作缺口。而且好的設計對於後續接手架構設計的人也有足夠的時間去熟悉和準備。

但不得不說架構設計最終面臨的就是高階人才的吃重，越是複雜技術越需要更強大的人才，如果在架構面的人員迭代會是一件頗困難的事。對公司來說，我的人員要壓箱在少數人手上勢必是一件非常可怕的事，這其實就是單純的管理難題了。

管理問題就不在這個文章贅述了。

先別急著對需求回應

竹子日誌（竹子） — Thu, 30 Nov 2023 00:43:46 GMT

最近輔導一些工程師朋友，發現了一些人在工作上的抱怨是個死迴圈，經常會把問題丟回去給其他人，不認為是自己的問題。

如果產品開發合作的 PM 沒有參與過類似解決方案的當前開發的產品，經常會搞不清楚一些程式邏輯性和操作邏輯性，也會無法掌握技術成本。這時就很需要工程師去提出「解決方案」，而不能像螺絲釘一樣想著會有人幫你想做法。

收到需求的第一反應，不該是「這個很難做」

我看見不少工程師在收到需求的當下第一個反應是「這個很不好做啦！」、「這會做很久喔～我要時間！」、「這個會有問題，不可行！」，但為什麼不是由你想出一個技術解決方案提供呢？兼具「開發效率」和「優良互動體驗」的解決方案只要開發的人才知道，特別是在公司規模不大的情況更是如此。一個成熟的工程師應該是能夠替公司解決問題的，而不是一昧提出異議，而無法給予建議。

但也不是所有人都該被這樣要求

當然我也知道有許多比較任性的公司，總是想要請比較 junior 的工程師去達成「又快」、「又好」這兩個要求。但事實上這些需求理解和溝通是需要經驗值的累積與培養，剛踏入這個領域的新鮮人光應付工作需求就很吃力了，更別說談解決方案和處理複雜的問題。

做一陣子之後，要能看到需求背後的問題

倘若你已經是工作一陣子的技術者，那你應該嘗試去思考需求背後究竟想要解決什麼使用者議題，配合並且提出解決方案。也要知道成本控管，評估工作背後要花費的時間。而不是「可能要很久」這種模稜兩可的答覆，這對於專案管理人員可以說超級困擾的。

估時程是要刻意練習的

但是估時程是一個需要刻意練習的，剛開始會覺得「根本估不準」，但即使如此還是得練習估。再一次又一次的練習中修正與調整，慢慢可以抓到自己的工作節奏和速度，自然就可以更精準的評估時程。到現在只要是我熟悉的工作幾乎可以誤差控制在提早20%內，這也是長年練習的成果。萬一遇到不熟悉的技術和工作內容就需要「前置評估」，先評估方案的難度與複雜度。更甚至花1～2天寫 POC 確認方案可行性，後面不但能避免投入過多的資源在不可行的方案上，也能提高時程估算的精準程度。

工作哲學一時半刻講不完，有機會再從別的議題講起吧～

前端基礎設施

竹子日誌（竹子） — Wed, 22 Nov 2023 00:38:28 GMT

這時近年前端蓬勃發展後才被提起的詞彙，前端基礎設施（Frontend Infrastructure）。隨著前端專案越來越巨大，團隊維護與協作問題逐漸浮出檯面，許多問題待優化與解決，這時候就需要強化基礎設施來改善問題。

前端架構上要密切關注的相關技術就包含以下：

Client Services
CI/CD tools
Bundle tools
Build tools
Package management
Server side render
Browser render
Frontend performance
Frontend monitor
Container management
SEO
AST
Module Federation

隨便舉例幾個超過一半都不是一般業務開發會用到的技術，這都是得花時間去學習的。我個人也是還缺了很多拼圖，現在都還在努力去學習各項技術。

前端工程是一個發展相對晚的領域，系統架構也起步的比較晚。但隨著發展，前端應用程式不斷肥大，產品的發展與成長速度遠超架構規模。當一個 repo 有超過10個前端同時在寫功能，團隊協作效益問題就浮上檯面。

我這一年來幾乎把心思放在 Frontend Infra，太多技術高牆，太多架構面的技術問題和底層議題。你對這些技術有研究嗎？歡迎與我聊聊天分享新知唷～～

加班才是最昂貴的人力成本

竹子日誌（竹子） — Tue, 21 Nov 2023 00:41:14 GMT

近期和團隊主管聊天聊到了「加班」這個議題，深深感受到加班是超級昂貴的成本。

從「看得見」的角度來看，加班首先要付加班費（那種連加班費都不願意給的公司就不談）。一般情況加班費其實是比照「經常性薪資」下去計算，所以不會是底薪計算，相對來說是沒有比較便宜，而且還有加班計費。加班第一第二個小時乘上 1.33倍，加班第三個小時開始的時數乘上1.66倍，絕對是相對昂貴的。

當然可能會覺得多雇用人力，

管理就是要放手

竹子日誌（竹子） — Tue, 14 Nov 2023 00:51:54 GMT

最近聽到朋友說著自己公司的狀況，有了很多感觸，其實很多資深人員和領導者都有強烈的控制狂症狀。我個人其實初期也有蠻嚴重的控制狂症，但經歷過去許多事情後，我開始改變想法，慢慢調整自己對事情那種無法放手的不安全感。

常常許多人的毛病是，底下的人做事方式你發現有問題，你會很急迫去導正與修正，甚至連知會都沒有就修改了文件與成品。這麼做看似把問題在誕生前提前擋下問題的發生，但事實上你解決了問題卻產生了人的問題。

人的內心其實終究是脆弱的，你底下的人之所以會是基層，正是因為內心素質並沒有那麼堅強。任意用權利或能力去壓制和管理，那只是一種過度管理，最終導致自我價值的破碎，要不是失去自我思考的能力，要不就是受不了控制而離開，這其實對團隊來說都是損失。

我個人的想法是，很多時候就是要適當的方式，並且規劃容錯空間，讓部屬能夠隨著團隊與公司成長。適當的給部屬嘗試一些「你預期有問題」的行為，如果不是嚴重錯誤，可以只告知與分析，並準備 Backup防止延續問題，剩下賦予權責給他發揮也是一件很重要的事。部屬感受到自由和權力，也感受到自己的成長，各方面來說也可以提高部屬的「成就感」與「工作滿意度」。當然反面來說，這當然也是一種成本，但長線來看，人才是最昂貴的，如何留住人才不是單單看「薪資」這個面向，而是各式各樣的角度。

你是怎麼看這件事？歡迎與我分享唷～

關於前端單元測試

竹子日誌（竹子） — Thu, 19 Oct 2023 00:53:33 GMT

許多新手，包含過去的我都會犯這相同的錯誤，就是會想要在單元測試測 component 以外的外部影響。但我後來了解到，其實不需要去測到這麼複雜，這只是徒增測試上的困擾，真正該被測試的是只是「那個元件實際完成的工作」。

常常聽到，很多測試的問題，但我整個做了下來得到的經驗都是自己「貪圖一個案例測到太多東西」，導致測試變得複雜。前端的元件單元測試確實相當不好測，加上還有運行環境問題和框架問題。

舉例來說：如果觸發元件的動作很複雜，可能要經過2～4個步驟才能觸發某個 event，這個時候就不要貪圖去把背後最終的 side effect 的渲染結果一次測到。建議先測「觸發」，再測「渲染」，由兩個 Test Case 去測這件事，因為他們要達成的目的是兩件事。

再舉一個例子，可能你有很多外部依賴，包含 store、router、api、ui library ⋯等等。但其實你不用貪圖在單元測試全部測到，那個是 end to end 才需要做到位。其實你可以把這些外部依賴全部 mock ，這樣可以更好的去關注在你的「單元」上。

雖然大家常常念「測試很重要」，但又有多少公司願意讓底下的工程師好好寫測試呢？

關於朋友圈

竹子日誌（竹子） — Mon, 16 Oct 2023 00:39:24 GMT

最近出國旅行，其中一位旅伴是另一位朋友的多年好友，但是這次出遊深深感受到所謂的「差距」。當然中間發生不少令人感嘆的事，也有不愉快的事，但我覺得那些不重要了。朋友之所以為朋友就是「相近」，也許是興趣愛好，也許是工作產業，也許是思想靈魂，一定有什麼接近，當兩人除了「回憶」有共同點外其他毫無交集，這段友誼肯定淡薄。

社會階級有分等級，這是眾所皆知。但思想也同時在這等級之中，因為階級涵蓋的不僅僅是「財富」，還有人脈、地位、思想，這些都是影響階級的要素。為什麼階級相近的人容易在一起，因為三觀接近有共鳴，共有機會深交。

人生中，大家都努力在社會向上爬，有的快有的慢，就跟賽跑一樣慢慢拉出距離。你會接近與你光譜相近的，也會離開與你光譜遠的，人生交集就是這樣分分合合。

有時真的不用那麼在意身邊與你不合的人，朋友也好，家人也好，伴侶也好。合自然會不斷走下去，不合自然是會分開，你看電波對方也會想看你電波，頻道接不上就會疏遠，對方也不會自討沒趣。永遠只要記得，人生終究是得向上爬，不要去停止自己的腳步，身邊的人始終是過客，想要與你走下去自然會去追趕這段距離。

CommonJS 與 ESModule

竹子日誌（竹子） — Thu, 05 Oct 2023 04:54:14 GMT

JavaScript 在發展的路上經歷了許多，早期沒有任何命名空間或是模組的概念，所以東西都是由頭寫道尾，沒有任何檔案拆分管理。但在當時這並不是問題，因為 JavaScript 功能當時並不複雜，功能單純。

教學講究實務情境

竹子日誌（竹子） — Thu, 05 Oct 2023 04:53:30 GMT

我自己做了教學大概3年多，大部分都是利用下班時間去累積培養，也透過教學去內化技術的知識點。在我帶了許多學生後，也會去培養學生去嘗試講課還內化學到的東西，其中開始看見了一些問題。我後來也多方比較了許多教學，發現蠻多教學也出了相同的問題，這也導致這個教學的學習效益很差。

在我所看到的問題中，我覺得最糟糕的就是「照本宣科」，按照預定要教的內容單純只有教「使用方式」卻沒有教「應用場景」。舉例來說，今天教你了怎麼使用「閉包」，但你沒有舉例一個實際的業務場景怎麼使用閉包，那學過的人只知道那個叫閉包但依然不會使用，過一陣子大概也忘記了。這就是我覺得糟糕的教學，每一個知識點都是為了學而學，其實沒有太大的意義。

但如果具體舉出個例子，我的業務場景是我想建立一個設定物件，它具備可被修改和取得的功能，但你不希望設定用取得函式以外的方法拿到，你希望將資訊封裝起來不會被函式外任意拿到，這個場景就很適合使用閉包。

用文字說似乎是抽象了一點⋯不過我想表達的單純就是不要一個個條目去講。必須說，一個個條目講幾乎是沒什麼好準備，但希望講的生動有場景有畫面是需要準備的，並不是憑感覺就可以做得很好。

其實說回來，我一直很尊敬在教育產業工作的人。常常有人喜歡說「賣課程真好賺！」，但我總是懷疑，如果很好賺為什麼要嘴砲？你也跳下來賺就好啦？我覺得要把一個課程準備好真的不是一件這麼容易的事。

為什麼前端這麼需要 Project Builder？

竹子日誌（竹子） — Wed, 27 Sep 2023 04:45:10 GMT

你覺得前端跟後端差異在哪？

前端只需要做畫面不需要做邏輯？

還是前端只需要碰瀏覽器不需要碰伺服器？

還是前端只要關心使用者看到的不需要關心使用者看不到的？

前端有超多邏輯，除了資料邏輯還有使用者的 UI 邏輯，量也絕對不會少。

前端現在 Server Site Render 流行，基本上伺服器一堆問題你也都要處理。

除了介面外，前端很需要花時間建構工具來維持專案品質。

前端跟後端的差別，其實只在服務的對象

這些就問題曾經我都有不同的答案，但最後我發現本質就是「軟體工程師」，沒有什麼你不需要學的東西。唯一的差別在，前端服務的是畫面呈現的一切和使用者操作的體驗，後端服務的是資料的儲存與提供和核心的商業邏輯。

那為什麼只有前端要又轉譯又打包？

但說回主題，為什麼前端需要這些工具？又要轉譯又要打包，各種預處理工具。後端都不需要這些麻煩的東西，基本上就是環境建置能跑程式語言和重要的工具程式就行，前端卻要搞那麼複雜？

從一支破萬行的 HTML 開始

早起前端運行方式就是寫「HTML」，把各種結構、樣式、程式通通塞在那個檔案，這時你會發現你的程式越寫越長，所以動輒破萬行程式碼的畫面就這樣誕生了。這時元件的概念誕生了，透過後端程式語言預先渲染，把不同的程式組裝起來變成 HTML，進而成為模板系統。

CSS 破萬行是基本的，所以有了預處理器

緊接著還有CSS的份量非常肥大、語法冗長的問題。不要講上萬行，CSS 破萬行根本就是「基本的」，你要找也是大海撈針，所以才有預處理器，如 sass, less, postcss。但CSS 也有全域污染的問題，你也很難去管理別人命名，所以才有 CSS Module系統。

上百張圖片與檔案，於是有了綑綁打包

還有資源的儲存，一個前端應用程式動輒上百張圖片，這些圖片的分類、路徑、資源管理都是問題，還有一堆 JavaScript 、CSS 的檔案，各種檔案造成資料夾肥大、分類不易，這時誕生了「綑綁打包」的概念。

前端就是一不小心檔案和專案就會變得「超級巨大」！所以就開始各種工具程式去拆分，組合又能自動化，讓開發者體驗更好。但隨著時間流逝和產品的成長，前端一直無法再去拆分，一樣是一個單頁應用程式在成長，專案就隨之巨大。

後端可以拆成微服務，前端拆不了

以後端來說，每個服務和工具都可以按照極小的單位去劃分，只要用網路或系統通道的方式就可以溝通，不需要強行劃分使用的框架、語言、工具，基本上都可以獨立佈署運行。所以後端是可以把元件獨立成一個服務，需要時動態配置，這就是微服務。

但前端大部分的東西是 UI，所以要能運行起來前提是先把元件讀進瀏覽器，然後才能把畫面與功能組裝起來。正因為這件事，所以前端很難做分散式部署，加上現在都是單頁式應用，所以大部分的情況一個畫面就是一整包的程式碼。

這些就是前端的問題與複雜性，要管理龐大的檔案、元件、專案變成前端開發很頭疼的問題。就因為這樣，許多前端工程師努力解決這些問題，因而產生了這些工具。隨之而來的就是讓人感到這些工具怎麼那麼多而複雜，一堆工具，有種學不完的錯覺。但也拜現在那麼多建置工具所賜，這件事其實也沒有那麼困擾，很多時候靠建置工作就省去搞各種設定。

今天廢話多了一點⋯⋯哈哈哈哈～

真的有需要微前端嗎？

竹子日誌（竹子） — Wed, 27 Sep 2023 00:41:08 GMT

很有趣，最近開始有人因為微前端的議題主動找我，也身邊越來越多人開始討論這個議題。

我覺得目前的發展來看，微前端更多還是炫技成分比較多一點，實際應用上，生態系還是極端不成熟。這種感覺就像是前端框架剛誕生的那個時代，什麼都要依賴 gulp 和 webpack 建構，當時也沒有像 vite 強大的建置工具，寫框架無疑是在拉高維護成本。而現在寫框架好像是「基本的」一樣，每個人都信手拈來，一言不合就框架開幹。

後端拆微服務其實不只是為了更好維護，還有伺服器壓力的分配，其實更多時候是一個「必要性」的系統設計，也是為了能承載更多的用戶而設計。但微前端並沒有產生這種優勢，反而大大提高每一個服務之間溝通的困難度及大幅提高程式碼的複雜度。

微前端真的一無是處嗎？

我承認它仍然有它的好處。如果你想大幅度重構、單獨功能部署、混合多技術線等情境，它就能發出奇效，但同時也得面對它高昂的建構成本。建構成本⋯⋯或許未來有一天技術成熟時，可以大幅度降低這個成本，就像 vite 霸權整個前端圈一般的兇猛。

你曾經考慮過微前端這個技術線嗎？又或許是第一次聽到這個名詞？歡迎與我聊聊唷！

Domain Driven Design

竹子日誌（竹子） — Sun, 17 Sep 2023 23:59:36 GMT

上週是 DDD 年會，從每一場演講中搞懂「什麼是DDD」，我才醒悟⋯⋯原來我們公司一直在推動 DDD。然而對我來說也充滿衝擊，因為DDD並不是廣泛在前端應用的方式，進而導致經驗上的缺乏和水土不服。

第一個水土不服：Domain layer 與 class

其實從前端接收資料對這些 services 的處理幾乎沒什麼問題，這些關於 infrastructure 其實觀念上本來就存在。但到了Domain layer ，要定義一個角色的 entity 就開始產生迥異。基本上前端很少人會用這樣的方式去定義操作，這會對 domain model 建立大量的操作與方法，如果不使用「class」這樣的語法糖會難以操作。然而回到 User Interface layer ，也就是UI 部分，是使用 React 進行操作，在各種 class 的環境下要手動去綁定「this」，這樣反平時前端開發的習慣性。當然我可以去轉換變成 DTO 跟 UI 溝通，但整個複雜性可謂大幅度提升。

或許有人會認為，可以把 store 視為Domain operator ，但我覺得平常在做的store 其實更接近於Application layer 處理 flow 的概念，如果要把 flow 拉到 UI 來處理，那邏輯架構會將各種髒東西往 custom hook 去塞。

從職責劃分改成功能劃分之後

再來是 DDD 最核心的 Domain 。

以往前端會以職責劃分模組的習慣，比如 store、hooks、router、components 等等，開始要改成用功能劃分，比如 Auth、Log、Member、Order 等等。接著產生出來的問題就是資料共享依賴變得更加複雜，如果總是以模組為拆分單位，很快就會碰上依賴循環，A Domain 的低階模組依賴 B Domain 的高階模組，但 B Domain 的高階模組又需要依賴 A Domain 的高階模組，直接發生模組依賴循環，你又得再次把 Domain 的分工再拆小。

前端要實現 CQRS，成本直接拉高

再來還要要談談前端實現 CQRS，原本在後端處理的讀寫分離拉到了前端，但前端根本沒這個概念！原本對於前端只有 function 的事情上升到一個 handler class，定義一個行為的成本與複雜度快速上升，更讓整個程式碼量以高速比例往上拉抬。

不過這一切也不全然是壞事

不過這一切也不是全然都是壞事。

以Domain 來劃分，把模組拆的更加乾淨，當專案要重構和移動時，整個工作成本大幅降低。應用邏輯變得更容易分工、打包、整合。git 衝突發生率也大幅下降，團隊會把精神放在更高層次的問題上面。

以CQRS來說，我們因為採用了「微前端」架構，每一個微前端元件溝通可以說是超級困難，有了Bus 去相互傳遞事件，讓每一個 Micro Frontend Component和 Domain Model 溝通都有了很好的橋樑。

你曾經在前端專案玩 DDD嗎？可以跟我分享唷！

動畫製作

竹子日誌（竹子） — Sat, 09 Sep 2023 04:30:30 GMT

最近做了很多關於動畫的操作，進而也多了很多感觸與心得，想分享一下這個經驗。

首先還是覺得我們家UI設計師很厲害，並不是講著一口「動畫」，而是很明確出了 Prototype 給我，一目瞭然他想要的效果。當然過程密切溝通，討論每一個細節想呈現的效果，這樣的溝通過程我覺得是相當愉快的。其中超級多的細節，包含動畫呈現的節奏、RWD會產生的非預期現象、操作產生的不協調感等等⋯

動畫的本質是處理每一個影格

其實說到動畫，其實還是得談談所謂的「動畫影格」概念，雖然在網頁大部分的情境可以仰賴 Dom 系統和 CSS 來操作元素節點的變化，但有時候還是需要知道「渲染」的概念。而動畫的本質就是在於處理每一個「frame」畫面的「狀態」。通常網頁每個 frame 大致上是 16ms 或 12ms，有時會依據效能的運行狀況影響每個 frame 的實際的時間。所以實質上動畫本質是「處理每一個影格畫面該長什麼樣子」來達到「視覺暫留」，因而有「動畫感」。

Reflow 與 Repaint：連「取得」都算

但說到動畫也要來談談在網頁上所謂的 Reflow 和 Repaint 兩種渲染，Reflow 職責在是計算和處理畫面的「空間」，Repaint 職責在表現畫面的像素表現。但不得不說，Reflow 因為會佔據瀏覽器引擎主線程的工作，所以大家常常說「操作DOM很消費瀏覽器效能」。那到底什麼行為會產生 Reflow？基本上「任何改變及及取得元素長寬大小與定位」都會引起 Reflow。沒有錯，「取得」也算，這就代表要特別小心了，不要任意即時取得元素狀態，不然都是不必要的消費。

實作上最好的解法，是脫離框架直接操作 DOM

最後也要來談談實作這件事，以往我們會很習慣把很多資料存在框架之中，透過改變資料來驅動畫面。然而做動畫時卻不那麼的合適，就拿我最熟悉的 react 和 vue 來說。如果是 vue 會造成非常高的檢查運算壓力，雖然將就一下還行，但也會造成操作上的不順暢。如果是 react 更加棘手，不但會造成極大的渲染壓力，還難以取得下一個 effect 的時間點。而我後來多次實作的感想，我覺得最好的解方是從頭至尾脫離框架的運行，改以純粹的 Dom 操作來達到視覺效果是效益最好的。

動畫效果在商業上不會經常有各種天花亂墜的需求，畢竟動畫背後的開發成本就是昂貴。不過偶爾一次的感受真的蠻棒的，充滿挑戰與有趣。

關於動畫你有什麼觀點嗎？歡迎與我討論一下唷！

JSDoc

竹子日誌（竹子） — Thu, 07 Sep 2023 10:44:07 GMT

雖然jsdoc已經很久了，但不知道的人意外還是不少。我一直以來都很推使用 jsdoc ，也確實推坑不少人使用，近日感覺使用的人真的越來越多。

過去在提議使用 jsdoc 時，很多人都說，為什麼不乾脆使用 TypeScript 就好？當然是因為沒辦法任意導入自己想要的技術才需要 jsdoc 啊～如果對於一個團隊你可以任意使用技術，這是一件多麼可怕的事。所以拜託不要再說什麼不需要用 TypeScript 就不需要 JSDoc 這種話，這一點幫助都沒有。

與其說，jsdoc 是一個閹割版的型別檢查器，我覺得它更多是輔助的價值。除了可以在 JavaScript 環境有很好的型別優化，更能夠提供許多編輯器的輔助提示。因為 vscode 解析時還能針對 markdown 進行解析，所以其實能玩出蠻多的花樣，讓使用你code 的人有很好的操作體驗。

自從體驗到 TypeScript 的編輯器提示優化後，真心有種回不去的感覺。但其實並不是每份工作都可以開心使用 TypeScript ，所以有一段時間我是使用 jsdoc 去進行型別檢查，也大幅提高程式碼的可閱讀的體驗。能依賴編輯器提供輔助提示，享受如套件生態系提供的享受，這種感覺讓開發更舒服。

你也有用過 JSDoc嗎？可以跟我分享你的經驗喔！

依賴循環：前端的 circular dependency 多半不會爆

竹子日誌（竹子） — Thu, 07 Sep 2023 10:44:00 GMT

可能寫前端寫了一陣子開始就慢慢會感受到，模組和模組都是互相 import 來 import 去，可能用的很開心時，在自己一個不注意就發生「circulardependency」

可能這議題在前端不會是很嚴重的問題。資料依賴循環確實會是個問題，它會造成程式本身的崩潰，因為這樣存在強烈的「不合理性」。但模組循環卻是經常發生，而且本身可能是存在合理性的。或許有些人無法理喻為什麼發生模組循環卻不會有任何問題？其實緣由是 JavaScript 在 ESModule 運行下，會先塊狀每個模組，但卻不會直接運行。透過打包和運行引擎會講模組綑綁在一塊，此時都已經加載完成，只要不發生「資料循環」，自然就不會觸發循環現象。

那前端是否就可以忽略這件事？關於這件事就見仁見智，既然不會發生問題，許多人選擇視而不見，以「方便就好」的心態在維護專案。但也不是完全不會有問題，當你以 CommonJS 的方式把程式運行起來時就有可能會出問題，因為 CommonJS 的運行與 ESModule 終究是有所不同的。

你在寫程式的時候回去在意是否發生模組依賴循環嗎？

技術選型是要找合適的

竹子日誌（竹子） — Sat, 02 Sep 2023 03:39:04 GMT

最近在社群看到一個議題，就是寫 Vue 的人現在各種推「Composition API 很棒，有新專案都應該使用」這樣的觀點，這我覺對保持否定態度。團隊的技術選型各種層面都得要考慮，不是一昧追求新技術，最潮的寫法。

前些陣子 YouTuber 「Alex 宅幹嘛」直播有提到，optional api 是有價值的，人不能忘本，其實我蠻認同的。現在寫 Vue 的工程師大概9成是寫 Optional API 出來的，它背後有很深遠的學習價值。

實質來說，Composition API 最大的優勢是可以把同一個元件功能關聯的東西組合進 composable function 之中，這樣閱讀可以依照資料流和邏輯去分離和排列。這樣的特性在越大的專案越是明顯，複雜的邏輯被抽象化為更微小的函式，因而更好被重複運用與拆分。

很顯然這件事並不是一件容易的事情，對於對程式還沒有這麼熟悉的人其實不容易做到。那自然就會誕生出很可怕的程式碼。因為不知道怎麼分類，所以邏輯會整坨攪豁成一團，閱讀不但跳來跳去，而且參數各種跨域溝通。

如果選擇 Optional API ，強制把變數分類擺放，大幅度控制了風格的可控性。當然你也可能會覺得 composition api 也不會多難閱讀，稍微學一下就好了吧？但問題在於給 junior 使用，會有超多誤操作，整個就是大大的偏離原本設計風格。

技術選型沒有什麼比較好，我只能說，依照環境特性，自認有「適合的」選擇。

用我用什麼角度去看套件？

竹子日誌（竹子） — Wed, 30 Aug 2023 00:49:08 GMT

往常找一款套件，大部分的人的態度是「我看起來好用就好，不需要關心實作方法」。但隨著自己資歷的增長，我開始在意我用的套件是採用什麼解決方案去做到效果。

其實我蠻討厭有一種「反正套件幫我解決了，所以我使用套件，不用關心他細節實踐」，但我其實挺不能認同這種方式⋯⋯過去我的實力建立在「大量閱讀原始碼」這樣的方法去提高能力，所以會思考各種實作的實踐，用它本身實現的方式來思考坑在哪，其實很大的程度避免了很多坑。當然常常別人覺得「有問題寫法」的問題，我常常會用「他原理就這樣，一定會有問題啊」這樣的思維看待。我也不太會100%去依循官方的作法，我會從本質思考「它就是這樣的東西，所以這樣用也是蠻合理的」。

上面種種情況，其實某種角度有點狂妄，但跟我的成長歷程和學習方法造就現在的我。經常鑽牛角尖在底層邏輯，搞得自己人仰馬翻，又無法被理解。

我很贊同「工作要用套件解決問題」，這是效率與產出的問題。

我也贊同「沒有程式碼就是最好的程式碼」，這是維護性的問題。

我更贊同「站在巨人的肩膀上開發」，所以所以善用各種前人開發基礎與背景知識去開發絕對是必要的。

經常社群朋友笑我是「竹輪」，因為我在個人的小專案真心造過不少輪子，也為了學習怎麼造輪子嗑了許多的套件原始碼，熟悉不同的套件作者的手段與方法。我不喜歡揣測套件作者的想法，我對待所有程式碼是用「平等的」態度去看待，好與壞有時是客觀的，場景不同也有時是主觀的。但我想說的是，造輪子絕對是建立在背後大量的準備和閱讀，不是憑感覺憑空想像出來的。

Observable pattern

竹子日誌（竹子） — Wed, 30 Aug 2023 00:44:40 GMT

最近在研究一個狀態管理器是如何做到反應與更新，一個狀態管理器如何去做監聽與響應。背後的效能節約與運算有很多技巧與方法。

關於 Functional Programming

竹子日誌（竹子） — Sun, 27 Aug 2023 10:33:23 GMT

最近的時間都壓在這個上面研究，起因是學生許願想聽聽所謂的 FP 是什麼，一開始想簡單介紹一下，結果不知不覺就花了很多時間在上面。其實也蠻感謝學生挖了這個坑，我開始大量嘗試在各種寫 Code 的習慣挑戰這種思考模式。

一開始要先從習慣使用陳述式轉換到去寫表達式，這感覺還不是大問題。但最有感的應該是開始要習慣 immutability 的變數使用習慣，開始感到函式抽象化難度提高。正當覺得很順利掌握這些觀念時，這才是 FP 學習之路的開始。

這也大概是這幾個月，大量去閱讀各種 FP 函式庫使用技巧。熟悉 curry function 的使用，理解它的應用場景與使用理由。最近開始習慣把函式當作傳遞的參數，而不是習慣去使用資料當參數，建立函式一等公民的操作手感。傳入是函式，傳出是函式，只有輸入與輸出是資料的方式。

練習歸練習，雖然 FP 的維護性和簡潔性都很高，也極容易閱讀，但這種撰寫方式並不是這麼容易被學習，比較跳脫一般寫程式的直覺，我也不敢任意在需要與他人合作的應用場景去使用。這也是近期教導學生與自我學習的過程中理解門檻，大概也知道為什麼 FP 雖然被許多人推崇缺極少能夠在工作的場域看到人去使用。

對自我的精進當然持續前進，繼續挖坑給自己跳（？？？

Laravel x Vue Conf

竹子日誌（竹子） — Mon, 21 Aug 2023 23:24:26 GMT

這次活動難得可以遇上前端圈的開源大大尤雨溪，可以聽他分享關於 Vue 發佈以來各種心酸血淚，從一個頂尖開源項目的主導者口中聽他分析的各種想法與策略。但我覺得聽到這些血淚史更重要的是從這些教訓中學習到對於開發的各種細節，從更高的層次去看待每一個專案的使用與升級。

一個成功的開源套件或規範一定要去聽取社群的聲音，社群對於特定的方法而壯大一定有背景因素與價值。
破壞性的改版，每一個點看起來都不是很嚴重的問題，但綜合起來卻是一個很大的橫溝。版本迭代過程再慢慢修正API，而不是一次做版本大更迭。
TypeScript 雖然無法成為規範，但如今已經成為事實規範了。團隊當到達一定的人數，使用 TypeScript 是對維護性的負責，它是有相當的好處。
未來 Vue 生態圈會減少對 API 的改動，漸漸往底層去優化，讓效能、效率、開發者體驗再進一步提升。
插件的開發要避免對私有 API 對使用，對於一個套件的開發來說，原作者很有可能去經常更動私有 API ，這是非常危險的。
Composition 這樣的設計模式是非常適合 TypeScript 開發，也很便於管理大型的業務應用場景。因為 class API 太依賴裝飾器，去依賴一個還不穩定的標準不是一件好事，當初放棄 class API 的設計是正確的選擇。
將核心功能的每一個部分拆分開，不但提高模組的管理效率，也更好的為 SSR 打下基礎。
避免使用 polyfill ，讓源代碼更簡潔，並努力推動有價值的提案規範化。未來可以更進一步去簡化不必要的代碼。

其實還是有蠻值得談的內容，網路上也有大神分享逐字稿，推薦可以去看看。

總是要逼自己

竹子日誌（竹子） — Wed, 16 Aug 2023 10:19:18 GMT

這陣子教學班開了許願課程，隨便給人許願想聽的主題，然後一連就出了很多難到不要不要的題目。看起來像搞死自己，但我也沖洗更熟悉了很多知識點細節，

實作狀態管理器

竹子日誌（竹子） — Mon, 14 Aug 2023 00:42:46 GMT

公司使用了 mobx 這款 observable pattern 的狀態管理器，它主打的是用 OOP 的核心理念建構的函式庫。優勢是跨應用驅動的特性，在微前端使用上有一定的優勢。當然，也必須要說，存在優勢必然會存在劣勢。劣勢就是物件導向邏輯實在與 React 非常 FP的程式設計有很大的衝突與不便。

只有實力與知識令人折服

竹子日誌（竹子） — Fri, 11 Aug 2023 00:44:02 GMT

我常常會掛嘴邊，我現在來到一間很棒的公司，而且我打從心底深處喜歡它。

我們有非常有實力的前端同事，能力可以說是在水平之上。

有的，永遠在技術的最前端，套件不定時都高速版更，衝的比任何人都還要快速。

有的，穩扎穩打，能夠當你堅實的後盾，Code Review 幫你找出問題之所在。

我們有超強大的 PM 團隊，不但會在需求書用心良苦，鉅細靡遺將需求寫到80%以上，一旦發現缺漏也會立即補齊。也是一群真正有花時間去懂技術，經常可以聽到從 PM 口中講出這些詞彙⋯

「那個修改的 PR 已經發給你了喔！」

「Image 已經 build 好了唷！」

「那個剛剛下 npm 有些狀況，你幫我看一下～」

沒錯！這不是和 RD 的對話，這是PM 跟我說的話。

我們有會寫自動化測試的 QA，有強大的自動化測試，讓你版更、重構、調整等等沒有後慮之憂，開發團隊衝就對了！

我們有好學的高年級 CTO ，他雖然不年輕了但永遠積極學習新技術。我遇過的老工程師的通病就是技術落後，對新技術都很不熟悉，常常用著老思維管理前端工程師。但我們家 CTO 曾經開了份微前端的 POC ，不管是 webpack、React、TypeScript 等都技術都用的很有一回事，你能不服嗎？

我們有厲害的技術主管，他領導者工程師團隊。從來不會過度管理，也不會不懂裝懂，經常默默看著一切變化，是時候跳出來修正執行方向，這才是真正的管理。

能夠在這樣的團隊，不開心嗎？

這次的聚會活動

竹子日誌（竹子） — Tue, 01 Aug 2023 00:36:05 GMT

上個月底我舉辦了我的社群小聚活動，人數不多，約略20多人。這雖然也不是第一次辦這種活動，每一次人越來越多，才逐漸到這個程度。

我其實蠻喜歡這樣的小聚活動，人不會太多，更不會像 Conf 一樣聽完議程就鳥獸散，來的目的就是要「認識人」。這樣的場合可以聽到更多每個人背後的故事，也少了很多官話，呈現出來的是更加真實的一面。

但社群上這種小聚活動都只有在小群之間散播，很少有那種公開找人來參加的，原因其實也很單純，因為「不好管理」。有辦過活動都知道，辦活動要搞的東西超多，常常都不是在忙企劃，光是幕後雜事就非常多。

這次來的人非常豐富，各類型的人都有。

有想轉職成工程師的新人

有網頁設計師

有年薪達到台灣封頂的前後端

有軟體自由接案者

有軟體的創業者

有遠端工作者

各種各樣⋯⋯

這次忙著控場，沒能好好跟每個我有興趣的人好好聊到天，這是我覺得最可惜的。但我也算是立下一點對自我來說的里程碑，每一次活動的都是一點經營值。

希望找時間能個別找大家出來聊聊～

UI 框架的選用

竹子日誌（竹子） — Tue, 25 Jul 2023 07:47:26 GMT

前些陣子在社群上討論了一個話題，「哪一個 UI 框架好用？」這件事。

React 生態：mui 與 antd 沒什麼懸念

基本上在 React 的生態系中，毫無疑問的是對應 Material Design 的 mui，和對應 Ant Design 的 antd。有 Google 和螞蟻金服兩大公司保障，完整且成熟的設計系統，我覺得是完全沒有太大的問題。

Vue 生態就微妙了

再來就是 Vue 生態，但這就有點微妙。原來在 Vue2 時期有基於 Material 的 Vuetify，好用並且有好的設計基礎。但到 Vue3 時期出了問題，Vuetify 到非常晚期才完成新版的發布，沒有足夠的時間讓生態圈去使用，導致現在採用Vuetify的產品相當少。那 Ant Design 呢？在 React antd5 時，它做了巨大的改動，大幅提高這個庫的彈性與性能。但 Vue 並沒有隨之成長反倒是卡在 v4，也沒有針對 Vue3 進行客製化改版與調校。

退而求其次的 Element UI

那該選什麼框架呢？這時就可以提到一直在 Vue 的 UI 界舉足輕重的 Element UI，官方也有提供 UI Kit，可以說是退而求其次的二解。但大家都知道 Element UI 是開源社群維護，沒有大公司支持，Vue 升 3 時也發生了一些團隊變革，在框架選用上不得不要考量更多東西。

Quasar 少了 UI Kit，協作會卡住

也有人跟我提議 Quasar 好像也不錯吧？如果以工程師的角度，它確實蠻不錯的，內置的方法和工具都十分完善。然而我卻覺得它不理想，因為它會是讓前端和設計的協作成為窒礙難行的地方。其實關鍵是 Quasar 缺少了 UI Kit，沒有任何完整的 Guideline 與標準，代表設計要憑空捏造出這個 UI 架構。試想，工程師都不喜歡刻設計師想像的元件了，更別說再毫無規範的元件整理出規範，並照著元件樣式在 UI 稿件刻出來，真的非常不實際。

選 UI library 真正該考慮的事

選用一套 UI library 要考慮的不只是好用跟漂亮，也要考量協作和整合等等問題。更深一層是這個元件庫背後維護的團隊是否為長期可信賴的團隊，不會突然有一天要跟你收費或直接不維護。

那你可能想問，那真的要客製化要選什麼元件庫？

Tailwind CSS 囉～～～

戰績是怎麼建構的？

竹子日誌（竹子） — Mon, 17 Jul 2023 04:13:31 GMT

經常幫一些朋友做履歷健檢，但大家不外乎就是「製作網站功能」、「串接 API」、「切版」這種寫了跟沒寫差不多的條目。或許你可能會常常聽到很多資深主管和人資都說要「數字化」你的經歷，但對於許多人來說，「我就是做螺絲釘的工作，哪來什麼耀眼功績可以寫？」，但這種事是可以靠平時有意識的累積的。

關於 React 的效能

竹子日誌（竹子） — Mon, 17 Jul 2023 00:37:12 GMT

這個大概是萬年話題，許多人吵了翻天，大家經常為了「有沒有必要使用 useMemo 優化效能」而相互爭吵，但從來沒有人能夠具體提出一個「數字化」的說法去佐證這件事。為了驗證效能，我覺得具體的算法就是計算時間，我想到直接在 browser 上直接使用 console.time 來測試實際運算的時間。依照每個人的電腦效能不同，消耗掉的資源及運行速度也有所不同，所以我才用「比較」的方式來驗證這件事。

先量一下：十萬圈迴圈要跑多久

首先我先建立一個十萬量級的迴圈，當然我也知道 forEach 在跑這麼高量級時效能很差，你我就先算這個十萬圈跑完要多少時間。測試方式是在單純的 CRA 專案嘗試連續觸發 30次side effect。結果蠻訝異的，在我的電腦裡瀏覽器跑十萬圈花了 0.7～3.2 毫秒。以現代 120 幀的螢幕渲染的計算，每幀必須在8毫秒內完成，也就是說只要接近百萬迴圈量級就有可能效能瓶頸，而且不是每台電腦都可以有這麼快的運算速度。當然越小的迴圈會有越明顯基本開銷，這時實際能承受的迴圈數其實是更小的。

一個 useMemo 到底吃掉多少效能

接著就是我最好奇的，每一個 useMemo 到底消費了多少效能？接著我嘗試去壓測，一樣採十萬量級並一組依賴變數花費 7.8～2.1 毫秒，接著提高依賴變數數量到 10個變成12.9～29.3 毫秒，然後我再提高依賴到100個 22.3～67.7 毫秒。但實質上在於一個專案實在不會消耗這麼大的 useMemo 壓載，所以我覺得useMemo並沒有想像中的消耗效能。

建立 Virtual Node 比原生元素還貴

但我就想，大家說建立一個 Virtual Node 其實不耗效能，我嘗試不掛載純產生看有多大的消耗。一樣十萬量級，一個空的物件是 1.9 ~ 8.5 毫秒，document.createElement 建立 div 是 14.5 ~ 29.1毫秒，空的 jsx div 是 42.2 ~ 66.4毫秒，這又震碎我三觀了，如果在不掛載前提下純產生，jsx 產生的 Virtual Node 比原生元素更耗效能！！！而且建立 jsx 元素竟然比 useMemo 消耗大上數倍。

真正的元兇是掛載，也就是渲染

然後思考了一下，如果加上了掛載到底多耗效能呢？我嘗試插入產生出div 插入 body ，結果才1000筆就消耗掉 1.2 ~ 2.9ms 的運算時間，進入萬筆瀏覽器就直接躺平了…這概就是為什麼人家說 DOM 操作很耗效能的元兇，也就是渲染這件事。

與其吵要不要 memo，不如把數字量出來

有時工程師常常陷入「效能」議題，沒有辦法很好的陳述究竟為什麼要優化，而究竟為什麼不需要優化。數字化是一個很好的方式，可以很明確講述具體的績效與理由。自從我開始寫 React 經常聽到這種效能議題，一派贊成「不管什麼我都 memo 起來就對了」，另一派贊成「需要我再 memo，不需要我就不處理了」。或許檢查是消耗，生成也依然是消耗。妥善管理好節點樹的運算也是前端工程師的責任，找清楚原因和給予明確的指標，而非人云亦云。

當然這是一種作法，我覺得仍然可能有我沒有考慮清楚的地方，也希望有熟悉底層的大神能相互交流聊聊提供一點指教～～

關於我走來體悟到的領導

竹子日誌（竹子） — Sun, 16 Jul 2023 10:23:56 GMT

我過去曾當過幾年的志願役，當時任職基層士官，領導底下的志願役與義務役士兵。年輕的我並不知道什麼是領導，所以嘗試過許多領導方式，野踩踏過許多坑道。當時我觀察不同的前輩或長官領導，也閱讀許多領導的書籍，慢慢也了解領導統御很多時候是風格的問題。在不同的領導統御風格下，有些是人性使然，有些是抉擇的問題，但能確定的是每一種風格都有優缺點的差異。

第一階段：想跟部屬當朋友，結果管不動

大部分年輕的主管都是剛好卡上一個微妙的點坐到領導者的位置，但因為從未領導一群部屬，所以不懂什麼是領導。這樣的人大多犯的過錯是想要和屬下當朋友，並不是部屬不能當朋友，而是遇到問題時處理方法上要有些技巧。過去我就是這種類型的人上來的，只能說這樣讓自己吃了不少悶虧，這樣會帶給我的問題尤為明顯，就是管不動下屬，有些比較皮或是資深的根本是無法無天。這時期除了要強化專業能力，也要穩固同事之間的關係，這絕對會是這條成為管理職這條路上最辛苦且荊棘的道路。

第二階段：靠硬實力壓出一道天花板

下個階段是靠著極強的專業能力和硬實力建構一道天花板的領導方式，這種人基本上沒有人會不服他，在基層領導尤為常見。這也是被大多數人所能折服的一種領導方式，通常這種人出身技術背景居多。隨著時間磨練上來後，慢慢對整個技術與環境的熟練，這時一個基層主管慢慢就會得心應手，出了任何狀況都能成為關鍵救火隊去解決問題。這個時期大多都是在提高旁線技能和跨部門溝通的能力，因為除了你自己的專業外還會發現有太多太多自己不會的東西。這時候如果升遷過快跳到需要帶領其他領域的專業工作者就很容易發生溝通不良的問題，大部分的人坐上主管階也會卡在這塊，無法很好的管理團隊的協作，也常常會累死自己。這時期最後不要執著在自己的專業知識，多去尊重不同領域的專業者，也學的放手別去控制自己底下的人，有時會收穫到更多。

這條路還沒走完

當然，學習領導的道路並未到此結束，這段路依舊要走下去。但也正因為體會過這些，我知道學習如何當好一位優秀的基層很重要，首先要能讓自己的直屬放心。這幾年我從其他行業跳到軟體業，經歷幾年的折騰和磨練，少說也是熬到成為一個還混的過去的工程師。但我的目標不為自己止步，在這領域依舊想要爬到更高的位置，一路觀察每一個領導我的老闆和工程師，看到許多問題，也有許多感觸…

不過我這一路過來也學到了不少技巧，下次來分享一下一些遇到各種難搞類型實戰經驗吧！

職場社交

竹子日誌（竹子） — Tue, 11 Jul 2023 00:34:23 GMT

雖然已經遇過不少「上班好同事，下班不認識」，但職場社交還是有其必要。你也可以說要不要職場社交是個人選擇，每個人有每個人的手法，每個公司都有其偏好的文化跟群體。

職場社交最重要的是

建立工作方式上的信賴關係，實際在工作上合作過、磨合過的夥伴絕對是最優的戰友，比起單純認識或外在資訊了解的人更值得信任，也比多年好友更合適於共同作戰。原因很單純，因為合作跟交朋友本身就是不同的事情，兩者並無法去輕易揣測。你可以聽朋友抱怨公司抱怨老闆抱怨主管，但你肯定不想在工作中聽到抱怨，那肯定影響情緒和士氣。

工作上合作絕對是磨擦大於相處，因為你下意識會認為「做好是應該的」，只要有失誤或不滿意，馬上就開始用放大鏡去處處檢查，可能不注意就加入很多主觀想法。而且如果有更多的社交相處，讓你更了解一個人，知道他做事的習慣有時背後有他的理由。或是單純失誤時願意互相扶持，而不是都用一個「找戰犯」的方式在工作。也許你今天在找戰犯，明天就成為這位被找的戰犯。

但也不是每一個人都適合與他套近。

舉例來說，最經典別去套關係的就是有情勒習慣的。常常：「之前怎樣，你也幫忙一下」或是「好同事幫忙一下」之類的話語，這種人最好敬而遠之。

再來是有明確位階比自己低的後輩，因為管理問題，儘量還是保持距離。當然有人認為可以扁平化管理，但勢必會有一些分寸拿捏問題。這部分以後談談管理再說好了。

其他比較不適合的都是更陰險狡詐的類型，也不容易看出來，卻也未必會遇到。而自己能夠做的就是儘量把自己能做的做好，也不要曝露太多私人情報給同事，適當的情報交換即可。

如果總是以「我不太擅長說話」這樣的理由拒絕社交，那肯定不會有任何進步與改變，督促自己成長與改善，說話技巧和人與人的互動也會進步。一切都是從基礎漸漸做起，提供自己的影響力，改變自己的職場環境。

遠端工作的現實

竹子日誌（竹子） — Mon, 10 Jul 2023 00:42:57 GMT

前陣子寫了一篇為什麼我不傾向遠端工作，但這陣子我看到了一些身邊的現象，更強烈確認我自己的觀點，這次要來依據這些事來談談遠端工作的觀點。
我就是常常找那種會被砲的主題…

我是曾經待過全遠端工作，也在曾全遠端條件下協助客戶管理團隊，更協助多名工程師尋找到遠端工作。但我依然沒辦法贊同遠端工作這件事，原因在上一篇有提到，這篇「關於遠端工作」。

想遠端的 junior，和很難遠端的現實

近日有這樣的感慨是因我好多朋友很努力想要找「遠端工作」，但現實問題是，很多經驗值還沒到位的 junior 們，想轉職軟體工程師的首要原因竟然是「可以遠端工作」，但你現場作戰經驗還不成熟的前提下很難在遠端工作發揮很好的產出，管理難度也很高，根本條件極難找到遠端工作。當然也是存在有許多公司想節省「辦公室成本」而清一色招募遠端工作者，但現實是因為素質沒辦理達到水準，導致管理難度提高，只能說合作上荊棘滿佈。

哪一種工作者不適合遠端

遠端工作不適合招募幾種工作者的狀態，這樣的工作者的特性是，無法預概略抓出專案時程，無法自行找出問題解決方案，無法自行找出既有任務以外對團隊有效率的工作內容，無法自律的規範自己的工作效率和產出標準。公司畢竟講究盈利和產出的地方，無法獨立工作自動運行的團隊成員實在很難勝任遠端工作。

實質上我看到的現象，過於資淺的工程師不知道自己實作效率，經常會卡在特定問題上，執著於眼前的困難或 Bug ，無法平行思考去找出其他解決方案。也經常會因為沒有真正人讓團隊帶領而不知道工作方式與協作方式，勢必會花上比資深的人更多的時間磨合。另外就是初學時不太會學到太多專案整合工具，會花費大量的時間摸索工具使用。沒有足夠經驗的人更別說要預估自己沒做過的功能要多少時間，連自己做過幾次的功能都沒辦法很好的去把控時間，更別說要自我管理自己的產出績效。

遠端要的是能單兵作戰的夥伴

當然也不是怪罪資淺工程師一無是處，資淺工程師在職場上也有對應的存在價值。但事實是遠端工作管理難度過高，要順利管理遠端工作者有超多眉角。管理本來就是件十分困難的事，加上遠端工作特殊的特性，更是難上加難。站在一個管理團隊的角色來看，遠端工作更需要的是能獨立單逼作戰的夥伴，而不是需要時時照顧的夥伴。

想走遠端的話，先準備好這六件事

如果你想要往遠端工作發展，首先你要具備足夠的專業知識和執行能力，可以獨立作戰，不需要公司前輩手把手帶你。
你知道怎麼量化產出和評估自己的產出，讓你的上級能夠對於交辦你工作是放心的。
你要有上下班界線模糊的心理準備，不可能獲得了自由還希望能準時打卡下班，或是公司剛好就有明確的打卡或掛機制度。
如果沒有強大的主管管理的全遠端職務，那你的公司開發很容易就是亂七八糟，大家愛做不做，或是老闆亂管亂發號施令。
遠端後同事的關係會變得淡薄，文字是沒有感情的，久了很難跟同事有革命情感，做起事的溝通與默契一定很差。你要知道有時候不是你同事不會說話或轉達的問題，可能更多是你們之間溝通有問題。
如果你已經開始走向遠端工作之路，時刻提醒自己要持續強化自己業界的競爭力，不要跟產業同儕脫節，因為疫情結束之後，遠端工作的機會不斷萎縮，很可能隨時會走回進辦公室。

講了那麽多感受的東西，下次來談談遠端實際的管理吧。

別期待別人是你肚子的蛔蟲

竹子日誌（竹子） — Fri, 07 Jul 2023 00:43:06 GMT

常常有人會有奇怪的認知，就是提供了範例程式、範例文件、範例流程後，認為別人應該都要理解「範例的規範」。其實別人永遠不會知道你在想什麼，更不會因為你提供了範例就能平行化眼中的世界，因為有色的視野下看到的世界是截然不同的。

日前有合作夥伴提供了一份寫 code 的範例規範給我，請我按照他的方式和他提供的開源程式碼的方式去撰寫程式。我仔細閱讀了一遍，其實我根本不知道「標準在哪」，因為在我眼中看不見「標準」。於是乎我用我看到的標準發PR回去⋯這下好了，夥伴他不耐煩了，因為我沒有按照他「所想的」去執行。

後來我回答：「那能告訴我你具體的標準嗎？」

他回應我：「我剛剛不是給你範例了？也有開源程式碼可以參考，你看不懂嗎？」

我回答：「你可能要具體告訴我你看到的重點」

就這樣來來回回他才說出他的標準，但我覺得他的標準不符合我看到的結果，所以我們又一路的僵持不下。後來我靜靜思考了一下⋯是不是應該問他在什麼條件下符合「例外條件」，不管是開源庫或是他的範例都存在例外，所以我用「問題」反問回去讓他確認。後來他發現了「例外」，才道歉回應告訴我他沒注意到。

這件事也不是要怪罪，而是去反思為什麼有這樣的溝通困難。我們有時候不要預期別人會看到跟我們一樣的東西，不要用「正確答案」去看一件事。而轉達與交派並不是預期同伴與部屬能知道你想什麼，而是要能夠具體清楚的轉達你想要達成的目標，如果對方理解錯誤，應該停下來思考一下，是不是自己說的還不夠清楚，有沒有辦法在講述的更加詳細。這也是教導學生的過程中學到的學問，你很難用「範例」讓人理解你想表達的，溝通需要的素材包含文字、圖示、範例⋯⋯這些都很重要。

Module Federation

竹子日誌（竹子） — Sat, 01 Jul 2023 10:13:59 GMT

前面談了很多關於「微前端」的東西，其中一項脫離不了的關鍵技術就是 Module Federation ，中文可以稱呼它模塊聯邦，但後面我一律用 Federation 簡稱。

這是一個讓各應用的函式庫有效的去共用函式的方法，把各種函式庫模組透過 Federation 共享機制去有效管理，讓輸出 JavaScript 不再是一大包 bundle 。但它共享 library 並非是多版本共存分享，而是針對共用版本共享，所以要去維護整個應用的共享版本機制。權重來說，以測試結果來看，均以「較新版」為優先，所以如果函式庫有向下不兼容特性時就要區分版本，不要加入共享機制。當遇到相同版本時除了靠 Federation 機制去共享外，也可以搭配 http catch 協助減少不必要的外部資源請求，大大去降低微前端造成的重複程式碼賦予的壓力。

當然，這麼好用的工具也不是全然都是優點，攜帶而來還有一些缺點。因為共享無法預期其他模組是否用到相同的子模組或函式，所以打包時會無差別進行打包，也失去 tree shaking 的優勢，所以共享時也要評估共享的對象，並不是無差別將所有依賴的模組通通加入共享。

另一個 Federation 很重要的功能就是模組曝露，就是將專案中的特定檔案當作入口去輸出模組，讓模組以「非同步」或「同步」的方式載入外部模組檔案。通常也不會用 Federation 去拿特定程式碼，可以將共用模組包成 package 再透過模組共享去溝通。而這個曝露輸出的功能能夠統一靠 Entry File 去建立單一資源點的溝通橋樑，在「適當的時機點」載入必要的模組。

Federation 更深一層的使用還可以加上打包類型、區域作用域模組、加載外部模組等等功能。實作上要更加熟悉底層機制和打包工具，不然可能費了很大的功夫卻收不到效果。不過基礎上，上面降到的功能對應業務場景就非常夠用了。

關於微前端的研究

竹子日誌（竹子） — Thu, 29 Jun 2023 00:40:29 GMT

在微前端的開發已經半年了，大部分時間都花在架構面和打包等等議題，也踩了很多很多的坑。但我希望可以更有系統整理這些資訊，我又重新讀了很多文章，然後嘗試各種 POC 實作。但不免跟使用的建構工具有點關係，因為微前端是靠網路傳輸來讀取跨應用的靜態 JavaScript 檔案。其中讓我踩坑踩到滿頭包到就是 vite，確實 vite 是劃時代的建構工具，打包的 config 介面也比 webpack 友好太多，但太多不成熟的成份在裡面，導致各種困難窒礙難行。

對於這個技術解決方案的熟悉度也因為近期的研究又提升不少，逐漸也發現各種新坑，但也因為近期的研究也抱持更多對於未來發展的期待。微服務 2014被提出來後蓬勃發展，而微前端是 2018年被提出來的，發展至今仍然沒有微服務來得普及，其中原因跟 web 的架構有很大的關聯，諸多難點和生態工具支持情況很差。加上前端技術近年爆炸成長，不管是 Bundler, SSR, SSI, Server Component 等等，微前端工具追不上生態圈工具的成長，微前端上手壁壘又非常高，能參與開發的人更是少之又少。

再不斷研究中我發現，想搞好微前端勢必要補一些跟網路、架構、系統相關的知識，它也屬於軟體開發元件的一個選項，所以如何整合也很重要。包含著 CDN, Server Render, Module Federation, Docker… 各種知識海量考驗著你。

近期應該會整理個大綱和簡報，想在社群辦個研討會來討論這個議題。

這些知識點留著後面一個個挑出來聊好了⋯⋯

看爛 Code 也是種學習

竹子日誌（竹子） — Fri, 09 Jun 2023 00:50:09 GMT

不知道是天生體質還是氣場異於常人，為什麼經常遇到公司要求我去重構專案。你可能會想，很棒啊！公司願意重構程式讓它變成自己想要的樣子不好嗎？但通常這種重構是「有前提條件」的，並不是很舒服的那種。

看過夠多糟糕的寫法，才知道好壞差在哪

工程師們有個很怪的特性，永遠覺得自己寫的很好讀，別人寫的很難讀。看過許多糟糕的寫法後，很多時候其實更能去體諒它人在寫程式時的感受。加上平時自己就有閱讀各大知名開源原始碼的習慣，比較過數種寫法的優劣，真正感受到好與壞的差別。

重構時痛出來的九條原則

有一些原則是我感受到非常重要的，這些原則其實可以幫助你寫出別人「更容易看懂」的程式。

不要去用字串組合「不是動態的字串」，用常數來取代固定字串，不但在 IDE 反查更為容易，也好理解字串本身的含義，避免為工程化而寫效益不大的迴圈去組裝。
減少耦合的套件與模組，特別是Map、enum、i18n 這類的模組共用，採用注入或註冊的方式宣告。可以減少對程式的依賴理解難度，並更易於解耦。並不是極高的去共用元件就是好的工程設計，而是依據功能模組去有效分類管理，同時具備模組易於拆分理解才是好的共用。
減少狀態管理，除非有效能瓶頸，結果能用算的就不要去記憶「狀態」，減少狀態的資料結構複雜度。舉例，篩選結果盡量是當下計算而非記憶成新的集合或陣列，要紀錄成狀態的是篩選條件。
避免使用巢狀迴圈和巢狀判斷。避免並不是不行，要考慮到的是當巢狀寫的時候是不是更容易讓別人看出流程與順序，而不是要把要做的流程全部進行閱讀。除了巢狀邏輯，也避免在一行程式碼中放進超過3個邏輯閘。
流程操作不要封裝在函數式中的使用函式。流程盡量可以在最外層的 function 一覽全部的行為與執行分配。而非用 function 去引用 function 一層層往深層封裝。
避免業務關聯性縮寫。除了一些比較能夠被大眾接受的，比如： val, req, res, cb, fn, el 這類的縮寫。避免去設計獨特的縮寫舉例像是： project name > pn , selling price > sp , activity > act … 這類業務關聯性的縮寫。
有一種說法是不要有過多的註解，用好的命名與流程雖然足以傳達好的程式邏輯。但不要對自己太有自信，如果沒有經過足夠的驗證和 code review，註解絕對贏過沒有註解。
減少全域變數或全域註冊的操作模式。這種設計可以說是超級「方便」，不過如果專案規模達到一定的效果會非常難以尋找來源，若非有足夠的文件或規範支撐，否則避免採用這樣的操作。
Linter 很重要很重要很重要！！！這個可能對於很多人來說是基本，但真的很多人因為弄不懂 lint 的規範與規則，任意去 disabled 規則，這絕對是大忌！

以上種種列舉其實也有蠻多 clear code 的既視感，但都是我在重構專案時真真切切痛過的經驗，有些敘述可能沒有 code 比較難理解，可能有時間再寫個部落格來上個範例。

自我專案管理

竹子日誌（竹子） — Wed, 07 Jun 2023 00:45:48 GMT

工作不是永遠都是工作塞到滿，偶爾就是有鬆散的時候，你不見得會很用力去擠出時間追加產值，但其實也不建議你去擠時間追進度。

當然，不存在那種會讓你閒到發慌的工作（最少我是沒遇過啦），但工作往往有很忙的時期與比較不忙的時期。話又說回來，進度這種東西並不是永遠都要追。

一個每天壓死線的情境

我舉個情境：

如果你們公司每天都在壓死線，大家都在趕專案能夠如期交付在最後一天QA 修復issues，在死線日 hotfix，那你可曾想過就算今天你提前三四天完成其實也是一樣的結果。

人類都是如此⋯⋯

可能PM心裡想「啊，還有三天，你多做個功能好了」

可能QA心裡想「啊，還有三天，你的功能我再測叼鑽一點好了」

可能UI心裡想「啊，還有三天，這個間距很不理想，我再調整一下好了」

可能工程師心裡想「啊，還有三天，這個API 設計不理想，我來調整一下好了」

諸如此類的情況⋯⋯

可能你的加班並不是你一個人的問題，而是很多很多因素的結果，這其實是「文化問題」。

專案管理的關鍵是按時交付，不是提前交付

當然，不是每間公司都這麼糟糕而血汗，但你必須依照公司的性質作出所謂的「價值」。如果你們是個每天趕的要死的接案公司更要注意自己的工作價值，不要被其他人擠出來的一些狗屁工作給淹沒。這是應該是安排自己的速度和進程，不需要拉早交付時間，因為專案管理的關鍵是「按時交付」而非「提前交付」。你可能會覺得「啊我如果能提早完成為什麼要拖到時間到？提早做完不就彰顯自己的能力嗎？」。然而事實恐怕不是如此⋯⋯所以到底在交付期到之前要做什麼呢？

那交付期到之前該做什麼？

我會提供一些建議給你

不是不能提前交付，但不要提前太多，通常抓總專案時程提前個10%左右還可以。（意思是越趕越不需要提前）
撰寫文件，文件不是要給正在跑專案的人閱讀的，是要給以下幾種人看的：「沒參與這個專案的同事」、「新進的同事」、「半年後的自己」
多和專案中有話語權的同事討論，一來是因為有話語權的人通常會帶動方向，等於是釐清需求的方法。
多關心自己沒參與的專案發生什麼事，也多閱讀自己未觸及的專案文件和程式（如果有權限的話，但公司規模不大的情況基本上都有機會），掌握全局有利于掌握公司動態和幫助未來適應，特別是職務與自己相近的同事他的工作內容。
撰寫個人工作日誌，紀錄自己到底做了些什麼東西，特別要紀錄常規外所做的事。

以上內容或許有些很好理解為什麼，有些其實背後還有很多價值但短期看不見。這就代表著都是「重要但不緊急」特性的工作內容都可以包含，依據工作職務的差異還能自行調整。日久會發現工作起來會越來越輕鬆，除非是有加班文化的公司，不然也可以漸漸減少自己的工作壓力。

當然，這也是過去的經歷給予我的經驗，如果你有什麼覺得可以更好的或是更有價值的歡迎與我分享～

求職者與求才者

竹子日誌（竹子） — Tue, 06 Jun 2023 00:41:12 GMT

近日總是聽到兩種聲音。

「有推薦的資深有經驗的工程師能介紹一下嗎？」

「公司在徵 Entry 類型的工程師能介紹一下嗎？」

並不是講這兩句話的人的錯，而是這個市場本身就不公平，因為期待值與需求本來就不平衡。

我雖然不是獵頭，但我大概能理解他們在尋覓市場時會遇到的妖魔鬼怪。我介紹工程師時並不是抱持「獲利」的心態，因為我沒有拿到什麼好處，我希望得到的是「雙贏」，而非「成交」，所以我更在乎的是公司與工程師是「配得上」的。但這個「配得上」並不是想貶低公司或工程師，而是兩者我希望好的人選能夠與之匹配。

但有時真的很膠著⋯⋯

從公司的角度看

以公司的角度來說，許多特別有找工作需求的工程師經常都是能力和經驗還沒到水準之上，還沒有辦法解決許多技術問題，更別說凌駕技術之上的商業問題。這種經驗或技術還不到位的工程師很難對公司產生有效的價值，甚至培訓起來曠時費力，投資效益難以為公司回人事成本。

從工程師的角度看

以工程師的角度來說，願意用入門級工程師的公司基本上只有兩個理由。其一，好教成公司期待的形狀，公司不見得願意培養你，而只是希望你聽話照做，如果今天公司能夠好好帶領我覺得很棒，但實為少數。其二就是便宜，因為入門級的工程師通常不會開出太高的價格，能節約請工程師的成本，然而代表著薪資差強人意，但這種公司多半是一人獨幹所有技術問題，沒有資深有經驗的前輩能教導，對於新人不是走歪就是忙不出來瘋狂加班。

市場機制會自己平衡，但中間那段最難

兩者來說。

有名有頭有資本的公司不愁找不到優秀的工程師。有能力有經驗的工程師不愁找不到工作。退個一百步來說，市場上也有諸多專業獵頭去媒合這市場不可或缺的人，市場機制回去平衡。

但我也難過，想找一個優秀能為公司帶來巨大價值的工程師很難，所以也很難推薦，畢竟推薦是要賣臉的。

反之亦然，想找一個能夠給予優於市場價格或是環境良好的公司同時願意錄用「白紙」的公司，這也是何其困難，商業上是講求效益與價值的。

不是不願意幫忙，是雙方條件太難對上

很多時候我不是不願意幫忙，是雙方期待的條件對我來說實在太過困難。這也是獵頭普遍沒有興趣的案件，因為成交過程不但成本巨大，也沒有足夠的好處。我秉持能貢獻產業環境的心態持續努力，希望能找到一點突破口。

無障礙網頁有多麻煩？

竹子日誌（竹子） — Fri, 26 May 2023 00:07:25 GMT

過去經歷過幾次製作無障礙網頁，都是各種改到崩潰的體驗，有做過大概都知道「FreeGo」這款討人厭的軟體，萬一資料庫龐大真的會跑到你想殺人⋯⋯

無障礙要求的，多半是網頁基本功

從基礎來說，其實無障礙要你做的東西很多是網頁的基本功，比如說 alt, title⋯這些東西。但以一個更深的層次來說，無障礙是要建立更好的網頁瀏覽體驗，而體驗這件事除了一般的操作用戶外，也包含著視障人士、鍵盤使用者、爬蟲各種你意想不到的使用者，他們瀏覽網頁時的操作習慣更是你遠遠想不到的。雖然在 UI Design 的階段，你不一定 Persona 會考量並且做到這些人，但是你無形中直接放棄了這些 TA。

FreeGo 和 CNN 檢測過了，不代表真的能用

或許你可能認為，「我們的網站 FreeGo 和 CNN 無障礙檢測都過了啊？」

這件事恐怕沒有這麼簡單⋯⋯

對於 CNN 來說，他們也不一定是盲胞或是爬蟲專業的人在人工檢測，程式測更是許多看不見的盲區無法辨讀，這些問題都潛藏在其中。開發出來的產品一旦到了真正的使用者手中發現其實根本不好用，而這些人普遍又不太會去反應或是無法反饋，最後也只能放棄這些使用者。

做無障礙電子書時，注意到的八個細節

前些陣子參與了無障礙電子書這樣的專案，要製作一個給盲胞閱讀的電子書專案，我發現其實無障礙要注意的細節遠比想像的多，我覺得可以分享一些細節。

對於盲胞來說，文字比圖片更友善，減少用圖片來傳遞關鍵訊息，多利用文字或語意結構來傳達。
Markdown 是好物，可以用文字的方式表述及其複雜的資訊，舉凡數學符號和文章結構。
表格並不是很好的閱讀工具，它是比較視覺化的處理，但內容複雜時，表格仍然會造成開發和閱讀者的困擾。（會造成開發困擾是因為你得宣告表格的報讀規則，否則報讀機很笨，不會理解你的表格閱讀方式）
H1~H6 的結構化和語意化很重要，盲胞的工具可以快速跳轉每一塊結構的閱讀，對於他們來說，一個 h標籤屬於一個段落，適當定義斷落點有助於閱讀。以及Header、Footer、Aside 的分配也是有意義的，在對應的標籤定義無障礙的錨點，對於工具型的網站更加重要。
網頁鍵盤互動中在主流網站最容易被忽略的就是網頁閱讀的鍵盤行為，特別是元件相關的互動，時常會被忽視，時常只考慮視覺和滑鼠的部分。但電腦操作者來說，很多有包含到鍵盤慣用者、肢體障礙朋友、無滑鼠環境等等特殊的場景。這時網頁的移動仰賴 tab, shift+tab, 方向⋯等等操作，這是網站的結構化就起了很大的作用。
減少阻斷性的互動行為。比方說大面積的版位改動或互動上的大跳動，盡量仰賴原生html 提供的互動邏輯，這樣瀏覽器會幫助你做引導。如果喜歡自定義客製化的彈窗、下拉選單、日期選單等等，工程師使用的套件不見得會幫你定義互動邏輯，一定要做過全盤的評估和驗證，否則多使用原生的功能（我知道原生很醜，所以你知道為什麼有做無障礙的網頁通常長的特別醜了吧？）
Focus 是很重要的行為，代表使用者關注的項目，通常在無障礙網頁會用 outline 的手法去強調，這是對於弱視同胞和色盲同胞的友善。或許你會覺得盲胞受眾不多，然而弱視和色盲恐怕比你想像的多上非常多，特別是紅綠色盲和藍綠色盲，這時 Focus 的顏色搭配組合就格外重要了。
在現在UI 當道年代，你知道對無障礙做的最好的是誰嗎？不是 Material 也不是 Ant，答案是是歷史悠久的 Bootstrap 。很多人嫌棄它，它實在不比其他網頁 UI 來得漂亮，然而它可以說是在無障礙中做的最為完善的。

當然，我分享遠遠只是冰山一角，而這些經驗都將化為寶貴的養分。你曾經參與製作過無障礙網站嗎？有什麼有趣或崩潰的經歷可以分享留言一下XD

設計一套 UI 元件庫

竹子日誌（竹子） — Mon, 22 May 2023 00:54:40 GMT

我從自己是 junior 時代一直對於自己手刻元件極其熱衷，最早刻過輪播、下拉選單、輸入框等。隨著時間前進，後來我又做彈窗相關系列的元件，以及各式工具。

製作通用元件的哲學相當多，很多 UI 元件的小巧思更是不容易，這是經年累月開發經驗累積後堆疊的。在現在滿街 UI 套件的年代，誰又去細膩了解每一個元件背後被製作出來的智慧呢？評估一個元件的設計方式也同時能評斷開發者的經驗值，大至各種元件 API 接口，小至互動體驗和動畫變化。

以設計師角度來說，如何設計出好的 design pattern & design token 就是一個難關，通用設計和專用設計的難度不是在同一個層級，要考慮各種組合搭配的應用情境。

關於基本的顏色系統是單一色調支援？還是亮暗雙色？還是複雜的色票風格切換？

多國語言文字的排列組合在同一個元件上設計差異很大，過長時可能延展的改變，過少也不會扁掉，這也是需要細節調整的。

再來就是互動體驗的優化，有時不能單單只考慮直接的體驗，還有關於無障礙的鍵盤互動與標籤語意上的設置，對於role的定義和交互細節的定義都很重要。特別是鍵盤常常是被忽略的東西，但照顧鍵盤用戶也是很重要的事。

而程式面設計部分，初期規劃就有很多要決策，包含採用的 CSS 解決方案、專案架構上的編排、基礎提供的方法與基底元件等等。更深層的設計包含到對於各種前端生態的支援與處理。

再來是元件的製作優先次序，什麼樣算是高階元件？什麼樣的元件是基礎元件？元件可以基於哪些元件當作基礎去延展？

還有 API 接口，對應框架生態圈中，大家偏好看到什麼樣的接口，去符合該生態設計的直覺與做法。

其實每一個環節能提的超級多，以後再慢慢一個個說好了。最近開始想從頭設計元件，多年的開發經驗累積下來有很多想嘗試的東西，不知道大家有在製作元件上踩過什麼坑嗎？

關於 Vue 的好與壞

竹子日誌（竹子） — Sun, 14 May 2023 04:12:01 GMT

我常常會說 vue 是自助餐，他從來不是「限制你」，而是他提供數種寫法。它寫起來真的很自由，很隨意。

好處一：九種以上的寫法組合

基礎的寫法除了 optional 和 composition 兩大寫法外，其實還有一種由社群提供的 class component 的寫法。在於 VNode 產生的部分也有 template 、jsx、render function 三種寫法，各自有自己的特性與優缺點。而這3種 component api 和 3 種 render pattern 又可以各自交叉組合，變化的寫法起碼9種以上。甚至Vue 3.3後還誕生了 function component 的寫法，可以說是它不斷在支援不同的族群撰寫偏好，提供了龐大的包容性。

好處二：全自動的依賴樹

再來就是全自動的依賴樹，在你做 observe 的綁定時就自動對變數進行依賴樹的建立，當你修改了任何資料它都會很聰明的去把必要的變數和元件更新，不去做不必要的渲染計算。

它有所謂的「實體」，可以針對實體去進行多種操作，所以介面上很方便。相對的也有一點麻煩的地方是，因為這份方便與自由產生的許多問題。

好處三：模板把難的地方封裝掉了

最重要的一點就是模板，許多框架成也模板敗也模板。我明顯感受到模板把許多 JavaScript 很困難的地方變得簡單，把很多艱澀難懂的特性直接封裝幫你處理好。

壞處，也是同一批東西的另一面

不過講了很多好，壞也同時也是一體兩面。

正因為它的自由與隨意，也有可能發生在一個專案中充斥著各種不同的寫法。導致閱讀起來極其辛苦。更可能發生混合寫，導致api 的使用變得更加複雜。

全自動的依賴樹常常會發生「殺雞用牛刀」的情況，在邏輯不複雜的變數和元件也經常會過度的檢查與處理。如果操作者不清楚特性，綁定了高頻率更新的物件，會導致不必要的國度運算。

也因為它存在物件實體和各種全域註冊的寫法，回頭查依賴也非常難以回溯。甚至產生各種節點的搜尋謬誤，會不經意做出各種「DOM」操作。

也正因模板帶來的低成本，也造成它跟 JavaScript 有莫大的差異，如果使用者不花時間精進 JavaScript ，那可能仍然什麼都不懂。也對本身熟悉 JavaScript 的人產生高昂的學習成本。當然你也可以使用 jsx 的寫法，卻也失去模板的優勢。

官方一直在補的兩個洞：編輯器與 TypeScript

另外就是官方努力改善的問題。

因為使用模板，所以需要各種插件來改善開發體驗，很難運用純粹的 JavaScript 的編輯器輔助。所以從過去 Vetur 到現在的 Volar 不斷改善模板的編輯器提示。

因為 vue 直接把「功能」切分出去，包含 lifecycle, computed, slot, emit, watch… 等等功能都需要去定義，進而也導致 TypeScript 的型別極其複雜難以處理，過去 component 也不支援泛型的定義。但隨著 vue2 的 class component ，vue3 的 composition api，甚至是 3.3 開始支援泛型傳入，整個 TypeScript 生態圈逐漸完善。

它不是我的主力，卻是我最喜歡的框架

Vue 不是我使用的第一個框架，也不是我現在工作主力使用的框架，卻是我最喜歡的一個框架。龐大的生態圈和眾多開發者協力完成的工具，沒有任何公司名號支持從素人開發者誕生的框架，這也是為人津津樂道。真要說我感受到的缺點就是歐美普及率低，高薪工作幾乎都是要找 React 的開發者，現實面就是這樣。現在台灣市場的 junior 幾乎人人會寫 Vue，但是真的能敢說深入了解這個框架的少之又少。

關於我轉換框架這件事

竹子日誌（竹子） — Fri, 05 May 2023 00:31:58 GMT

本身我經歷了2次框架轉換，所以我自認我是能理解在框架轉換上的痛點。第一次是由冷門框架Mithril轉換到Vue，第二次是由Vue 轉換到React。這兩次都帶給我很多不同的感受，也切確體會到不同框架開發理念很大的不同。

Mithril 是個什麼樣的框架

我大概簡單描述 Mithril 是怎麼樣的框架，以後再另外寫一篇更詳細的。

它是一個基於「事件」驅動diff演算的框架，也就是你綁在DOM上各種事件被觸發時都進行檢查。缺點很明顯，你如果不是基於事件就不驅動，所以api請求是另外的方法去驅動，甚至可能發生要「手動」驅動。撰寫邏輯既不是template 系統，也不是 JSX系統，是更加JavaScript味道的「渲染函式」。比React更加JavaScript，完全沒有語法糖的那種。它渲染邏輯採用的是 class component 的生命週期，也有自己的 lifecycle hook，每一個生命週期也可以透過回傳 Promise 來達到渲染堵塞和延遲更新。

從渲染函式跳進 Vue 的碰撞

更詳細的就不贅述了，大體我可以了解到框架是基於「資料變化」來同步更新畫面，這也是框架的精髓。但突然間從強烈JS 味道的寫法進入 Vue 就有很大的碰撞，我在Vue我更偏好寫渲染函式和JSX，但整個生態圈鼓勵採用 template 。再來是 Vue 為人詬病和為人稱頌的 v 系列黑魔法，我不得不說好多語法，記起來很累。模板最討厭的地方是常常會出現讓你看不懂的語法，你又得回頭去查文件。更糟糕的是萬一遇到比較少人寫的語法，那真的會出現不知道怎麼寫的情境。

「Vue 很好學」是被比較出來的

常常有人說「Vue很好學」，而好學是怎麼來的？其實好學就是被比較出來的，我當時同步學 react class component ，相較之下真的落差很大！最後慢慢我最大得到的感受，就是框架提供五花八門的API真的很方便，能夠解決各種應用上的情境。但也因為底層概念關係，有些api 設計理念是不合適的，進而設計組件有很大的衝突。

寫了三年 Vue，它比較像自助餐

我一路使用 Vue 就是 3年，期間Vue2 和Vue3，也寫過 composition api 和 optional api，甚至連 JSX、TS Class Component 、Render Function 我通通寫過。我並不覺得Vue 是限制很大的框架，我反而覺得它是「自助餐」，它提供了五花八門的解決方案，你可以選擇你喜歡的寫法，喜歡的控制程度，喜歡的自由度。

跳進 React 之後，適應不良的五件事

近幾個月跳入 React，不得不說現實面，以高薪工作還是要選個「很多人用」+「門檻很大」的框架。講講我遇過一些適應不良的狀況，具體描述一些 Case。

首先是你要時時刻刻關注 dependencies，因為只要引用到 useEffect 和 useContext 都可能造成不必要的計算，相依的變數都需要一層層處理處理 memoize。
每個 Component 並不會自動處理依賴變數，要手動包 memo 並自行處理 dependencies ，這些計算行為必須自行評估計算上的效率價值。
在 React Function Component 的 scope 中，不存在「initialization」這件事，只有「first effect」。然而你沒辦法在這個 function 當中定義初始化變數給其他 function 當作狀態。這件事超級違反 OOP 在操作的直覺，狀態不方便儲存。
幾乎沒有 global 註冊的方法和策略，需要經常大幅度跨檔案去取用模組。
對父層除了porps 下傳溝通外，幾乎沒有方法可以去對父層進行去用與判斷。

以上種種大概是最有感的，再設計組件頻頻遇到瓶頸。

但反過來說，React 的好處也很實在

但反過來說，我也體會到好處。

React最強的也是那誇張的生態圈，它所支援的套件範圍可以說是非常廣闊，可以說是 React 代表了前端生態。
另一個點是 React 非常適合使用「functional programming」的撰寫方式，讓整個 code 更加簡潔易懂，半而鼓勵採用這種邏輯在處理程式。
因為效能這件事是手動操作，也就是你可以縝密的評估要做多少程度的「效能優化」。
對於資深 JavaScript 開發者完全可以用「直覺」在寫程式，因為你思考的都是「如何寫JS 」，而不是「如何表現語法」。
Context 有超多打破規則的玩法，可以從中設計出很多有趣的寫法。
對於生命週期的限制與要求更加嚴謹，避免出現很多漏洞。

還有就是⋯⋯不會有人因為你寫 JSX 白眼你XDXD

從零學習前端框架

竹子日誌（竹子） — Thu, 04 May 2023 00:33:23 GMT

我一直有從事程式教學，從新手開始，有些人真的連 HTML 都不認識，一路往下學習切版、程式、框架。網路上其實一面倒政治正確說著要學習「React」才是正確的選擇，我其實也能夠理解為什麼學 react 更好，但背後有很多週邊因素。我無論如何依然是推薦新手學 vue，以下理由我會逐一說明。

為什麼我還是推薦新手先學 Vue

不需要太懂 JavaScript 就可以寫出許多邏輯複雜的操作。模板最方便的地方就是可以讓作者輕易自訂語法，許多黑魔法可以快速讓新手上手，但黑魔法特別容易讓老手感冒。
Vue 不會寫到特別好，但也不會寫到特別差。我要說的是 optional api ，不是指 composition api ，這兩者特性不同。如果你看過新手寫 React 就能明白，不但寫的慢，而且根本看不懂邏輯，一堆東西都攪在一起。
公司教育成本低，反正完全不懂前端也沒關係，只要看得懂 html ，粗淺懂 JavaScript ，我告訴他模板怎麼寫一下就上手了，也不用花很多錢請「厲害的工程師」。這個企業方思維下其實已經很明白，就是一個成本考量，對於中小企業來說這更加明智。
承如上一點先決條件，Vue工作機會豐富。我要講的並不是 React 不好找工作，我要表達的是 Junior 不好找寫 React 的工作。我身邊就有太多血淋淋的案例，就是資歷經驗不足就是找不到 React 的工作，學 Vue 的早就下職場了。
常常有人說寫 React 就是在寫 JavaScript ，對於長遠來說是好事，對於修煉基本功很重要。但教學不是這樣，你要的是讓她能寫出功能建立自信比較重要，不然還沒上手就放棄了。舉例來說，迴圈你不需要分辨 array 和 object 迭代方式的差異，也不用學習多種陣列操作的差異(map, filter, concat)，更不需要關心陣列的 references 有沒有改變。以上舉例真的對新手來講太友善了。
組件的依賴偵測和渲染優化，Vue 可以說是全自動化，動態處理。幾乎可以說是無差別幫你處理所有 dependencies ，也不需要對 component 去包 memo，因為框架背後做完了，效能不會90分，但不容易不及格。
前面有講到，成就感很重要。快速能寫出功能遠比學好基礎有時候對於新手重要太多了，畢竟這條路很長，早點進職場總是好的。

其實真的每一點要往更細的角度談都還可以以細分列舉，不過還是留著下一篇說吧。

Nic 炎上事件

竹子日誌（竹子） — Mon, 24 Apr 2023 00:39:24 GMT

我又來當反風向的人了，我真的是反骨，每一次熱潮我總是喜歡做反風向的事情，講些大家不想聽的話。

這次 Terry 和 Nic 的 feat 影片在工程師群之間炸開來鍋，很多人罵聲連篇，一個技術如此掉線的人，憑什麼當一位「技術總監」？

姑且不論那場「演」出來的面試是真反串還是假反串，我也不在乎，但我從這個現象看到另一個層面的事情。領導你的人「經常」是一個比你技術還不到位的人，甚至跟你專業完全運行在不同的道路上，怎麼會期待有一個主管「什麼都會，以技術領導」，最怕的是擁有很強大的技術卻進行「過度技術領導」。說回原點，你有發現嗎？能夠當高階領導者重要技能並不是他具備很強大的技術，而是懂得「資源調度」、「控制成本」、「解決模糊的問題」，這才是老闆要的領導職。

實際來說，工作上，我們主管是後端背景出身的工程師，但我非常尊重他，也很努力想幫忙推動好工作。但他前端能力強於我嗎？這個答案也很清楚。強大的主管是去領導一群「比自己更強大的人」，而並非帶一群小孩前進。

再舉一個例子，我是「軍隊士官」出身，過去專業技術都是我負責的，但領導我的卻是不懂技術的軍官，難道我會期待這些官員懂技術嗎？從來不會這麼想，因為我與他的角色和責任不同。

社會運行的規則總是沒想的這麼簡單，當你還覺得「一個技術總監技術能力怎麼這麼差」時，可以先想想「為什麼技術能力差卻可以當好一個技術總監？」，如果他做的不好讓公司蒙受損失，那他應該也走路了。

妖魔鬼怪無所不在

竹子日誌（竹子） — Mon, 17 Apr 2023 00:51:55 GMT

社群走跳久了就是會遇到很多人，有討厭自己的人，有你討厭的人，無所不在無可避免。

前幾天我踢出一個人離開我的群組，我認識這個人也算有一段時間。會想要這麼做的導火線是他兩度在我群組中懷疑兩個我朋友的帳號是假帳號，而且不分情況和觀感。當然有一部分的因素是我個人感受因素。

一開始我都是對任何人保持著尊重，也能夠體諒很多人可能只是不善於表達自己，但自身也有許多令人尊重的價值。

但是，如果說話總是不清楚，又喜歡高調談話，別人無法從你的說話脈絡懂你所想要表達的，缺要忍受你沒有重點的談話，那問題就很大了。可能單純這點原因也還好，但如果多次不尊重別人的發言，私訊問一些私人問題，高談闊論去評價你，這就真的讓人很感冒了⋯⋯

要有一定程度社交溝通能力是件很重要的事，不管你喜不喜歡社交，活在當下這個社會，如果你不懂怎麼社交，那你會是一個讓人很不受樂見的人。最糟糕的是去頻繁私訊一個人，講話語氣毫無條理凌亂的發言，甚至有時候帶點不尊重他人的語氣，這都是高速磨光人耐心的點。當然這也不是第一次遇到讓人渾身不對勁的鬼怪，但每次發生都一點讓人害怕⋯⋯

哪來的勇氣去相信套件？

竹子日誌（竹子） — Fri, 14 Apr 2023 00:32:49 GMT

很多工程師莫名無條件相信套件，但你知道套件不一定寫的好嗎？

過去我挑選套件我一定會去原始碼大致上讀過一次，用最快的速度判斷是否有使用價值。其實300行的程式有時候關鍵可能只是其中一個 function ，面對複雜的套件需求它得寫得很彈性，但面對你的業務需求可能根本不需要。其實重點在如何快速掌握一段程式碼的重點在哪，而不是「因為我不懂，用就對了」。如果你只是名 Junior ，或許我能理解你看不懂，但如果是工作2年以上的工程師，我會覺得你應該慢慢去培養自己讀原始碼的習慣。

我的資料夾中有一個地方都是去知名套件 clone 下來的套件庫，經常是我用了一個不熟悉的函式前我要先理解它的運作原理，我會先簡單了解一次，不要跟現有寫法和狀態引起衝突。一來可以提高對程式碼的閱讀經驗，二來減少未來改寫修復的時間。

為最不喜歡用的套件類型是以 Vue 或 React 為前綴的套件。其實你知道嗎？當初寫這種耦合性套件的人對你正在使用的框架不一定很了解，所以寫出來的東西也不見得漂亮。我可能沒有博愛到經常去 github 發 PR，所以對自己公司的程式品質管控可能就得更加嚴謹。

至於有哪些我只能說很多，也有那種很多人用的套件，但寫得真的很可怕⋯⋯我只能說，小心使用⋯⋯

優秀的PM

竹子日誌（竹子） — Wed, 29 Mar 2023 00:25:06 GMT

到現在的公司工作也快要滿4個月了，其中最讓我有感的部份就是PM對需求的細膩度，有一個好的PM在開發上的感受尤為深刻。

舉例來說，我想編輯一個「路徑」，一般的人會怎麼設計？不就是給他一個「input」，然後檢查是否為空這樣，你還會覺得有多少細節？不止如此，從輸入的方式、互動細節，包含輸入「斜線」有什麼特殊的反應來反映出回饋。驗證上的規則，也不馬虎，對於空白符的規則、禁止特殊符號也能明確指出「哪些」符號⋯等等，這可以說是超級好的開發體驗。

不知道是過去待過的公司太雷還是現在太幸福，有強大的PM作為自己的後盾讓人備感信心！所謂看到需求書就有80%的掌握度這種話並不是說說，因為你幾乎可以預期你要做多少功能。真正感受到「需求不模糊」這件事。

如果說寫需求不過是PM基本技能，那接下來這些事才讓人震驚。

一次會議，有個需求是：「如果工程師進去伺服器做任何操作要有Log 」這時有個PM提出疑慮：「為什麼沒有”cd”的紀錄？」⋯⋯等等，你不是PM嗎？連terminal 指令都認識？！

另外我們公司不管是前端、後端等等工程師，對於上線部署的要求就是「build 出 image 交付給 SRE」這個步驟。當然不限工程師，而翻譯其實也是PM負責的，它們要求也不例外⋯⋯ㄉ等，你不是PM嗎？連 docker 都會玩？！

你一定心裡想在想，他們是不是工程師背景轉PM，但並不是。他們只是比別人更用心學習產品細節與軟硬實力而已，這真的是我看過最稱職等PM了⋯⋯

關於遠端工作

竹子日誌（竹子） — Wed, 22 Mar 2023 10:24:44 GMT

不少軟體業工作者不斷追尋「遠端工作」這件事，好像能遠端工作是一件美好的事情。或許你可以說出許多你覺得遠端工作的好，但我今天要來當一個壞人，我得說遠端工作是有缺點的。身為一個曾經做過「全職遠端的軟體工程師」，我清楚極致的遠端和正常的進辦公室兩者的差距，我只能說，我會選擇進辦公室，理由我後面再提。

做了一年，沒見過任何一個同事

曾有一份工作，我真心沒有跟「任何一個同事」見過面，我永遠看到的都是通訊軟體上的大頭貼，那時是一份全遠端的工作。從開始面試、入職、考核、工作、開會，全部都是遠端，我從來不知道我的同事長的是圓的還是扁的，我足足做了一年。當時因緣際會我接觸這個工作，也剛好當時我的腳骨折沒辦法行動，有這份工作維持收入。但講維持怪怪的，因為我當時的薪資也可以說是相當高，也確實讓我足足領了一年的薪水。

工作氛圍不好嗎？我可以說相當爽！上班只要打卡前一刻起床，下班只要原地下班。我可以在任何地點上班，無論是家裡、咖啡廳、工作空間、甚至出去旅遊，只要有網路就可以上班。工作壓力不大，只要能完成份內的工作就可以妥妥的領到薪水。

既然這麼爽，為什麼還選擇進辦公室？

既然這麼好為什麼依舊選擇進辦公室？

單單從一個職員的角度來說，遠端的好處當然多，自由、放鬆、無拘束，然而對於公司來講並不是如此。先假設，如果你今天是一個帶著工程師團隊的主管，你覺得是遠端好還是進辦公室好？也或許有些人回答不那麼上來，但如果排除自身「爽」這件事，只論要遠端管理團隊那很明顯會有問題，下面來提一下實際問題。

一、線上開會讀不到空氣

首先是開會溝通的落差，會議室之內其實更容易去「讀空氣」，常常可以從語氣、表情、神情去取得很多當下這個人的狀態，很容易推斷大家「懂」或「不懂」，這樣講述時可以更精確瞭解需求是否傳遞正確。而且網路上大家不一定會開鏡頭，所以不一定有這麼多資訊。再來是網路延遲，就算延遲只有0.1秒，其實你還是感受得到，會有種溝通沒那麼順暢的感覺。最後是發言率，試問，多人線上會議和會議室會議，究竟有多少人會更多話更勇於提出意見呢？

二、主管觀察不到日常

再來是團隊管理，主管其實平常都會默默觀察大家工作時的神情，還有同事與同事溝通的過程，還有平常投入做每一件事情的效率和比率。只要主管不要過度放大有些偷懶和摸魚，其實認真觀察都可以發現很多資訊。了解這些有什麼好處？它可以讓主管更有效去分配工作，也可以進一步去了解每個人的人格特質，把每個人放在能夠有效益完成工作的崗位上。

三、長期遠端會養出惰性與疏離

最後是團隊因素。你可以發現「長期遠端工作」的人都容易有惰性，就算這個人很自律都可能有惰性，如果是有惰性的人可能會隨著時間產出越來越少，人們傾向「完成剛剛好的工作量」，付出絕對不如待在辦公室之中。久而久之，貢獻與付出同時等價於「認同感」，對團隊用心與忠誠度會漸漸薄弱，對於公司來講是意見蠻危險的事情。

以上是我的經歷與感受，如果你有不同的想法和感想，歡迎留言與我分享。

Design Token：可替換版型與識別形象的前置設計

竹子日誌（竹子） — Mon, 20 Mar 2023 00:40:08 GMT

這真的是奠定一套識別形象很重要的觀念，也是製作一套可替換版型風格很重要的前置設計，更是一個與工程師達成共識高速溝通的利器。

Token 這個詞彙最早是用於服務之間溝通的一把金鑰，用於辨識這個使用者對象。但拉來設計界變成是一個類似key word alias的標籤。那到底什麼是 design token?

先來看看這個例子：

heading-color: #\xxxxxx

heading-hover-color: #\xxxxxx

大概像這樣，定義了未來什麼場景要用什麼顏色。如果今天要換成 Dark Mode 時只需要換掉 Design Token 就好。

那引用一般的顏色表不行嗎？

這其實只會增加自己麻煩，因為你的場景就不夠面向因應各種應用場景，今天如果theme要替換，你必須檢查每一個地方，不然極容易出現顏色違和的情況。或是有些顏色不想換色，有些卻要，但用 design token 和一般的顏色系統直接區分，非常好辨識。

這套系統廣泛應用在 UI 開發上，像是 Ant Design 就有使用。應用的公司像 Adobe，就有建立自己的 Design Token。這套系統定義的是規範，使用者會覺得被拘束不自由，但你可以省去「我該用什麼顏色」的煩惱，把更多精力放在使用者研究和優化使用者體驗。

其實我相信平常在設計時內心也有默默建立一套自己的Design Token 而不自覺。好比「這個是標題就這顏色吧」、「這個button 的hover 就這個顏色吧」、「這個tip文字就這麼大吧」各種內心自言自語。但從現在開始你可以嘗試著練習使用 Design Token 完成你的 UI，慢慢讓你的設計形成一套準則規範。

講了很多次，要寫文件！

竹子日誌（竹子） — Fri, 17 Mar 2023 00:29:05 GMT

很多人誤以為寫文件是要給工程師看需求的，常常覺得在需求會議都討論好了，工程師也清楚也正確完成需求，為什麼又要寫文件？

最近聽到一段故事，有一個產品是一間新創公司的主力產品，大概團隊有10多位成員極力開發一個平台，隨著平台越來越大，公司也跟著一起成長。有一天團隊成員和老闆發生了不愉快，人員大規模出走，老闆無奈只能再找人維護產品，因為要靠這個產品賺錢。然後，新的團隊找來了，但產出卻低下的非常嚴重，QA發現新團隊開發的Bug現率超高，特別是舊功能修改，團隊主管去了解一下發生什麼事。不問還好，一問才知道，工程師和PM花了很多時間研究「原功能」的設計理念和系統邏輯，有時排程一趕也只能寫寫出來不要管會不會造成舊系統出問題。

到底發生什麼事？

其實文件真正的用途是給「後手」看的，沒有文件的情況下，新來的對於這個產品會有成堆成山的疑問，不清楚到底為什麼需求當時這麼設計是為什麼。很多時候不能因為懶惰而推卸責任說：「當時這麼設計一定有用意，不要亂改」這種不負責任的發言。

永遠就有人嫌寫文件很麻煩，就是有人把寫文件擺在後面考慮，沒了文件功能是難以維護的。如果開發的軟體不是接案性質那種拋棄式的需求，而是講究長期維護的，沒有文件針對會大大提高開發的困難指數。

總而言之。

有文件查舊東西，叫考古。

沒文件⋯⋯⋯叫通靈

轉換框架的感受

竹子日誌（竹子） — Mon, 13 Mar 2023 00:28:08 GMT

一直以來我都是在寫 vue ，調過來轉換到 react 後強烈的感受到不同的思維方式。換框架坦白說真的不困難，有奠基著足夠 js 的基礎不是太大的問題，單純只為了把功能寫出來並不難，對任何框架都是如此。

但你開始思考著如何設計元件、元件的重用性、優化效率與效能⋯⋯等等進階問題，你會發現 react 排山倒海的問題冒出來，每一個都牽扯複雜的渲染機制，你要在腦海中建立一個生命週期的循環。心裡默默在想，那些該死的 deps不能再更聰明一點嗎？這memoized 難道都得自己處理嗎？

反觀 Vue 呢？你只要關心它有沒有被觸發檢查機制就行，剩下它會自己完成檢查和更新。很多東西的性能優化處理、參數的拋接和傳遞、閱讀性的一致性，等等東西其實都不用太煩惱，因為再差也就這樣。

但也不得不說，生態圈的繁榮，和對於自由的追求性，這大概就是它最大的優點吧。寫起來不會有太多拘束感，也不會有很多模板語法上的禁忌，你可以直覺的用js 去思考問題。對於效能的運算你可以選擇「處理」或「忽略」，可以對每一個環節的計算做更細緻入微的優化。

我可以說，如果你是一個工程師會很喜歡寫 react ，可以對一切極盡追求，讓程式可以更漂亮，讓效能可以更有效率運作。但如果面向市場 vue 更快更有效率，也更好學習更容易教人。

和 ChatGPT 當好朋友

竹子日誌（竹子） — Wed, 08 Mar 2023 00:42:04 GMT

上一篇講到 ChatGPT 強大的生產力，實際上在工作上它也非常好用，以下都是我會找它來幫我的幾個工作項目。

以下將 ChatGPT 通稱 AI：

我實際會找 AI 幫忙的六件事

做資料搜集和技術評估。在茫茫的google 大海中，要快速找 3～5 個相似何適的對照組實在頗花時間，對於一個技術的問題往往要大量的時間研究和執行 POC，曠時費力。問問AI快速勾勒出重點，減少摸索時間。
製作簡報文案。真要說 AI 最強大的還是文字生產力工作，當有一段敘述文字你覺得想不到怎麼寫而燒破腦，你可以請AI想一段文盛並茂的文字，以最少的時間拿到80分的表達。
潤飾一段程式碼。當有一段寫起來很醜的程式，或是情急下想不到怎麼寫的 function ，請AI 幫你小小潤飾，雖然不能保證最優前提，但好像多了一個不帶感情也不帶意見的個人助手，提供許多好用的客觀評估和建議。
實現功能。很多人很喜歡靠一段模糊不清的敘述文字請 AI 幫你寫 code，但我覺得這是極沒有效率的事，因為你只會來來往往做沒效率的調整。我會先完成一段單元測試，因為AI在「畫面」這件事比較弱，我會避免做太多 UI 工作，提供測試讓AI幫我完成邏輯，精準度瞬間大增。測試的程式碼也可以反過來讓自己重複利用，減少無效的人機溝通時間。
文字微調。當有無聊的文字調整，很難精準的掌握處理規則，但基數不夠大時，那可以請 AI做反而快。比方說一段 CSS程式碼希望把px單位全部替換成rem，如果單位比例特殊一樣可以換算。或是找出一段json各式的錯誤。或是把一段 json 文字轉換為 TS 型別還可以追加條件和規則。
不想花時間回答的問題。許多比較菜鳥的人會問一些輕易可以取得答案的問題，相信你也答的很累，你可以請他「先問ChatGPT」，如果可以得到答案代表也沒什麼好問的，除非你覺得獲得的資訊還是太模糊。這種學習方式我覺得是AI時代需要改變的思維，不再什麼都硬邦邦的學習。

其實還有很多應用技巧，要期待也有人能分享一下自己獨門的操作絕技。

我也來蹭一下 ChatGPT

竹子日誌（竹子） — Tue, 28 Feb 2023 06:45:04 GMT

最近炒得沸沸揚揚的 ChatGPT ，這陣子我對它做了一些初步的嘗試和生活邊的觀察，我得到很多心得，讓我覺得非常有趣。

不少人在吵的是什麼被 AI 取代，雖然 AI 的技術力確實有長足的進步，但我覺得從發展到取代還有莫大的鴻溝，我還不會是短期能被取代的。不過與其害怕被取代，我更覺得能依靠它為我產生莫大的生產力。我印象很深刻，近期我在工作 code review 的時候看到一段很熟悉的程式碼，一查發現有可能是 ChatGPT 產生出來的，因為命名、邏輯幾乎一模一樣。你說寫的好不好？我能說它是一段70～80分的好code，對業務的貼合度我不敢說很好，但我覺得是還不錯又好閱讀的程式。我並不覺得那位工程師偷懶，我反而認為他非常懂得善用工具。

但我覺得現階段 AI 並不是非常完美，它出錯率相當高，需要有人去把控產出品質，並且校驗與修正。以工程師來說，用 AI 寫 code 可以說是一個優秀的 Junior ，快速、有效率、錯了能立即修正。但它不是完美的，有一些是它沒辦法很好的處理的問題。技術整合問題、發現潛在的問題、圖像修正問題、UX體感問題，很明顯就是說一動做一動，沒辦法處理模糊的事情。所以，很明顯⋯⋯有危險的人就是⋯⋯

我覺得AI 目前仍然是一個輔助工具，如果你完全不懂技術，它沒辦法代替你完成技術工作，還是需要一個人去把控品質。但再也不需要去手動做非常重覆性、低價值、反人性等等問題，這種沒有價值的事應該要交給 AI 幫我們處理，充分運用它能帶來非常驚人的生產力。

未來⋯⋯除了 google，ChatGPT 會是我列入主力的生產力工具了。

為什麼前端打不到資料？

竹子日誌（竹子） — Thu, 23 Feb 2023 10:20:32 GMT

有一句聽到爛的話，「我 postman 都會通，為什麼你打不到？」。相信很多前端對於這件事已經習以為常，這就是傳說中的 CORS 問題。

平常在瀏覽器上有一個獨特的機制，就是當對象host與發出的host不一致時，瀏覽器就會檢查 headers 中的 access-control-allow-origin，如果對象並不是允許的 host，瀏覽器就會強制阻擋回應。這其實是一個安全的保護機制，以防瀏覽器有不安全的回應行為，防止跨站攻擊。

然而，如果網路基礎知識不足的情況，不知道這個保護機制，開了api 給前端請求，卻奇怪為什麼怎麼都不會通，那十之八九就是這個問題。所以要確定前端是否能夠正確取得回應除了看 response 之外，還要確認 headers 是否攜帶 access-control-allow-origin ，這樣才能正確判斷這件事。那基本上可以斷定，解決這件事要從後端解決，正確來說是從「伺服器」解決。

那這件事前端有沒有解？其實是有的。解法就是前端自己必須要起一個伺服器，負責 proxy 的工作，去代理所有本地請求，再轉傳出去請求後端回應資料，這樣就能繞過瀏覽器限制，因為這個條件下就是同域溝通了。但這樣其實架構就會有點複雜，同時要去管理伺服器和瀏覽器兩端的問題，這就會延伸更多的技術困難。

錯的不是技術

竹子日誌（竹子） — Sun, 19 Feb 2023 03:49:40 GMT

現在前端開發生態圈中，一但聽到「Wordpress 」、「MVC」、「jQuery」就想是看到鬼一樣，聞之色變。

Web 領域發展非常快速，技術汰舊換新，每一種技術背後都有要對應解決的問題，這生態其實是好的，這是高速進步的象徵，這也意味著執著在舊技術不更新的問題。

很多老一輩嚷嚷著很多年輕人追新技術，都忘卻舊技術的傳統與價值。不得不說，這些東西都有市場對應的優勢及價值，但通常在嚷嚷這些東西的人根本不了解新技術想解決的問題。反過來說也是，很多新人從初學開始就在新技術的薰陶，在根本弄不清楚 html 和網路協定的情況下覺得就是要用前端框架。

我倒是覺得隨著專案的成長與變化本來就得適當去重構技術，沒有所謂的永遠合適。小專案用各種複雜的架構只是拖慢初期開發速度，大專案用簡易架構只是提高維護難度，每個公司都希望快！但背後的問題依舊存在，並沒有消失。

不過⋯這場新時代和舊時代的戰爭依舊持續，就像大家常常掛嘴邊的：「jQuery，再戰十年！」

關於穩定度

竹子日誌（竹子） — Thu, 16 Feb 2023 11:36:13 GMT

不少管理者、老闆、獵頭，他們都追求著「職員穩定」這樣的特性，但我怎麼覺得就是個盲區⋯因為除了考慮到員工穩定度來說，還要對應公司的流動率。我現在的公司讓我很幸福很滿意，我現在不是輕易開高薪我就會想換工作，當然前日才有人說要高薪挖角我，確實薪資很誘人，但評估公司體質後我覺得就不考慮了。我現在待的公司是滿意，也待過那種雷到讓我很崩潰，現在回想起來都很賭爛的（我也不想說哪間），但看履歷的人不會知道這些消息，我履歷呈現的結論是「每年都換工作」。

換得快，不等於不穩定

為什麼要把時間浪費在毫無舞台也毫無成長機會的地方？在評估這個人的好壞時，不是單單看這個人待多久，而是他知不知道自己是「為什麼要換工作？」這個議題，也有人是因為「我覺得不爽就要換」，最少我堅持「薪水要上升才換」這個點。三年來我的薪資成長了3倍，那換的快是因為我不穩定嗎？如果今天不是這樣換工作，我根本不可能有這樣的薪資，待在同一個地方的薪資不可能成長這麼快。

「穩定的員工」到底得到了什麼？

最近有個很要好的朋友我想勸說他換工作，他們公司的狀況，無論是主管風格或技術取向，甚至是企業文化，我都覺得對他薪資成長相當沒有幫助。我跟他資歷接近，他也非常聰明，唯一的差別是換工作的頻率超級低，是企業理想的那種「穩定的員工」，他們的到什麼好處？實質上我看到的是能力成長和薪資調漲的受限，既然事實如此，盲目在待2年到3年為的是什麼？

該看的是實質價值，不是年資數字

工程師是一份有可能到職第一天就提供產出的職務，就算需要熟悉也能在3個月內提供相當的產出。我同意穩定的待在相同的地方確實更掌握業務，但我希望看到的是更有侵略心的人，能夠要求自己在極短的時間成長學習並產出，做好傳承交接及各種企業長遠考量的規劃，文件、制度、技術鋪成等等。做到這些的人哪怕只任職半年也遠比那些幹一年多三年的更有價值，歸咎在實質價值而非沒有意義的數據評估。

這也只能說說，現在求才市場大環境就是這態度。

如果看到這裡的你是工程師，你現在有沒有不同的想法了呢？

如果是獵頭，其實我懂你們的難處，畢竟用人的是企業，並不是您。

如果是企業主管，放下你過往的成見，在這快步調的社會，你可能需要不同的策略了。

設計一個頁面，設計一個元件，設計一個服務

竹子日誌（竹子） — Mon, 13 Feb 2023 00:36:19 GMT

設計這三種東西，頁面、元件、服務，我可以感受到是不同的層級。頁面本身是不可複用的，只要專注思考如何帶給使用者更大的價值就好。但設計元件和服務就不是那麼簡單的事了。

一般在設計介面時，會想著「好看」加總上「好用」，這都是 UIUX 的考量要件。然而開發產品是有成本極限性，時間有限、人力有限、預算有限。所以製作就要考慮設計出來的東西是有複用性和通用性，能面向更多的應用場景，這時就開始有「元件」的概念。一個頁面有多種元件拼湊組合出一個一個頁面，許多頁面再拼湊出一個服務及產品。

但最近工作遇上「微服務微應用」，意思是整個服務都要像元件一樣可以複用，也能夠應付多種產品的通用場景，那功能和參數的設計就不單單只考慮這個產品要設計什麼進去這麼簡單。想想，任何設計改動都會牽扯到全部的產品，要能在最少的改動下應用在產品各種地方的商業情境，這件事是多麼燒腦⋯

費曼學習法

竹子日誌（竹子） — Sat, 04 Feb 2023 12:37:32 GMT

我並不是一個打從娘胎出生就外向善言詞的人，從小看著那些班上的中心人物有點羨慕，但我就是很難講得一口好話。包含破冰、讚美、延續話題，這是何其困難吃力的事。面對人，害怕說錯話，覺得跟陌生人搭話是件讓人恐懼的事，而這件事隨著年齡增加越來越嚴重。

後來我接觸了傳直銷，我發現「銷售」和拓展機會是需要社交活動的，我開始強迫自己去認識更多陌生的朋友，當然也認識很多雜七雜八的朋友。這社會比想像中更險惡，也遇過一些人生低潮⋯⋯

現在來到軟體工程師的領域，我覺得擁有更多社交資源是件很棒的事情，讓我觸角延伸更廣，機會更多。然而學習的過程卻非常辛苦，技術要不斷追逐深度與廣度，新學東西舊東西也會忘記，新東西學了沒有使用也很快就會忘記，在這糟糕的循環裡我有另外一個解答。

這解答是什麼？就是「費曼學習法」。

我去無償對新手進行教學，我不是為了獲利，只是為了更紮實的基礎。也經常辦交流活動，與不同的工程師交流技術，並分享自己工作和練習所成。在不斷輸出和分享過程中，也把技術帶給不懂技術的人，也從「不太會講話」的人漸漸變得讓人稱讚有條理。但我本質依舊不是「活潑外向」的人，所有的外向是逼自己去侵染的。

這個習慣經年累月下來，我已經達到「轉職仔」來說不容易達到的境界。但我也深知比不過那些頂尖的工程師，我仍踏尋一個能更加自我實現的土地。最少現在待在一個還不錯的公司能夠好好成長和發揮，我仍繼續努力成長。

Monorepo 踩坑記

竹子日誌（竹子） — Sat, 14 Jan 2023 05:13:12 GMT

最近在實行 monorepo 架構，真的是被雷到一個不要不要的。特別是「依賴問題」，難搞的讓人傷腦筋，它總是不按照你想的去 work。

一般在 monorepo 的時候，node_modules 的取得會優先讀取 workspace 再讀取 root，這樣才能分類優先級。一般專案都沒什麼太大的影響，甚至專案版本都很一致時都不會有奇怪的地方，初期建構時當然我也覺得沒什麼問題。

不過就是有坑，因為專案不能保證都是「新專案」，多少都會遇到老舊難搞的專案，然後還轉成 monorepo 的架構，這是就有多種版本在運行了。其實一般的依賴有多版本也沒啥問題，真正會有多版本問題的是「打包套件」。許多打包套件很貼心，它會自動幫你檢查有沒有安裝特定套件，並且自動使用，比如webpack 的 loader 都是這樣運作，非常好用。然而事情沒那麼簡單，但套件內部如果自動去 required 時它無法幫你辨識它是 workspace 還是 root，它會去讀取「運行套件它所在的node_modules」，這問題可大了，因為你所有的套件並不會都放在同一個 node_modules，第一個問題就是它可能找不到套件。第二個問題就是它抓到套件未必是你想要的那個版本。

當然也不是全然沒有解法，就是你必須要「清楚指定套件要運行哪個版本。情況有兩個，第一個是字串辨識，一樣舉 webpack 來說，我想要使用 css-loader，我不能單純只給這個字串，必須給它絕對位置，或是用 required.resolve 來抓依賴。第二個情況是你無法確定你版本到底有沒有正確，你內部所有的套件依賴係都必須明訂在 node_modules，並且確定安裝位置是在 workspace 的 node_modules或是都手動指定過絕對位置。

只能說 monorepo 是很新的技術，很多坑都等著要踩，有機會踩到我就會多分享囉。

新年盤點一下自己的經歷

竹子日誌（竹子） — Tue, 10 Jan 2023 00:28:48 GMT

在軟體領域，自己有足夠競爭的技術能力很重要，這是贏過他人很關鍵的點。我是一名來自其他行業的轉職者，無論學歷、寫code資歷、產業熟悉度等等都輸人，更因為如此我願意付出更大的代價去學習、練習、實戰、精進。

我也被前輩罵過學技不精，我也被面試官羞辱過不值得價格，也被老闆瞧不起過。但是這都是過去，一步步能力值我都在培養。我並不是一個有天賦的人，所以我付出巨大的代價努力，只要有餘力就會繼續成長。

一路到現在從業3年半，漸漸在行內也得到一定的尊重，薪資也到達讓人羨慕的高度。雖然在軟體界這只是剛開始，但對於我的人生影響是另一個層面了。

這三年半經歷了很多，認知到技術力是決勝關鍵，最少在這一個部分是備受尊重的。

有自建過無create-app的無框架和冷門框架webpack設定。
自建plugin package 完成各項包管理設定。
有客製化過canvas自定義圖表。
帶過50位以上的學生，幫助將近10位成功轉職。
舉辦過小型20人以上的演講活動。
參與過10人以上前端專案協作。
執行過3週高速開發客製化前後台網站系統。
處理過上萬筆資料渲染優化，讓效能提升30%。
製作過月百萬級流量電商系統，降低後端資料壅塞。
重構過達80組module的中型網站。
架構微前端系統，自建webpack設定。
設計過monorepo專案架構，自建npm設定。

雖然不是多麼漂亮的成績單，許多在頂級外商企業的人可以有更棒的成就，但這也是一位專職仔拼盡全力達到的成就。

學習新技能不是講講

竹子日誌（竹子） — Tue, 03 Jan 2023 15:40:39 GMT

我一直有在免費教學前端技術，帶過上百個人。然而很多人開始前都講的很自信說每天花2小時、每週花10多小時什麼的，但真的做到的真的沒幾個。每個都說，想學切版、想學前端、想學程式，但每個禮拜真的能擠出4～8小時好好學習新技能的寥寥無幾。

有朋友說，其實陣亡率很高有一個關鍵原因，就是「我沒有收錢」。這也讓我感嘆，真的想幫助人學習新技能，但真心會珍惜這個機會的人怎麼那麼少，難到一定要付錢心疼才會珍惜嗎？

初學時也有許多朋友每個都說想好好打磨技術，但時隔多年，我也爬到現在的程度，當初的朋友還是說要找時間好好學。學技能真的不是出張嘴，是真的要砸時間打磨成長的，只有認認真真變強了，在市場才能立足在不同的位置。

Webpack升版（二）

竹子日誌（竹子） — Sat, 10 Dec 2022 06:02:03 GMT

要關閉 Vue-cli 的 TS，方法就是去修改 ts-loader 的設定，從頭到尾不是 ESLint 做的祟。到這裡總算是可以把專案暫時動起來了，但接著還要各種問題⋯⋯最要命的是 typescript 的各種運行規則，不要去挑戰非常冷門的寫法，永遠會讓你有驚奇的事。比方說 class 初始化去省略 constructor 的語法不寫這種情況，能定義清楚或是有爭議的部分千萬別去挑戰它。

眼看著專案動了起來，這時發現又是一片紅。這次是對於 SCSS 變數的 :export 的轉換失效，這問題其實是對於檔案名稱在 vue-cli 下有綁定一個名稱的規則，要加上 “.module.scss” 的後綴，這時辨識為模組後才將其轉換為 JavaScript 的變數。

接著就是缺套件的問題，像是會噴出 core-JavaScript 相關的 Error 就是 babel-core 沒有更新，升一下版本就可以解決。其他也都是相依套件缺失，安裝一下或是升版就可以解決。

一路過關斬將來到看到它運行起來真的是成就感滿滿，可以把一切弄成目前狀態也是花了不少時間。終於可以開始跟平常一樣去架構專案了⋯應該啦XD還不知道有什麼坑呢！

Webpack升版（一）

竹子日誌（竹子） — Thu, 08 Dec 2022 10:34:32 GMT

近期舊專案要幫 webpack 升級，從4升到5，以往升級其實還沒遇過這麼大的專案要升版，但這一次我真的碰壁了。龐大而複雜的架構與依賴讓我極難修復各種問題。

從升級的方式，因原先是用 Vue-cli 去建構的專案，首先要找到它提供的升級的介面，而非是強升內部依賴或是建構新專案設定來遷移。

第二個問題就是 node.js 的版本問題，要進行升班指令時，依據 node 版本不同，指令依賴也有點差異，首先還是要先以舊版本的 node 為主。但遇到模組不相容時，就需要另外安裝 polyfill 去支援。因為 webpack 內部處理 4和5遇到不支援介面時4會預設處理部分的模組，升級後有些預設就不支援了，當版本過舊時就要去 reslove 去關閉對原生模組的取用，改以 webpck-polyfill-plugin 去執行。雖然有人使用原生模組直接介接的方式，但我執行時似乎不管用⋯⋯

接下來遇到的是ts 錯誤噴到一個崩潰的程度，主要原因是過去專案的撰寫方式不符合新的 TS 標準，導致新的 TS 檢查出問題，因為專案太過於巨大，我選擇想辦法關掉檢查。但這才是問題開始⋯⋯你可能覺得是關 lintOnSave或是ESLint，但答案都不是⋯⋯

關於文章分享這件事

竹子日誌（竹子） — Sat, 03 Dec 2022 10:00:03 GMT

最近我的幾篇分享關於面試和履歷的文章觸及率特別高，也漸漸傳到朋友圈甚至出圈，慢慢有人會看到我。然而隨著曝光率增高不免惹來一些敵視和攻擊，私訊也好，朋友分享也好⋯等等。我其實有點難過⋯⋯

我沈靜想了幾天我決定會持續分享，你可以認為我講的不好而不參考我的作法，我只是用我學到的經驗和換位成面試官角度去看這件事，把我在意的點說出來。我覺得就是要有人講出來才能幫助到更多人，如果永遠背後當鍵盤俠噴人，那社群不會進步。

我不是最好的或是完美的，你可以告訴我該如何改進，我會非常感謝你。但請不要用輕藐或瞧不起的態度覺得「你也沒多厲害，憑什麼在那邊講大道理」，為只是願意分享我看到的角度，我只是想幫助更多人能更好。你說目前我靠這些努力拿到什麼好處？目前沒有實質拿到好處，包含求職也沒實際在任何社群平台找到工作，我仍然願意持續寫文章分享。

從現在開始我會做我覺得對的事，不需要敵視任何人，或去笑別人。我就是提供我覺得有價值的事，持續努力不懈的做。

在聯禦科技的最後一天：半年裡學到的四件事

竹子日誌（竹子） — Tue, 29 Nov 2022 23:30:05 GMT

今天是我在聯禦科技最後一天，雖然短短半年，但有許多的體驗。有製作Canvas的經驗、有面試找同伴的經驗，有重構專案的經驗，甚至有產品設計的經驗。

最有趣的是 Canvas：渲染與多線程

其中最有趣的就是Canvas製作了，嘗試實作渲染和多線程的處理，極致在效能上做出努力，真的非常具有挑戰性。但在前端裡也算冷門技能了，沒有太多人會，但我也是努力挑戰去實現它。

花最多功夫的其實是 UI/UX 設計

這段時間我花最多功夫的應該是「UI/UX 設計」這兩塊領域，對我並沒有很大的實質幫助，但是我覺得對於一個產品的產生有了更深的理解。從需求產生、需求訪談、需求分析、架構設計、介面設計、流程設計，完成一連串的設計規劃後再仰賴自己去製作實現。設計跟工程不管是在思考上和執行上有很大的不同，思維上設計講究的是「包容」，要盡可能放人各種創意與功能去優化對使用者的體驗。而工程是規劃可行性、成本等問題。設計有時候不是單單想出來就好，經常需要和工程師溝通協調，找出可行的實現方案，有時真的不是像「想像的」這麼順利。

重構專案最心累

重構專案大概是最心累的，龐大的技術債花了巨量的時間在改善，閱讀就有的邏輯再重新去實現與改善。前手不成熟的處理導致埋藏諸多問題，進而造成重構上的艱難，還要去說服其他工程師要去接受改善。

幫忙面試，找一位 UI 設計師

因為身兼設計和前端，主管感受到這兩個職務的差異，希望讓分擔我的壓力，也花了一段時間在物色一位UI設計師。過程進行面試準備和籌劃，設計面試流程和問題，也是費了很大的力氣。最後要離職時也協助設計前端工程師的面試題與流程。

和後端工程師溝通時我一反過去非常激進的態度，我盡可能去委婉說明，使用「麻煩您」和「請教」等字眼去表達，不免因為我積極的態度產生思考上的衝突，但我要的是更好的成果不是？

這段時間最照顧我的大概是我們家 Allen 主管，他對於我實行的方案全力支持與實現，我也願意為他付出一切代價與時間，我只為了專案能做的更好！

說真的，我還想繼續待

這是一間福利制度完善的公司，要不是當時被一位長官挖坑，我也不會開履歷去找下一份工作，不然我還真想繼續待⋯這真的是一間讓我待的很開心的公司。

最後的最後，祝福自己鵬程萬里，我得繼續往前邁進！

如何寫好一份前端工程師的履歷

竹子日誌（竹子） — Mon, 21 Nov 2022 23:46:23 GMT

之前分享了從面試官角度談UIUX 設計師的履歷，身為前端工程師我也想談談這一塊，最近幫朋友看了非常大量的履歷，發現不管是 junior 還是 senior 都了類似的毛病，明明能力還不錯，卻沒辦法在履歷上呈現自己的價值。

面試官只用 10 秒決定要不要認真看

面試官在看履歷時，你要想後面很可能有100份各種滿滿文字的履歷，也可能看了100份跟你很相似的履歷，只會用10秒鐘決定「我要不要認真看這一份履歷」，如何吸引他願意認真看？

讓履歷被看完的六件事

只寫重點，不要廢話。這點很重要很重要！沒有人在意你個人的事，或許寫學習歷程和轉職前的經歷有些面試官會看，但這些不會是最重要的，大家在意的事你「現在」的技能和軟體經歷。
技能不要流水帳寫，要用最短的文字讓人知道你的技能強度在哪裏。如果沒寫，就當你是剛學會，只懂粗淺的使用。舉例來說，webpack: 能客製化打包路徑，熟悉處理loader套件的版本依賴問題。這樣就可以很精確的呈現實力。
自我介紹一行就夠了，不要當自傳和文章寫了一大堆廢話，因為根本沒有人會認認真真的看。
經歷不要寫「串接API」、「撰寫技術文件」、「依據設計稿製作畫面」、「與團隊溝通討論需求」。哪一個前端工程師不是在做這些事？當每一份履歷的每一份工作都長得差不多時，真的對這些文字已經啟動「自動忽略模式」，看完只會「沒印象」。既然要寫，請寫出這份工作跟其他前端工程師相比較特殊的部分。比方說「製作google extension 」、「為團隊導入打包工具，提高部署時效率50%，降低網站消耗流量10%」、「開發團隊共用web components」等等比較亮眼的經歷。也盡量找出「數字」來表現成果，會讓一切看起來更亮眼。
除了履歷，還有呢？許多工程師做一陣子後也不再維護自己的 github，導致裡面空空如也。沒有作品不是原罪，但沒有code讓人更瞭解你，也沒有部落格，更沒有名氣，那你到底怎麼展現出你的亮眼之處？這其實都是經營個人品牌的環節，除了Github 可以撰寫 Profile Overview，也可以寫文章記錄技術經驗，更可以經營社群建立個人品牌創造影響力。
Github 除了給，也寫了專案，但 commit 的頻率根本寥寥無幾。加上沒有README可以導讀，讓面試官在茫茫大海在尋找亮點，這真的一點也不加分。具體就要讓人從外部連結一進 Profile 就知道要看什麼專案，打開專案就看得懂要看什麼檔案，快速引導到關鍵檔案。

不要樣樣靠 104 履歷

網路上很多花里胡喬的履歷模板，弄一份客製化履歷放在網路上。不要樣樣靠 104 履歷，你無法脫穎而出，只會被當作炮灰而已。目前我幫許多人健檢過履歷，問題大同小異，希望大家可以越來越好！

UI 設計不是靠感覺

竹子日誌（竹子） — Wed, 16 Nov 2022 23:35:43 GMT

我經常掛在嘴邊，UI/UX 是一門非常專業的東西，它背後龐大的知識體系導致它深不可測，也非常的困難。常常有人真以為UI是找個會畫畫的來畫一下就好，確實學習操作繪圖軟體不是一件很困難的事，但這些知識細節根本沒辦法考量的很周全，只會畫出一個四不像。

所有的設計想法和理念都需要一個理由，如果有人問你「為什麼要這樣設計」時，難道你只能回答「因為我覺得比較好看」這樣膚淺的回應嗎？UI設計界有一句經典名言：「好看的介面不一定是好用設計，但好用的設計一定不會難看」。

經常看到的顏色、間距、圓角、流程，每一個設計細節都應該要有它的理由。可能實際在製作當下是用直覺和美感在畫，但後續在review 時一定要重新思考過這樣設計的價值和理由，並非一個「好看」或「我想要這個功能」這種想法就做出決定。因為每一環節的設定都是為了成本控管、市場效益、使用者體驗等等因素，只有同時考量到這幾個因素才可以非常義正嚴辭的表示堅持這樣設計，不要其他人來干涉這些想法。

即使你樣樣考慮到了，最終總是得問過工程師。就算今天要製作一個效益非常大的功能，你也很確定功能的可行性和成本考量，還是得問過工程師和專案經理，因為每一個公司的程式架構不同、能力不同、環境不同、期程不同、核心價值不同，沒辦法綜觀全局剛愎自用是很糟糕的，不斷溝通和討論，注意措辭和對談，這才是解決之道。當然我也知道有些長官和工程師脾氣很差，但那是他的人生課題，你能做的是成為柔軟又有想法的人，常言道，以柔克剛，硬碰硬雙方只會鬧得不愉快。當你在這軟實力達到某個境界，談吐自然而然就會與眾不同，這些慢慢都會反映在面試成果上。

Mobile App和 Mobile Web 是不一樣的東西

竹子日誌（竹子） — Wed, 16 Nov 2022 23:07:25 GMT

這件事我歷份工作都經歷過，每個人看法迥異，但這兩者絕對不一樣。那他們分辨的定義呢？mobile app 就是你去app store或是下載應用程式安裝檔所跑的程式均歸類為app，讓使用者藉由瀏覽器、app內部瀏覽器打開的應用程式均歸類在web。

你可能會覺得兩者長得很像，但就只是很像而已。也有工程師會覺得web也可以做app啊！那分辨點在，差異點在於「預設行為」和「預設介面」。瀏覽器包含了各種為使用者預設好的操作功能，包含網址、上下一頁、重新刷新、預設的UI Bar，等等功能其實都是基於「瀏覽器」這個app上，也就是web是app轄下的一個部分。當然你也可以把app包裝得很像web，那我會說它依舊是app，但看你怎麼去界定。

既然介面跟行為不同，那又為什麼會覺得它是一樣的東西？那肯定是不能通用的，光是app都要分IOS和Android了。

什麼？！IOS和Android不都是App?剛剛又說到關鍵差異點，「預設行為」和「預設介面」，這兩個只要完全不同就是不同的東西，那對於與使用者體驗也肯定不同。

當然不少公司想要把它混用，降低複雜度和成本，它不想弄那麼細。但事實是這樣只會讓成本更高，因為你為了讓工程師去實現統一的體驗去想辦法刻出一摸一樣的三種不同的環境，最終只會在「測試」、「互動」、「限制」等等多種環境的整合花上時間。或是充滿妥協和費時的溝通。

曾經有個設計師問了個很有趣的問題：「如何分辨哪些介面是原生，哪些介面是被另外寫出來的？」我諮詢過幾個比較有經驗的設計師得出來的結果是「靠經驗」，就像工程師要去認識龐大的原生API，設計師也要去認識各種系統的原生介面有哪些，確保操作體驗是在可控制範圍，而不是「請工程師統一」這麼沒有成本觀念的行為。

所以希望app和web統一，你必須建立在瞭解和充足的開發資源前提下才做得到，如果做不到這兩個前提，那只是因為無知而做的任性而已。

設計與工程的萬年戰爭

竹子日誌（竹子） — Tue, 15 Nov 2022 23:14:58 GMT

在軟體界，不少工程師和設計師總是會在工作上有不少爭執，其實我覺得本質其實就是不了解對方的工作。

這兩個在工作上最明顯的區別就是，設計師要的是「發散」，講究的是包容，最大程度的把各種可能和良好的創意與發想包容進去。而工程師要的是「收束」，講究的是可行性，為所有天馬行空的想法找到一個可行的實行方法。

設計師的職責：交得出創意，但要扛成本

回頭談談職責吧，一位設計師的本質職責是什麼？不就是找到一套市場解決方案，提供用戶一套理想的使用者體驗。如果交不出有創意的提案，很快就會顯得沒有價值，你我後只是一個寫文件和畫圖的機器。但理想的東西最大的問題背後要承擔的問題是「成本」。所以認清手上有什麼工具，極限和速度在哪，如何最有效率去規劃和執行就很重要了。

工程師的職責：把天馬行空變成可執行

回到工程師，他本質其實是產出可執行的實體，並且能夠提出每個天馬行空的想法一個實現的具體方案、限制、時間，並下去執行實現。但問題是經常在乎的變成「我能不能快速做到」，而非實行方案。經常衡量工程師的KPI並不是用「實現困難的東西」，而是用多「快速去產出東西」，那又為什麼要花時間在產出困難的東西呢？但反過來說，技術區別價值就是在能否最大程度去實現「老闆的夢想」，這樣自己才會顯得有價值。

工程師的立場：不是做不到，是時程內做不到

工程師的立場來說：

當主管覺得要你做充滿動畫的簡報，但你手上可以使用的工具只有PowerPoint，但是他希望明天就可以給他呢？你心裡想著，雖然不是做不出來，但只有1天怎麼可能做得出來？但老闆卻覺得，做簡報不就是1天能搞定的事？於是乎你就回答：「做不到啦！」但問題並不是「做不到」，而是「時程內做不到」。

設計師的立場：同一套系統，不同的人做不出來

設計師的立場來說：

假設你今天規劃一套系統，但是得交付給其他工程師做，但那名工程師卻回答你「做不到」。但是這系統規劃很可能只是你抄隔壁公司的系統架構，你可能很疑惑會想問：「為什麼做不到？」。然而問題是，那位工程師可能只是剛入行的菜鳥，但這套系統卻是頂級企業的資深工程師做出來的。

但現實是公司總是又要馬兒好又要馬兒不吃草，你相信一個心臟移植手術的手術費只有10萬嗎？那背後龐大的成本肯定有一個人買單，或是⋯⋯根本做不到。所以同時要兼具整套的軟體技術其實實在不太現實，最後搞得全部的能力都是半套三流，人一天只有24小時，能學到什麼程度？

要理解對方，只能換位思考

回歸主題，其實要理解對方，最好的做法就是換位思考。當你做不到換位思考，你就永遠困在自己的思考能立場，那思維依然被困在那個位置，無法拉抬上更高的層級。

文件究竟價值在哪？

竹子日誌（竹子） — Tue, 08 Nov 2022 00:17:41 GMT

軟體開發的世界，無數人一再強調「文件」的重要性，卻沒有人能很清楚說出為什麼要文件。

我有一個新創圈的朋友，當初他組建了一個團隊，有專案經理、工程師等等人員。但是礙於公司規模實在沒有很多預算請一個強大的團隊，每個都是能力不高的 junior 。然而，初建產品最忌諱的就是著急和貪求完整，他一直急著要把產品開發出來，但需求一直不明確，因為他沒辦法具體讓PM很清楚他想要什麼，也經常覺得「這樣好像比較好」再改動需求，甚至有「少了這功能好像這產品就不是很有吸引力」在追加MVP的複雜度。

我當下覺非常不對，我告訴他，停止你的開發方式，立刻開始寫文件！他非常反彈覺得「寫文件是沒有產出的事」，希望工程師盡快把Code寫出來。大概經過了2個多月的開發，團隊也有各種磨擦和爭執，PM和工程師鬧了翻臉。後來，PM和工程師都離職了，那堆程式碼根本沒人想要接手，任何工程師都想開發自己的程式，什麼都沒做出來。最終還是當初文件最有價值，工程文件讓下一個工程師能夠上手，PM畫的設計稿、需求列表讓下一個人知道要做什麼。

文件不可能詳細到一看就懂，也不可能是解藥萬靈丹，也不是文件有了產品就沒有問題。但是，從這段故事可以知道，文件是「標準」和「抵抗風險」的關鍵工具。可能有工程師會說「Facebook 不也提倡代碼即文件」這種說法？這其實是他們想逃避寫文件的作法，因為這個只建立在團隊成員都非常成熟，產出的程式都非常易懂的情況。但大部分的公司並沒有那個條件、能力、預算請一群頂尖的人才，這時候文件才更彰顯價值。

而寫文件來說，最關鍵的角色就是「產品經理」和「設計師」。看似對程式碼毫無產值的兩個角色，實際上是產出文件的骨幹。需求文字化的角色和需求視覺化的角色，有了這兩個角色才能推動好的產品。如何定義這兩個角色的價值？就是溝通力、文件易讀性、文件細節理解力、成本管控能力。

至於文件要寫些什麼這就是另一個議題了⋯⋯

在鄙視鏈的最下層

竹子日誌（竹子） — Wed, 26 Oct 2022 23:20:10 GMT

這件事其實就是指前端工程師和UI/UX設計師。

我們這兩個職務是新興職務，主要是現在的畫面越來越複雜，難度越來越高，已經不是一個職位能夠去勝任的了，早起還可以讓一個叫「網頁設計師」的職位包辦，但現在似乎越來越難。

為什麼會發展到難以是一個職位能勝任的呢？主要還是因為大家真的被 google 生態圈養壞了，超乎常理的體驗和畫面優化，幾乎是業界的指標。但那個等級，真的不是隨便一個阿貓阿狗你達到的，連我都覺得還有點追不上。實務上，上級也會說「google 可以，為什麼不行？」我心裡默默的說：「因為你沒有拿出google 用人的預算⋯」。其實如果拿10多年前的等級，不需要RWD，不需要複雜的交互，那⋯真的沒那麼難啊⋯但是工程師也不願意做那種落伍沒有發展性的東西。這就是資本高牆，想跟這些資訊界的怪獸一較高下沒那麼簡單。

但也因為上下限太過於巨大，你可能只要會切版，似乎就能當前端工程師。你可能只要會畫圖就能當UI/UX設計師。但⋯⋯這就是入行門檻低下等副作用，變成軟體圈內鄙視鏈的最下層。但大家都知道，事實沒那麼簡單，因為企業的需求本質是商業上的競爭，怎麼可能拿出那種十年前的等級出來競爭？

一個資訊產品的競爭力怎麼來的？

它能不能符合需求正常運行關鍵在後端

它能不能營銷出去賺錢關鍵在商業模式

它能不能讓更多人看見關鍵在行銷策略

它能不能讓人長期留下來並且顯得跟其他競品不一樣，關鍵才在前端和設計

其實它就是一個很軟的東西，不是非黑即白的，我們計較的不是它能不能動。而是它到底帶給使用者什麼？更方便的操作？更絲滑的動畫？更順暢的操作？這些都是要雕琢的。

如何知道知道自己值多少薪資？

竹子日誌（竹子） — Thu, 20 Oct 2022 00:33:57 GMT

我一直有在做教學和諮詢，不少人總會問「我到底該開多少薪資」？

這也許是個千年難題，這會有兩個面向，一個是企業端角度，一個是求職者角度。要了解自己到底能開多少，首先要先知道身為徵才方到底在演什麼內心戲。

在公司角度，第一個問題是我這個職位要用多少預算，企業會傾向找在預算範圍的人。但許多公司不願意說出這個「預算」，原因是因為這是他們談判的底牌，他們也像嘗試看有沒有很划算的人才。當然也有一種可能，就是他們根本不打算真的找人，可能面試了很多求職者後依然找不到他們要找的人後就不找了。可能是覺得市場這種人才太貴、可能是一直遇不到理想的人、可能是任務方針改變導致人才需求改變。

而求職者來說，完全單純看公司環境、條件、薪資明確可視化因素。因為探不到公司預算前提下，你只能用自己預期的金額，如果能知道預算又有不同的策略了。這時單純要驗證個人價值就是「去面試」，不斷面試展現客觀條件，包含經歷、技能、人格特質，隨著你拿到的offer去上修或下修金額。

但這時也會牽扯公司面最在意的問題：「預算」，不同公司願意給的數字是有落差的，有時可以用外在條件去評估。傳產比較不願意給予高額的薪資給一個單一技術職位、融資到A輪後的新創公司更願意用高額來聘請人才、一般的小公司是根本沒有條件和資本來請一個高薪人才，他們要的就是能維持公司運轉的全才人員。

綜合來說就是去不斷嘗試面試，用不同的數字去嘗試不同類型的公司，因為你的類型對於一個公司也會有差異，你可以得到一個較為客觀的數據，這就是你的價值。

寫前端的價值是什麼？

竹子日誌（竹子） — Wed, 19 Oct 2022 10:40:39 GMT

這件事從我過去到現在被一些老式開發者、非技術領導者影響。每個都是用寫了「幾頁」和「美醜」影響。已經有不止一位上級主管質疑我前端能力，他們質疑的標準是：「我覺得你的畫面不漂亮」這種點，我只能說，很棒~

被用「畫面漂不漂亮」評估的前端

不知道有沒有Frontend看到這篇文章，如果今天有人用你的畫面程度來評估你的價值。「我覺得你這個圓角很怪」、「我覺得你的區隔兩塊資料沒有群組感」、「我覺得你的配色很不搭」、「我覺得你的間距排列太大了，這樣資訊會變少」⋯⋯⋯等等奇怪的疑問，所以「你的前端能力不行」這種詭異的理由。真棒～

工程角度的價值，外人看不到

或許你會想說「我的code很乾淨簡潔又好懂」、「我的組件函式複用率很高」、「我的瀏覽器運行效能很好」、「我可以高速建立網站」等等工程角度的技術，但我只能說對外人來看，前端就是一個「畫出可以用的網頁」這樣的角色，你只是一個做「美術」的。哎呀～一秒惹怒前端工程師就這麼簡單～

抽離工程師角色，站到產品設計師的位置

直到最近我開始思考，抽離「工程師」這個角色，我應該怎麼做？當你站上產品設計師的角度思考事情時一切不一樣。你不再想的是「怎麼做出功能」、「怎麼寫好code」，因為這些並不是最重要的，需求端永遠會給你很趕的時間寫不出好code，永遠會給你很難搞很難寫或是根本寫不出來的功能。你要做的是，在「開發成本」和「市場需要」中間取得最大的價值與平衡。

改來改去？超正常的！

期限就是期限嗎？並沒有，那只是有個期待值。（期限這件事這已經可以另外寫一篇了）

那還能為產品貢獻什麼？

那你還可以為「產品」貢獻什麼呢？

寫code到後面基本上大部分的東西都寫得出來，那瓶頸會在哪？更多技術？多學後端？多學系統？大部分的前端工程師確實會這麼做，這也是有跡可循，朝著軟體開發更完整的技術線前進。

麻煩多練習說人話

但依舊沒人懂，你做的到底是為什麼？試問，如何讓一個不會寫程式的理解「前後端分離」、「ESLint風格管理」、「程式碼重構」等等，這些只有工程師懂的東西能講得讓一般人懂嗎？麻煩多練習說人話！並且告訴他們，我能為商業上帶來什麼實質好處，不然⋯⋯再多的技術都是沒價值的。

能力強大沒有比較了不起

竹子日誌（竹子） — Tue, 18 Oct 2022 00:41:08 GMT

有很多能力頂尖優秀的工程師，靠著自身的努力和拼搏走到人生高峰，憑藉著自身卓越的經驗與實力拿到許多的工作機會。然而，並不是每個人都有辦法走到這個地方，不管是人生機遇或是天賦才智。之所以能夠被稱之「頂尖」是因為別人做不到，很難去要求每個人下屬或是夥伴都是成熟、聰明、有才能，更不要去鄙視能力差的人。反而能夠伸出援手去協助、引導、突破的人才不容易，教導他們不斷成長，為團隊帶來突破，這種人更能成為領導人才。

我遇上了不少工程師嫌棄隊友太雷，並不是隊友倚老賣老或是拒絕學習，真的就是「新手」。不少公司其實預算上真的請不起強大且經驗豐富的工程師，剛好就是那間公司比較資深的工程師勢必就是要擔待一點，並不是仗勢自己的能力。既然公司花了巨額的預算聘用你來解決問題，勢必希望你是能夠有高價值的產出，而不是哀怨著環境條件很差。

我向來的宗旨，公司只要允諾應該付給的薪資、不會把加班當作時常態的策略、合法經營管理公司，那就沒有什麼可以稱之有雷的公司。可悲的是，仍然許多公司做不到⋯⋯

公司有公司的問題

工程師有工程師的問題

各自都得去面對和解決

第一次參與 Mopcon

竹子日誌（竹子） — Sun, 16 Oct 2022 06:44:09 GMT

這不是什麼值得炫耀的事，但對我來說是有趣的事。

在這邊跟各個網路上的朋友們在實體互動，看看各路大神站在講台上分享他們的經驗，也看到崇拜的有些知名角色現身實體。

參與這樣的盛事議會，雖然不能保證每一場都可以有所收穫，但每一場都可以去觀察講師們的台風、語速、用字遣詞，每一細節都有對應的價值。

再來也可以去各個贊助廠商的單位，跟廠商交流，埋下一些未來的發展機會。另外就是可以觀察這些廠商來到這活動用什麼樣的手段去找出想要的宣傳效果。

雖然到場的大部分都是工程師，但很有趣的也會有商業人士、設計師、行政人員，每個人有自己的目的與目標。

作為一個UI/UX的面試官心得 ep3

竹子日誌（竹子） — Wed, 12 Oct 2022 03:14:12 GMT

為了找到一個與我合作的 UI，經過了幾場現場的面試，也很順利找到合意的人選。這段過程得到更多的體悟，也發現許許多多的問題，這當然要跟大家分享一下囉！

我設計了一個白板題

我設計了一個白板題。我簡單設計了一個情境，它會是一個簡易的需求，希望瞭解面試者對於需求的釐清能力跟溝通技巧。只能說白版題可以說非常殘忍，把一個人應變能力和經驗值快速榨出來。當然⋯不免有更多更多感觸⋯⋯

從幾場面試裡看到的五件事

這點要很重要，我必須強調！不要說自己很喜歡前端也很願意學習（除非你真的很喜歡，未來真的想轉前端），不然真的很不加分。如果前端強的公司不需要你去切版或寫JS，如果是前端弱的公司就是要凹你去承擔前端相關業務。我在面試時真的一點也不在意你想不想學前端，也不在意你前端能力，我要的是強大的 UI/UX 的實力和產品開發經驗。
事前做功課很重要，懶惰做功課也應該要試探對方要什麼。大部分B to B的公司不太經營自己的官網，通常寫得很簡陋，面試前查不到資料可以在自我介紹簡單帶過，試探性問問公司性質和工作需求，再精準提供自我介紹。有些設計師有10年以上豐富的經歷和多領域技能，但自我介紹全部交代完實在太不現實了⋯⋯超過5分鐘的自我介紹開場聽得人都神遊了。要講對方可能會有興趣的部分很重要！
做一個系統開發來說，牽扯的層面很深，不要只想到表格、搜尋、視覺效果。更有深度的是資料的來源關係、權限不同的呈現的差異、對使用者直覺化的 flow調整，這些都有很多東西可以著墨。其中一個面試者在這塊說明的超詳盡，強烈感受到他的實戰經驗。
大部分的人遇到白版題超驚慌，但慢慢進入狀況可以抓到重點，最重要的並不是你的答案，而是你溝通的方式和詢問的問題，最糟糕的那種是什麼都不問就開始作答。
從白版題能得到很多有趣的人格特質。有經驗的人可以從模糊的問題透過反問來釐清自己要的答案，這個問題的深度也代表著能力和經驗的深淺。善於溝通的人可以讓這個互動加上一些俏皮活潑的對話，讓過程變得不會冷場。創新的人會重新質問這個需求，回歸問題本質去瞭解使用者需要什麼，重新定義問題找出真實需求。有邏輯的人能快速發現問題的盲點，釐清沒給清楚的資訊，找到關鍵資訊。

拿得出實力，很多公司願意出更高的薪水

很多人都覺得設計師薪水不高，但我必須說，只要拿得出實力，很多公司是願意出更高的薪水請有實力的人。最後投意的設計師在洽談中，還不確定是否會入職，但喊出來的數字真的是大家認為的工程師薪資，但我們真心還是想說：「太划算的價格了！」。

重構專案

竹子日誌（竹子） — Tue, 11 Oct 2022 00:31:52 GMT

許多公司聽到工程師喊著要重構都會覺得害怕，重構意味花掉的時間卻毫無產出，甚至可能發生原本好的功能反而壞掉。所以不管你能力多高超，說服企業要重構依舊是不現實的，所以想要讓公司願意進行重構是有其前置作業和必要條件的。

如何才能去說服公司呢？

如果你有技術主管，首先得先讓他知道公司的 code 有多爛多糟糕，如果放任不管是會造成更多問題的。這時你需要提報一份問題列表，詳載著目前專案所有現存Bug、復現方式、解決的利害優劣分析、解決方案、修正需要的時間和專案處理的週期。這時無論上頭是否同意，你可能要偷偷的另外開一個分支進行整理，並寫一份測試報告，有充足的佐證告訴上級可以進行合併。

基本上你就是要非常用力的讓上頭對於重構這件事的害怕降低，並且提高不重構會引發問題的壓力提高（就是恐嚇），這樣才能驅使願意進行重構處理。

但自己真的要審慎評估，一路處理下來，投入的時間成本是驚人的，而且真的是一件毫無產出的事情。如果重構的專案並不是公司產品，而是一個接案公司的案子，那重構價值真的是奇低無比。

身為一個全方位的工程師

竹子日誌（竹子） — Thu, 06 Oct 2022 23:08:16 GMT

一開始進入公司是第一次成為全端工程師，原本我擔心的是，我沒辦法勝任後端的各種 Linux 指令、容器、微服務等架構，我頂多只會改改api。後來我發現，但我的擔心完全是多餘的。因為根本沒有時間管這麼大的範圍。

我接下公司前端的專案後，不但要處理新需求，還有很多很多技術債等著我解決。這些都不打緊，其實一路從需求釐清到出Wireframe具體定義介面與需求，還得要畫設計稿出 Mockup 。許多規劃面的東西都得處理，我得釐清設計系統並重新定義、進行使用者訪談、畫出邏輯面的Flow Chart。

我從不計較這些工作是不是我職責範圍，我覺得這些都是我實戰的機會，也是我驗證實力的機會，我會盡力把握。從找使用者訪談，蒐集回饋。再來是和網路工程師溝通釐清商業需求，並將其流程化、介面化、結構化。再來是製作，極力優化架構、程式品質、使用者體驗。

上一週開會，我被CEO認可我畫出來的稿件是符合他期待的，希望接下來這專案的完成品交出來的是令他滿意的成績。

作為一個UI/UX的面試官心得 ep2

竹子日誌（竹子） — Tue, 04 Oct 2022 03:07:42 GMT

我們公司沒有任何一位 UI，我是首開先例去徵這個職位，因此沒有任何規範可以去依循，我只能自己去尋找面試的方式。加上我本身是一個工程師，如何面試設計師並且吸引他們加入團隊成為我一大課題，絕對不是單純靠薪水高就去這麼簡單。

但過程中我面臨的最大難題就是「如何找到一個有開發過系統產品經驗的設計師？」，就跟如何找到好的工程師一樣困難。雪片般的履歷如何過濾出想要的履歷是一件很難的事，每一份履歷加作品不能花超超過1分鐘閱讀，真的不想浪費太多時間在不漂亮的履歷上，但又怕失去好的求職者。

我設計了一個互動問題，發出模擬真實的需求，提供一個情境讓求職者發問釐清問題。用途是為了瞭解他在需求溝通上的行為方式，和一些人格特質的表現。但我仍然在思考要怎麼去驗證一個設計師的能力值呢？

作為一個UI/UX的面試官心得 ep1

竹子日誌（竹子） — Sat, 26 Mar 2022 01:24:12 GMT

最近因為工作量吃不消，向上頭爭取了一個 UI/UX的職務，也很開心願意開放出這個職缺。

我現在著手處理這個徵才需求，因此有了一些感觸⋯⋯

看完三十幾份履歷之後的八點感觸

社群、朋友、104履歷綜合大概30幾份，客製化履歷很重要，給制式履歷會讓人很快就閱讀不下去，有的甚至要去履歷一串字挖寶⋯⋯這樣好辛苦，但我不想捨棄任何機會，所以我很細心讀完。換作是別人可能就刷掉了。
如果大概調查一下會知道我們公司是做資安網路相關或是做系統的，這類的產品要的不是絕倫的視覺感受，而是優質的體驗和具備邏輯性的設計。許多公司要的其實是這類型的設計師，但是市場上很缺這類型的，因為大部分設計師都把重心放在視覺表現而不是體驗分析和功能分析。所以作品不要清一色都官網或電商，有時加一點醜醜的系統類的也會吸引到一些系統類企業的目光。
Component 並不是拆出來有使用這個功能就叫 Component 。而是能清晰表示「狀態」。假說一個按鈕，它不是只有能按和不能按，還有 Focus 、Hover、Loading、Active多種可能。還有頁面處理一般的版面還有沒有資料和資料過多的情況。
許多人有畫 Functional map，但很多人不清楚那是什麼，結果畫了 site map。其實畫出來很棒，但Functional map很重要，一定要嘗試去畫分析圖。User Flow本身圖形是有規範的，不要亂用圖形或自創圖形，這樣顯得很不專業。
使用者調查分析和 wireframe 很多人都有畫，比起以前看到多很多，代表這個觀念逐步成熟。但有的人畫的真的太花俏。實戰中真的沒有那麼多時間去畫這麼細緻，還會模糊長官的焦點（這些長官就是這樣，永遠不好好看你想給他看的東西）。
不管是 AI、PS到現在的Figma，為什麼圖層跟群組都不好好命名⋯你知道這份設計稿後面的人接手看了多心累？
CSS不是必點是加分，不要弄錯重點。會一點 CSS 和 jQuery 千萬別說自己會前端，要不會讓你去要自己切版的公司，要不會讓你反而被好的公司刷掉。包含說熟悉敏捷開發、程式語言什麼，這些不是你專業的東西（真的很厲害另當別論），因為你的重點是UI/UX啊啊啊啊！
多多觀摩一些大神的 Figma，不要老靠自己憑空想像去畫，厲害的設計稿真的是一看就看得出來。細節差超級多！

圖表系統開發經驗

竹子日誌（竹子） — Sun, 13 Mar 2022 01:41:14 GMT

一開始，CTO想要做一個 Event Time Line Chart，但具體分析完需求後，他想要呈現的資訊實在是太客製化，為了能滿足需求，勢必要自己刻了。

工程師都知道，沒事不要造輪子，但遇到極端客製化的需求怎麼能夠不造輪子？我也只能選擇跳下去和 Canvas 搏鬥了。首先肯定要挑一款合適的框架讓我開發，考量過 ”

pixi.js”、”p5.js”、”create.js”、”paper.js”，最後選了”pixi.js”，這下真的要開幹了。

原本覺得在 Dom 上理所當然的東西，到了 canvas 整個都不一樣了。包含著碰撞、渲染、組件化，每一個畫面的展現因為沒有了CSS，全部都必需用數學算出來。真正體驗到，到了 canvas 需要數學去支撐程式設計力，越複雜的圖形越需要去設計圖形計算的公式。

到了開發後半段，面臨了另一個大問題

我是如何變成前端工程師？

竹子日誌（竹子） — Tue, 08 Mar 2022 14:48:47 GMT

學校畢業後我第一份工作是去當職業軍人，經過六年的軍旅生涯退伍後，當然最大的煩惱就是未來該做些什麼。

一開始時幹的是保全相關職務，心想我必須要證明自己退伍後可以活得更好，一面工作努力養活自己不要揮霍退伍金，一面玩著傳直銷希望能透過它賺到些錢。既然要賣些什麼，我會去思考一個推銷產品的流程隨著，思考並推演可行的做法。隨著思考和嘗試，我理解到必須要學會網路行銷推廣產品，最後我在這過程中認識了 Wordpress 。

從 Wordpress 開始，然後被 CSS 卡住

我規劃了一套屬於自己的產品推銷的漏斗，用 Wordpress 建了一個屬於自己的部落格，弄了一個一頁式的產品行銷網頁，搞得有一個起頭的樣子。然而只是做出來是不夠的，接著會想，我應該讓頁面更漂亮，下一步就是要學 HTML 和 CSS 了。但是網路上的資源之凌亂，這學習的過程真的是坑坑疤疤，簡單調整一個顏色讓我搞了好幾個小時，這時我想要有一點系統的學習，我花了錢去巨匠學習如何切版，而且還是學「float」這種古早味的切版模式。但學習到了「入門」和基本的學習資源搜尋這關鍵技能後，我覺得對我自學能力又多了一分突破，某種層面也是一種開始，就著樣栽入網頁製作的世界。

上完三個月套課，其實我什麼都不會

上完了3個月的套課，其實我仍然什麼都不會，最多也只是能切出粗糙的版型和用 jQuery 做出基本的互動，連什麼 RWD 都是懂非懂。學習沒有捷徑，我也只能開始我的瘋狂的練習之路。下班後其實已經超級超級疲累了，要能堅持學習是一件極難的事，我只能拖著疲憊又有點想打瞌睡的狀態持續學習。除了下班，假日或其他各種休息時間一面堅持要寫文章，一面還得練習網頁撰寫，研究各種想達成的功能。

自學一年半，還不知道有這個職務

就這樣輾轉過了1年半，中間換了幾次工作，也放棄了原本開始寫網頁動機的直銷，甚至跑去和朋友創業搞有的沒的。經歷在職學習的漫長路程，一步步熬過跨領域困難，甚至當時我跟本不知道有一個職務叫「前端工程師」，我抱持著對於這門技術學習的堅持。我用盡當時會的技術嘗試去寫一個網站，自己租了一個伺服器和網域，把資料上傳到cPanel，我連什麼是 github 都不知道。

破釜沈舟的海投

終於到了某一天我知道了原來這是一門工作，當時我創業失敗過得正痛苦，資金和債務問題接踵而來我只需要一份工作。我當時根本沒考慮過公司的好與壞，我只知道，我要找到工作，抱持這樣的決心海投履歷。帶著破破爛爛的作品，當時我css只會 float，js只會簡單操作 jQuery，不要談什麼物件陣列我根本不懂，薪水鎖定在大台北30k~35k這樣的低水平，抱持破釜沈舟的心告訴自己一定要找到一份前端工作。我借了一台學生用的破爛筆電，免強能讓我DEMO作品，履歷粗糙的寫了一份，一次次的面試就這樣衝了。當時我面試了很多間公司，每個都因為我沒有團隊合作經驗和能力不足甚至不會框架打槍我，也犯了許多現在想起來很糟糕的求職大忌，但我依然堅持去嘗試。我從台北中心投到內湖，東從汐止投到西邊的林口，北從士林投到南邊樹林。反正無一不投，只要有機會我就去面試，薪水什麼我根本不在意，公司說要加班要砍價我根本無所謂，我只知道我要轉職成功，先拿這張門票。

32k 的 offer，前端之路的起點

我下一個階段就是從前端新手成長到 Junior 的道路，然而，真正的困難也才正要開始…

尋找遠端工作

竹子日誌（竹子） — Tue, 08 Mar 2022 14:47:19 GMT

繼上一篇從前端新手成長到 Junior 之後，接著又發生什麼事呢？

躺著養傷，還是每天寫程式

受傷後的第一個案子，和遠端復工

當我自己開始工作後，剛開始是很開心，我終於有一份工作，但這也是疲憊的開始。我離開後，老闆尋找前端工程師一直不順利，所以在極缺乏人員資源的情況下我用遠端的方式回到工作崗位上。

從無聲卡到國外遠端的 offer

之後的一段時間，我過著自由自在的遠端生活，很開心能來到這份工作。理想的薪水，自由的遠端，壓力不大的工作，我非常開心！

創業

竹子日誌（竹子） — Sun, 06 Mar 2022 13:51:30 GMT

當時我還在物業公司任職幹事，畢竟是大公司，職場爭鬥都是難免的。但當時我有一群共患難的好夥伴，我們一同打拼完成我們的工作，加班一起加班，遇到困難共同克服。

後來因為內部鬥爭，離職的離職，調職的調職，我當時就覺得失去工作的向心力。

就在這時，我一個很要好的朋友，熟識15年未曾斷聯的好兄弟邀請我去他的公司上班。

先說說多多這個人

先說說這個朋友吧！他叫多多。

多多曾經是空軍士官，但因為一場車禍，他摔下山崖底下的河床，當時送醫搶救。後來插了葉克膜急救，險些喪命。康復後他復健非常順利，但是也因為肺部嚴重纖維化，被軍中驗退。

沒了穩定的工作，他獨自去台北發展，做過傳銷，做過業務，做過少爺⋯很多奇怪的職業。一切不穩定，但他獨自打拼，他也交了女朋友。後來他認識了一個大陸人，叫阿哲，很聰明很心細很有義氣。多多把他之前投資的股票都賣掉，和他一起創業，做一個品項叫「木藝品」，專門做像是「小葉紫檀」、「崖柏」、「金絲楠」這類的稀有木品。在台北松山開了一間門店叫「墨格藝品」。

事業不一定都是順遂的，但是總體來看是往上提升的。直到累積了200萬的資產，他們轉向投資了一個品項，自動販賣機商店，產品是成人用品。包含找產品源、資訊系統整合、營運規劃等。他們半年找投資人開了5間門店，事業有聲有色，也和台灣的情趣用品龍頭「阿性」談合作。

22k 的薪水，和「拼一次不後悔」

在一切順利的這時，他們想進一步擴編，先找了我想一同努力。我有猶豫，但是他們的成長和品項的類型都十分有趣，經過考慮我願意加入他們。但我知道，他公司正值起步，我只拿22k的過活薪水，他允諾我公司賺錢把差額買回乾股給我，我道義上挺他。實質上，我想要夥伴努力朝向同一個目標前進的感覺。明知道這薪水生活根本過不太去，但是我算了算積蓄，應該可以撐一年，所以我決定拼一次。

人生就拼一次不後悔，我當時就是這樣想。

在我原離職前，下班我都跑去他們辦公室幫忙。架設網站、整理報表、清點貨品，希望自己能盡快熟悉工作，真正的幫上忙。

表面上我朋友是老闆，所以我也不太在乎他怎麼做，畢竟能走到這步，做的每一步或許都有其道理吧！我就忙我能夠幫忙的，盡力協助。但此事我看到的是，看似已經有一定體量的公司，內部的制度、流程、表報、紀錄、模式，什麼都沒有，我告訴自己：「這就是創業，從零開始吧！」

看似有體量的公司，其實什麼制度都沒有

我們先招募了一批業務，開了兩場招聘說明會，我和一個同事叫小A，規劃整個活動的時程、道具、文宣、場地⋯。

而大規模的舉動非常燒錢，我也盡快去拓展業務。包含跑商會，陌生開發，四處宣傳產品等等。內勤部分，我把網站架好、跟外包工程師對接修復系統Bug、製作行銷企劃書、業務任職前文件製作。設計說明會簡報。例行性的有月報、補貨補錢、跑銀行⋯

接著，業務進來了，我們辦教育訓練，教導業務熟悉產品，我們研究產品特色，找出差異化來作為引導。建立業務信心、規劃行銷受眾、從社群進行品牌形象的規劃。我們也租了一間像個樣子的辦公室，客人來就有比較像樣的門面。

基本上我們的品項是屬於B to B性質的，除了產品是成人用品，我們的販賣機也是各類產品的載體。所以也報名下一個季度的加盟展，這部分也得著手準備。因為產品延展性的優勢，我也發揮我的經驗去規劃產品的開發方向，我和工程師協調，預備進行研發。因為後面的需求，我也進貨大陸主機，處理相關貿易、海關報關、廠商協調等等事務。

而我們也有現有門店，當初這些門店是多多找我安裝電力系統的，所以我也頗熟悉。門店的維修、保養、打掃、貨管，都是我跑現場處理的。這部分我也全權負責，有問題就回報，不能處理就打電話聯絡外包或廠商處理。

等等事情可以說是非常充實，簡直是忙翻了呢⋯⋯

一切好像將要開始，一切都抱著期待，踏上一條不讓未來自己後悔的路。

團隊裡的每個人，都在忙自己的那一塊

小A和多多共事最久，他們不單單是同公司的戰友，也是親兄妹。雙方只能說是太了解對方了，小A她不會計較太多，總是背後默默的推著多多前進。她更知道，不是時候也別強求，放著也才不會帶來更多的麻煩。

小A被找來已經共事半年多，許許多多基礎業務都是她建立起來的，阿哲和多多不時會他要忙著木頭店的生意，因為那是他們接觸的財源。所以無人販賣機店的大部分業務都是小A包辦，包含財務、貨管、營運，都是小A一個人處理。她默默的持續做下去⋯⋯直到我來了，替她分擔了部分工作。

阿哲畢竟是大陸人，基於法規，還是有許許多多不方便，想拘留在台灣有許多限制，他是用讀書的名義來的。他要撥時間弄論文、要照顧木頭店、要聯繫工程師、要談判一些業務和合作。真的很忙碌⋯⋯

領導業務的是另一名有入股的股東，他叫大銘哥，是個個性直爽的大叔。我不是很喜歡他，我跟他講話總是不太合，但他依舊是個長輩，用長輩的角度說話。不過老前輩終究是個老前輩，還是由許多人脈和獨道的經驗。對他還是多尊重多忍耐點，畢竟未來還得靠它呢⋯⋯

一次的內部會議中，我們正朝著該如何擬定方向和策略，但是意見有了分歧。阿哲站在踩穩踩實的立場，多多站在放手給業務們衝刺，沒有誰對誰錯，但是多多意氣用事，鬧脾氣了。這一氣鬧了兩三天，多多愛做不做，也不準時上班，這氣氛僵了。我是他的好朋友，我去鼓勵他，我去叫他起床一起進公司，我和他一起去跑客戶，希望一切都好起來。不因為什麼，我相信，我也看過，他只是暫時的情緒而已。

一切都只是過渡，雖然有點困難⋯⋯有一點沒有團隊共識？但似乎單純只差什麼？我可以盡力協調，我可以當其中的潤滑劑。我還是能付出些努力去兩邊溝通取得平衡，團隊還是必須走下去。

新辦公室的落成，官網的完成，業務們開始帶回了客戶資訊，一切好似踏上軌道。我們每月召開例行的股東會，雖然我不是股東，但我是核心的營運成員，想然爾也參與。我不發表太多意見，因為我手上沒有股權，更沒有發聲權，我做一個秘書，替大家完成會議紀錄及各項文書表報的整理。

然而，我沒有想到今天是我最絕望的一天。

「倒就倒啊！我又無所謂。」

多多已經消沉大概一個月，我每天早上上班前去他家叫醒他，我們一起進公司，一起相互打氣。我跟他是多年的好兄弟，密不可分，這患難情感，共同努力共同玩樂，許多年了。我多麼嚮往著跟兄弟一起打拼事業！等著這一天⋯等了好多年！

今天，小A主持會議，會議非常不順利，阿哲和多多依然在吵架⋯⋯多多索性不說了，和大銘哥兩人跑到客桌泡茶，對於會議簡直不在乎。正當我傻眼和無奈之下，小A問了多多：「如果我們公司找這樣發展下去，資本很快就會燒完，這時怎麼辦？」

阿哲不語，大銘哥回答：「真的很可惜⋯，頭都洗下去了，還是得做⋯」

多多卻這麼回：「倒就倒啊！我又無所謂。」

⋯⋯

這時我深深被打擊，當初找我的是你，現在無所謂的是你，現在重要會議，還這麼無所謂？

原來⋯⋯友誼這麼脆弱⋯

原來⋯⋯你的努力和成就如曇花一現？

我那一剎那，有種被欺騙的感覺⋯⋯

我放下工作用這麼低的薪水與你奮鬥⋯你竟然比我還不在乎公司？我真的覺得難過⋯

隔天，多多找了全部的人這麼說：「我手上和阿哲手上三分之一的股份都給小A，她才是最了解公司的，交給她運行公司做決策吧。阿哲學業即將結束，年中就要返回大陸，長遠來看，要有合適的人隨時管理著公司，小A是最適合的。而我⋯⋯公司現在的營運越來越不樂觀，我們必須要有資金才能繼續生存，目前還缺規模性的拓展，我會再去找金援和業務，短期內會不太進公司。」

從那天起，多多不再進過公司，我也沒有再去他家找過他了⋯⋯

阿哲把股權全讓出來，自己什麼都不拿

由於營運困難的狀況，我們遣散了一些產值不佳的業務和沒有意願努力的人。

這時阿哲端出最終殺手鐧，他比誰都不願意努力付出東流，但卻願意讓自己受到最大的傷害。他說，年中他將要結束在台灣的日子，來台灣拼搏那麼多年，他也不後悔，每天為這些利益的東西失去多多這兄弟，聽不划算的。吵架歸吵架，阿哲還是挺掛念和多多這段時日拼出來的功業與情感。

所以阿哲提出：「我把股權轉讓出來，公司不再發薪水直到六月加盟展結束後的第二個月。這時把我手上全部的股份分出來給願意付出努力的成員。」

沒錯，阿哲什麼也不拿，那些錢就當灑了。

當然，也因為私心，我被配到的股份比例是最高的。這些可真是名副其實的乾股，但也要公司賺錢啊⋯⋯

小A和阿哲問我，還願意繼續努力嗎？

小A這樣說服我：「我知道你是因為多多才進來我們公司，現在多多不在了，我沒辦法說服你留下。但我知道你一直項挑戰這一切，創業這件事你還是有期待吧？過去做的事情可能都是錯的，所以你可以當作我們什麼都沒有從零開始，沒錯！你就當作是創業吧！以後每個公司的決策你都有一份，你就是公司核心的營運成員，我們用現有的基礎開始，其實我們成績也不差啊？」

對，或許我不想後悔，所以我決定跟了這樁賭局。現在想想我當時真的是瘋了⋯⋯

我們最後留下的人有小A、大銘、我、業務阿堯、業務小賴。阿哲因為還有他的學業和木頭店的事，所以忽略不計。

我們共同的目標是六月中的夏季加盟大展，我們要把我們的自動販售機以連鎖加盟店面的形式推廣出去。緊接著我們展開一連串的規劃，把我們的精神力與全力放在這波，無論如何都必須做出些什麼成績。

鴻緯集團進來，和格局差異的震撼教育

首要的問題就是資金，正當瀕臨危機的一刻，我們得到了鴻緯集團董事長的青睞，他們隨手一揮就買下我們30%的股份，資金問題瞬間得到舒緩。

大公司在做事不小家子氣，和他們總經理開會徹底體會到我們跟他們的格局差異。所謂「我們不賺小錢，要就是要玩大的」，甚至把銀行的錢當自家的金庫，開口閉口就是那億來億去的投資。被他們震撼教育後，我們改變了思維，修正了我們的企劃和專案方針，針對這次加盟展做不同格局上的改變。在加盟展前總是得做一些事，我們依然推廣產品並展店，畢竟我們的價值體現在店家的數量。

展店同時，除了新機的裝機與軟體系統安裝外，這時舊系統頻繁出現Bug，我和工程師合作想辦法排除，這些惡根都是過去就種下的，但都沒有被妥善處理，我們必須要在加盟展前全數解決。另一方面，我也用剩餘空閒把系統的簡體中文字繁體化，畢竟原先是大陸某公司釋放出來的後台系統，並未給台灣人完全相符的介面。

緊接著，還有前台人機介面的美化、金流支付系統的串接、銀行系統的串聯、電子發票與稅務問題、硬體替代來源、擴充設備安裝⋯⋯要面臨的困難，法規問題、技術問題、資金問題比想像中多上太多太多。這時才真的覺得時間不夠，公司內部沒有真正意義上的工程師根本就是致命傷⋯⋯常常必須要與外包廠商協調，外包成本、配合時間、研發週期，通通都讓人崩潰。我好恨自己，為什麼沒有研發能力？我好想好想自己解決這些技術上的問題⋯⋯我不過是個公司和工程師之間的傳聲筒。

小公司勢力單薄，需要更多更多的異業合作。同行的，相關行業的，各種我們都四處找可以結盟的對象，不免也遇到不少妖魔鬼怪。很慶幸結識了阿法碼科技，他們CEO全力幫助我們開發機台的插件，更進一步提高了機器的延展性與便利性。也藉由這個新開發的商品，我們也能跟許多供貨商合作，大大降低產品的出售成本，我們在最後一刻又再推出不同的方案。

因為多多是公司負責人關係，現在要做股權轉讓以及新銀行開戶，必須找他回來辦理。我就在這時和他聊聊，他說：「對於我的行為我感到抱歉，我希望我們不要因為這樣當不了朋友，換個角度說你也很感謝我吧？是我創造這個舞台讓你可以發揮～不然可能都還在普通的公司上班呢！」

這時聽到這種話真是五味雜陳⋯⋯

加盟展就快到了⋯是好是壞看這次，因為沒有領薪水的關係，我的存款以飛快的速度見底，真的是背水一戰了⋯⋯

因為身上錢真的不夠了，剛好租處也到期，我索性搬去辦公室住，把全部清醒的時間都拿來工作，再怎麼樣都最後一刻，我不想後悔！

四天加盟展，和見底的存款

我們很興奮，加盟展到來了，準備了那麼久終於迎來這一刻。為期四天的加盟展是我們的生機，我們找了工讀生、熟識的業務、合作的廠家，大家目標一致，就是幹好這場展覽。

第一天設備還出了包，臨時沒有機器可以用，當機什麼⋯這我之前從未預料。我迅速調用店面的機器來展場才化解這個危機。

不過也有令人開心的事，依然有新聞媒體注意到我們，無償採訪我們，再一次有了曝光。

所以，我們成功了嗎？

說到這，其他其實不重要了。累啊！努力啊！都是屁話，商場是最殘酷最現實的。結果來說就是失敗的，我們依然沒有取得全面的成功，甚至是加盟展結束後最後留下來的業務大分裂，阿哲也即將搭機回大陸，團隊徹徹底底的破滅！

團隊破滅之後，我進退兩難

大銘哥一個堅持，他說要把辦公室收掉，撤去股東公司的共同辦公室。而且還得2個月我才能拿到薪水，但我現在的存款只剩省吃儉用的吃飯錢了⋯⋯我急忙打包我在辦公室裡面的家當，大多寄回去南部老家，和大銘哥協調有沒有辦法幫我解決我的問題。他表示，他能做的只有借我錢放租押金再撐兩個月⋯⋯

我陷入猶豫⋯進退兩難了⋯⋯

我再撐⋯能如何？

我不撐⋯那我之前的努力呢？

我猶豫了很久，連續好幾天睡不好覺，我邊收拾著辦公室的設備邊收拾自己的行李，看著手機裡的房屋出租的列表，我不知道該怎麼辦，我是該做個選擇⋯⋯

加盟展結束，公司依然需要營運，我其實已經近乎精神潰堤，失魂落魄的處理後續的東西。包含客戶追蹤名單、合約文件，已經基本營運的例行公事。然而，我不知道自己在做什麼⋯

我反問自己，我想要的是什麼？

其實⋯⋯

我發現我想要的東西一直都在⋯⋯

我沒事跟人家搞什麼東西⋯

蠢死了⋯⋯

我和團隊的人告別了，我該為自己著想了。

我精算身上剩下的錢，還夠撐幾天，夠吃飯了！我先把可能還會需要的行李寄放在台北的朋友家，然後回到老家，把行李做個打點。

接著我要怎麼辦？

我要成為前端工程師

沒錯，我要找工作，我學了1年半的網頁技術是為了什麼？我不再遲疑了！

我開始瘋狂投履歷，我的目標只有一個。

「我要成為前端工程師」

就這樣單純的決心，我回到台北，清空家裡所有僅剩的資產及立即可變現的東西當作租房子的押金。我寄宿在女朋友家過，被她罵到臭頭。我也有借了公司的商品倉庫能臨時躺著，最少在累的時候有地方可以歇腳。

我只花三天找到了一間在板橋的6坪小套房，我開始搬運我的行李，中間的空檔就是做作品和寫履歷，有面試就去。大概花2週，我終於找到了工作！

沒錯，某種意義我找到了理想的工作。

這時才覺得，當員工真好！

從前端新手成長到Junior

竹子日誌（竹子） — Sun, 06 Mar 2022 13:51:05 GMT

繼上一篇我是如何變成前端工程師？之後，接著又發生什麼事呢？

第一份工作：什麼都要學

第一份工作拿了 32k 薪水的 offer ，我開始了前端工程師的道路。實際上了工，依照我的能力工作內容是設計做圖和前端切版，慢慢從我能做到的工作去執行工作。後來又有了PM和設計加入團隊，他們們可以說是專案的核心，所以只要是他們兩個開口我都要想辦法，沒有所謂做不出來這件事，極力要求自己的切版能力和程式能力。甚至後期我要學後端，當時是使用 C# ，不時也要幫客戶去資料庫查詢改資料，什麼都學。最特殊的是，公司是有導入前端框架，但並非大家熟悉的三大框架，而是一門冷們框架，我依照公司的要求學習並且使用。

我當時的生活大概就是上班工作，下班吃飽了一直在學習，不管是找 youtube 的影片還是讀文章，不然就是去看原始碼和練習寫輪子，放假也是泡在寫程式上面，平均一週扣掉上班也花上超過30小時在學習上，就這樣堅持到快一年。當我第一份工作越來越感到艱難，不止越學越多，薪水還卡在超低的水平，公司沒有更充足的資源讓我學習前端，我知道我要前進必須轉換環境。我發現我根本不懂 JS ，我也發現我用的技術和現在主流的前端界脫節，我必須自己獨立學習。但是，找下一份工作勢在必行。

用冷門框架，在面試裡等於什麼都不會

我又再一次去海投履歷，我發現我遇上另一個困難。我依然被判定完全不會框架，因為我使用的是冷門框架，等於什麼都不會的新手被看待。我知道我必須去學習框架，經過多方爬文，我大概知道我要去學 React ，但根本沒人教我應該學什麼 hook API 我硬著頭皮爬官方文件學 Class Component ，我真的覺得好難好難。可能有人覺得我可以去買課程，但是我根本沒有錢，要還債務和台北的房租，我32k 的薪水根本就吃不消。

拿 node module 當教材，死嗑每一行

很幸運找到第二間，也很不幸很雷

很幸運的，我找到第二間公司。 也很不幸的，我找到一間很雷的公司。

我到了一間10人左右的小公司，薪水台北是 40k。

大家心想，沒有前輩教嗎？

然後我車禍了

我車禍了，左腿閉鎖粉碎骨折斷了三節，進醫院躺了整整一個月難以動彈，我接下來該怎麼辦？

設計要不要懂前端？

竹子日誌（竹子） — Mon, 21 Jun 2021 04:45:20 GMT

講講我覺得對於設計要不要懂前端

(我是前端)

設計的知識領域已經是一大塊了

還要懂前端?

換做是前端相信也不希望老闆要你去寫後端要你修伺服器吧…

我同意會限制設計發想與創意

但是設計階段為什麼要煩惱這種事?

搞不好你們家前端是大神(大部分不是…)

那不懂對方領域不知道能不能實現麼辦?

就是尊重和溝通

不要一天到晚互相質疑

前端: 為什麼你畫這種東西?做不到啊!!!

設計: 為什麼你做不到?你工程師ㄟ~

那這樣沒完沒了…

所以前端應該提出解決方案

設計從解決方案找出妥協點

阿如果遇到真的能力不到或不願意做的前端?

我說句坦白的

加入設計是為了畫面不要出現”工程師美感”那種東西

而不是真的要多新穎

所以訴求只是維持畫面基本的色彩和間距平衡

老闆真的想要畫面多美???

如果你初入行到中小公司上班

老闆最在乎的是時間成本CP直

那你去提高工程師的開發成本根本反其道而行…

所以才有設計師要懂前端這種說法

結論:

你該怎麼做?

看公司#

老闆希望畫面美一點，願意付出成本

恭喜你，去要求你們家前端做出來

反之

老闆覺得出來就好，而且要快!!!

那你真的要懂前端

思考如何把開發效率和速度最大化

［自律與學習］

竹子日誌（竹子） — Sun, 20 Dec 2020 18:17:33 GMT

我認識這麼一個人。

每一日六點半就會起床，日復一日無一例外，數年來都是如此。每一天總是會規劃每一天要做的事，大的包含備忘錄，小的包含時程紀錄，並且遵循與執行。

對時間的管理做到一個極致，對於它來說無論是吃飯、坐車、休息全部無一放過，每一個時間段都有其發揮最大價值的方式。

在它眼中，鎖定的目標無一放過，拼盡全力，總會掌握者9成的把握去面臨考驗。

人類之所以能凌駕於一切生物成為地表的霸主，並不是擁有強勁的體魄，也不是擁有堅韌的生存能力，而是因智慧而有身為人類價值。

每天嚷嚷要改變，但依舊圍繞著自己眼前的東西。活在世界上除了滿足現狀的美好並且去珍惜它，另一種生存方式就是汲汲營營追求自己想要的目標與生活。但許多人承認自己選擇了前者，自己滿心想著要追求更好的生活，卻沒有辦法為自己更好而付出對應的代價。

很多人問我，為什麼我能夠學習那麼快？我並不是天才，沒有辦法學什麼都快，真正的天才我根本無法觸及，我只是比別人花上更多更多的時間而已。當我想學一個新技術，我會每週扣除上班還會花上超過30個小時的時間去鑽研，從生活中固定的行為中去擠出更多更多的時間。片段也好，完整也好，就是像擠牙膏一般。

目標是拿來達陣的，與其說目標很難之前，先問自己，是否已經付諸行動去執行？有些事情不求天賦、不求先天優勢、不求基礎能力值，在這之前付出多少努力了呢？在這之前執行了多少了呢？滿嘴的藉口聽起來只是讓自己更顯得醜陋而已。

［這就是硬門檻］

竹子日誌（竹子） — Sun, 20 Dec 2020 17:43:51 GMT

隨著零工經濟與斜槓青年的概念興起，一個人擁有多種技能也不是什麼奇怪的事情，現在的年輕人樣樣都得學，包山包海包了一條龍，十八般武藝樣樣都得通。

那這樣誰被衝擊？因為補習班、教學課程、影音串流等平台的普及，學習一個新技能已經不是什麼新鮮事，各方技術人才如雨後春筍冒出來，後浪濤濤推著前面的中年人，原先在自己領域耕耘多年的人不在安穩，隨時面臨著挑戰。

那有哪些領域飽受挑戰？

音樂、設計、影像、演藝⋯⋯凡是你得到的接案者都是，後面竄出來的人不斷冒出來，同業的競爭也不停攀升。

要跳出這個競爭迴圈唯一的出路就是要擁有自己的產品，而產品並非一朝一夕的，一項產品是經過打磨與琢磨的。

然而我從事的軟體業也是接案領域，但也是在這些領域相對衝擊之下較小的。但也隨著網頁所見即所得的系統誕生，我所在的網頁製作領域也受到影響，因為建站的門檻的降低，導致許多半路出家的人開始做起這門生意，殺紅眼的價格屢見不鮮。

但差距也是在這，現代移動端與系統需求的提升，所求功能極致追求客製化與細緻化。這也使門檻再一次被拉高，不但進入門檻上升，技術的迭代更新速度越來越快，學習慢的人迅速被淘汰。能夠根本熟練掌握技術核心的人才能快速學習投入應用，把這個門檻以指數的速度往上堆疊。

然而，這些都是硬門檻。

缺軟實力表徵的是天花板，可以透過時間去淬鍊，培養觀察力、直覺力、創造力。那種行業中的素養都是培養出來的，讓自己更加具備同行中的競爭力。

硬實力表徵的是門檻，未達門檻很多東西是連實現都沒有辦法，不再是「做得好不好」的問題，更殘忍來說是「做不做得到」的問題。

硬技術的關鍵在於學習速度，越是需要理解深層的技巧，更考驗一個人的適應與學習力。

工程師領域從來不怕別人來搶自己飯碗，自己能夠毫不吝嗇分享自己的技術，不怕你來突破這面硬門檻，只怕你中途放棄。

［什麼是前端技術？］

竹子日誌（竹子） — Sun, 20 Dec 2020 17:33:57 GMT

現在我致力於前端工程技術，它是近十年來興趣的一項分工。原先前端工程師前身是「網頁工程設計師」，但隨著近代對於我網站、手機等等使用者端的需求提升，過去的網站技術已不足以滿足現在的人了。漸漸的，細分出前端設計師、前端工程師、後端工程師，衍生出更加複雜的開發流程。

前端工程師負責什麼？凡指網頁瀏覽器發生的大小事都算是前端領域的東西，往前至使用者介面美化、體驗感優化、與前端設計師密切搭配構建更美的畫面。往後至伺服器溝通與資料傳輸，組合、串接資料流，以合理的方式呈現在網頁上面。

上面講的都不懂？沒關係。

簡而言之就是製作網站的軟體工程師。

［區塊鏈］

竹子日誌（竹子） — Sun, 20 Dec 2020 10:17:31 GMT

之前都講到人工智慧了，不得不談談近年最大的世紀詐騙話題，區塊鏈。跟我談區塊鏈之前，請先搞清楚原生區塊鏈到底是什麼東西？它的原理與解決方案是什麼？加密貨幣都是區塊鏈的衍生物，但它本質究竟是什麼？

區塊鏈又可以說是分散式帳本，是一種防偽技術。透過將資料分散在每個用戶端，已達去中心化。要取得對應的核心資料要使用密鑰取得，每個使用者保管這獨一無二的密鑰，透過哈希雜湊防止反解密，讓這層電子防護達到更精密的保護。

而我們熟知的加密貨幣又是怎麼回事？像是比特、以太⋯這些東西，其實只是讓每一個人在分擔這些帳本處理的運算。因為去中心化，沒有了核心的運算者，為了報酬這些替系統運算的人給予的貨幣，而這些貨幣其實本身是毫無價值的數字。

但為什麼他們有實體價值？舉例比特幣，它因為它的限量發行，導致它不會發生「通貨膨脹」，而且去中心化，不再受中央金軟機構干涉，而成為「貨幣」很好的本質。剛開始只流通於網路交易與黑市交易，但隨著生態圈的興起，「貨幣」的價值取決於交易的需求與供給之間的比值，隨著比特幣產量下滑，市場交易量的商上升，以致價值節節攀升。

最終，加密貨幣只是一串留存網際網路的代碼，它本體是「毫無價值」的，它的價值是「被承認的價值」，成也去中心化，敗也去中心化。不被認識甚至不被承認的加密貨幣根本一文不值，沒有任何人能擔保，即使流通於交易所也沒有辦法提高價值。每一枚貨幣本身要有被「使用」，要有絕對的被使用價值時，貨幣本身才是具有價值的面額。

區塊鏈本身並不是很困難的技術，網路上琳瑯滿目的教學與函式庫可以輕易建構一套貨幣。再來就是燒錢的維護與發行。維護需要有運算點，要建構其生態圈，為了發行時有等量的價值，必須有對應的擔保，要有相對應的資金。

洋洋灑灑又廢話一堆⋯⋯

工程師做久了越來越愛打字了⋯⋯

［奇葩剪接價格事件］

竹子日誌（竹子） — Sun, 20 Dec 2020 10:12:00 GMT

這件事是從某YT開始，現在網路上開始炎上，其實當事人講的是許多人的心聲，從單純同溫層的取暖地圖炮到整個生態圈炎上。

我自己也是技術工作者，也是接案工作者，我能理解被壓價格的感受。但這些都是市場機制的選擇，必然的。

尊重專業？為什麼不先問自己，在市場上，自己的專業值多少錢？你引以為豪的專業是「專業」還是人人都會的「通識」？

現在隨便一個人都可以用FC和PR剪輯上字幕上綜藝字。

現在隨便一個人都能打開PS和AI畫圖排版。

現在隨便一個人都能用WP、Wix架網站。

現在隨便一個人都可以買工具在家DIY搞裝修。

現在隨便一個人都可以管理社群寫文案下廣告。

以上這些事我都做過都玩過，整個生態圈就是這樣，你所自以為的專業就是這麼不值。

當然要更專業的自然有對應的客戶群，多少預算做多少程度，因為有程度的自然不願賤價，程度不足的自然會壓低自己的價格。

客戶是需要溝通的，價格是談出來，我做網頁從不是很懂就開始接案，一直到把它當職業，我的價格也不斷上升。客戶找便宜的自然有它的風險，你不需要賤價。但為了飯碗，誰不低頭？這個叫供過於求。

商場上不跟你談什麼專業。

商場上不跟你談什麼行情。

商場上不跟你談你的生計。

商場上不跟你談你的標準。

現實就是：解決方案在哪？能不能有收益？

尊重專業根本就是烏托邦的想法

社會是殘酷的，現實的

只有去接受它面對它尋找解決之道

提供超越別人的「價值」就是生存之道

當你只有勞力價值，跟那些160元的工讀生有什麼不同？

人家便利商店大夜班都還比你更多錢

我依然每天辛勤學習新東西

保持在社會上角逐的競爭力

我沒辦法成為金字塔頂端

但我會努力生存找到自己的存活之道

共勉之

工商：本人目前致力於網站建置技術

［人工智慧］

竹子日誌（竹子） — Sun, 20 Dec 2020 10:09:00 GMT

人工智慧的本體是透過程式構建一種演算法

演算法會去紀錄對象、自身行為

把對應設定好的數據紀錄進資料庫

透過資料庫的內容增加

可以進行更精確的判斷來分析、執行程式運作的行為

這種程式就算是軟體工程師也只有不到5%的人具有構建這種演算法的能力

後面還包含著：

是否有合理的商業模式

是否有足夠的資料源

是否有充足的除錯與測試

市場上大概有70%以上充斥假AI

拿著好像很厲害的名號招搖撞騙

四處騙取巨額融資

這不就是洗錢？

明著向政府、銀行、投資者索取大把鈔票

可笑⋯⋯

我雖然不是頂尖的軟體工程師

只是構建普通商用網站的工程師

但越是了解更覺得越可笑⋯⋯

［短文分享］

竹子日誌（竹子） — Sun, 04 Aug 2019 04:07:08 GMT

這是我踏入寫程式的路，很多人看到，工程師每天都在看天書，但久了和學外文看原文書差不多，你沒辦法解釋，但就是看得懂。

［短文分享］張志祺的行銷秘密

竹子日誌（竹子） — Sun, 10 Mar 2019 12:32:57 GMT

## 1. 找到擴散中心

訊息要具有公信力、傳播性，一定要找到與該訊息相關領域的關鍵意見領袖（KOL，key opinion leader），才能達到讓更多人看到的初步目的。

## 2. 製造接觸點

訊息相對冷門或艱澀，就必須製造能夠引誘受眾「進門」的接觸點，在「奔跑吧！台北」專案中，透過遊戲內容吸引受眾進一步閱讀市政報告。

## 3. 提供資訊本體

當引起受眾興趣之後，才有可能觸發他們進一步閱讀的動機，在這個步驟裡，必須注意資訊脈絡是否清楚、具有閱讀親近性等問題。

## 4. 創造分享動機

訊息必須透過大量的分享才有機會擴散，讓更多人看見。受眾的分享動機包括「實用」「訊息觀點清楚」「可以一次了解8成事件過程」等等。

［自我閱讀］愛無能的世代

竹子日誌（竹子） — Sat, 02 Mar 2019 09:15:07 GMT

1.我們生活在一個創造需求的社會

2.愛另一個人，就是把自己和對方變得更好

3.感情的存在是為了雙方能夠持續互相扶持

4.坦白和誠實只是為了內心的舒坦，那就是自私的行為

5.女人說的「真正的男人」其實是瀕臨滅絕的物種

6.女人想要男性他的的外在形象與真正想要的背道而馳

7.當熱戀逐漸轉變成日常生活，一段感情的挑戰才正要開始

8.真愛只是神話

9.從生物學的角度來說，人類本身就不是單一配偶的生物

10.女人愛上一個人只是因為「催產素」

11.你在符合誰的期望？

12.不要把自己的願望投射給下一代

13.保有孩童的清新眼光

14.上班只是為了賺取閒暇生活所需的金錢，這些人的赤子之心已經死了

15.安全感讓人失去改變的勇氣

16.星期一是惡夢？還是滿心的期待？

17.職場和私底下可以是兩個截然不同的角色

18.人不是逐漸變老的，而是有一天早上起來就變老了

19.外在年紀並不重要，而是你的行為舉止是不是真的老了

20.我們活在需要將就和妥協的社會環境

21.我們的愛情愛的從來不是那顆頭腦

22.談戀愛擁有共同話題、人生、規劃、目標，非常重要

23.年輕一代靠著社群創造第二個自己

24.我們定義的「幸福」其實是被媒體教育出來的

25.紅藥丸還是藍藥丸？你選擇的是真實的恐懼還是虛假的安樂？

26.現代人過度依賴社群，也過度去干涉與控制社交

27.你看到的是真實世界還是濾鏡般的世界？

28.對大多數的人來說，止痛藥比把病治好更重要

［好文分享］業務，不業務

竹子日誌（竹子） — Wed, 27 Feb 2019 01:20:33 GMT

如果七年前沒有選擇做業務，

我絕對不會想跟任何不熟的人聊天。

這張板子讓我很有感覺，甚至感動

這是以前做業務訓練時，

公司希望我們每天習慣的事，

以前我很不習慣/喜歡的是，要去跟陌生人聊天，

後來有位講師跟我說：

「說陌生開發太壓力，不如換個方式翻譯，

就當做是”認識朋友，跟一個人建立新的關係吧”

放下你的業務心，用平常心，對人的好奇來跟人聊天。」

這短短的一段話，打通了我對要去認識人的心結

然後，我就用這個心態去做了七年

直到剛才我去7-11，

才發現做業務，就是在建立與人的關係，

剛去買一瓶礦泉水，去櫃台結帳看到最近很紅的

「可口可樂纖維＋」放在旁邊

這時以前當業務的習慣跑出來，當下心中有兩個想法：

一個是：問問店員這瓶賣的好不好？

另一個是：

我又沒有想陌生開發，不要問好了

一瞬間，第一個想法贏了

「這一瓶最近是不是賣得很好呀

我常看到廣告，還有朋友有買。」我手指著那瓶可樂

「對啊，這一瓶有很多纖維，有些人喝了排便變得很順喔

我是還沒喝啦，但大家好評都不錯，而且是無糖的，

對身體沒負擔，以後有機會可以買一瓶試試。」

店員很熱情的跟我介紹，她當然沒有想賣我，

因為我好奇問了，她就熱情的介紹，

沒有任何人想賣任何人東西，that’s it.

再跟她短暫的聊了幾句話，

我微笑離開小七，她笑著說「謝謝你，下次再來喲」

我們沒有人想賣對方什麼，

但一個讓兩人微笑的早晨，一次小小的認識就這樣開始了。

#謝謝這些年來的業務訓練

by laa li 2019.2.27 8:07-32 am

轉載臉書：Laa Li

［時事議題］LINE@要變貴了！

竹子日誌（竹子） — Tue, 26 Feb 2019 12:36:09 GMT

過去Line社群行銷只要付費，就可以無限群發訊息，和廣大的粉絲群宣達最新消息。

近期，Line官方發布，以後付費會員也要限制訊息量，每超過一篇就要額外收費，使得Line@對經營成本也上升了。

台灣來說，Line的使用者黏著度非常高，曝光率也是目前台灣所有社群平台之冠，可以說是轉換率非常良好的工具。

然而這波異動，不知又要影響多少的商家了⋯

對於Line@收費模式的改變，有影響到你嗎？

你認為會帶來什麼影響呢？

［議題討論］行銷x銷售；差在哪？！

竹子日誌（竹子） — Tue, 12 Feb 2019 14:18:35 GMT

這個複雜的問題就像男女朋友吵架一般複雜，因為思維模式是完完全全不同的方向。兩者的行為、邏輯、法則上面根本不一樣，但因為是兩個和客戶走最近的兩件事，讓人難以忽視，卻又傻傻分不清楚。

而職場上，行銷企劃跟業務人員可就有吵不完的架，因為明明是與客戶最接近的兩派人，但功勞吵不輕一個所以然，這兩方人馬爭起來還真要把公司搞個人仰馬翻呢！

而這個百年議題你怎麼看呢？

歡迎一同分享喔！

以下是竹子我個人的見解喔～

行銷要的是知識深度、邏輯力與創造力、受眾的心理揣測，最大的目標是曝光讓最大數的人看見，再從大量的人選與曝光中篩選出精準的客戶族群。

行銷有人比喻像空軍，遠端轟炸標的，雖然沒有辦法佔領領土，也沒有辦法有明確的成效，但是卻具相當高的戰略價值。一個市場要殺出血路就是要仰賴行銷進行先鋒處理，讓客戶對公司有基礎的了解。

行銷最高境界就是建立讓每個人有強烈的品牌印象，打造強烈的品牌形象，令人談起產業就會有一致的聯想連結。

銷售要的是知識的廣度、敏銳的觀察與反應、情緒與氣氛的拿捏，最大的目標是從有限的時間與人選去進行情感交涉，並協助客戶完成每一筆交易行為。

有人說銷售就像陸軍，所有的佈局收網仰賴銷售把市場的領土攻佔與收復，是最直接影響公司營運的職務，常常是舉足輕重的一個部門。

銷售的最高境界就是令踏入門市的客戶與業務員面前的客戶都能夠順利完成交易離開，而不是輕易讓客戶帶著疑問與猶豫離開。

兩者對於現代化的公司都非常重要，商場上的競爭激烈，搶到客戶量代表著公司的生存獲得保障。所以兩部門不該是敵視和爭功，應該要通力合作，把兩方擅長的事做到最好！

［自我閱讀］劃出善良的底線

竹子日誌（竹子） — Thu, 03 Jan 2019 05:37:18 GMT

先學會愛自己

可以有情緒，但不能情緒化

歸咎他人不會改變事實

為自己負責就不會受人擺佈

剛剛好的聰明是大智若愚

劃清界線，對的人就會聚集

別為合不來的友誼浪費時間

踩著別人的腳印很難走出自己的路

離職就該是展翅高飛，而非逃避

你所堅持的是自己的夢想還是別人的夢想？

追逐夢想的人沒有時間談寂寞

當你覺得孤獨時只是因為你還沒完全燃燒

找到想做的事情就是成功

煩惱源於自己，是不是「問題」自己決定

期待別人理解的人只不過是不懂獨處

虛張聲勢只代表更沒自信

獨自玩耍經驗不足的人會缺乏專注力

［議題討論］創業需要夥伴嗎？

竹子日誌（竹子） — Sat, 22 Dec 2018 11:29:11 GMT

談到創業每個人都有滿腹的想法，一開始每個人拼命想要找能夠合作的夥伴，爲的就是想組建一個強而有力的團隊。

我們常常談團隊是1+1&gt2的非典型邏輯公式，良好的團隊能夠帶來好的協作，因而創造更大

然而，卻又有一派「寧缺勿濫」的人，他們對於合夥人極為感冒。基於穀倉效應為前提，一個人發揮最大生產力，反而經驗法則上團隊變成拖垮自己生產力的絆腳石。

許多企業成也團隊，敗也團隊，當「人」這個不確定因素越多，經好像帶著眾多炸彈在自己的創業路途。

你認為，

創業是團隊越大越好呢？

還是小而精小而巧好呢？

甚至是一個人最自在呢？

團隊要多大，看的是產業別與商業模式

竹子認為，需要的團隊規模依據產業別及商業模式決定，不同的產業發展方式自然對於團隊的需求性不同。

舉例來說：

如果是組織行銷，因為每個人都是負責業務，每個人的工作都是要產生成交，透過組織行為建立分潤。

如果是一般通路銷售盈利，通常會將門市通路與後端分工處理，量體來說通路越廣也就越好。某個思維來說，也是擴大團隊為主。

以工程營造類或是開發設計類來說，工作以工作班為單位，主要講究團隊的協作性，團隊需求高但重在互助性與專業力。然而規模一但大成本很容易補不齊收益，因為協作效率降低，導致利潤被成本吞噬。

最後是一人工作室，因為跨領域涵蓋項目高，各種技能因為協調性全部掌握在手上，工作效率是最高最好管制的，相對利潤也能夠最大化。若是能夠一個人做的事業項目，儘可能在各種細節和流程系統化，也相對幫助未來擴大組織規模。然而所有流程尚未系統化前，絕對避諱擴大團隊規模，這只會造成組織運作互助力下降，把寶貴的資源流失掉。

什麼情況下，其實不需要夥伴

常有人說，不怕神一般的隊手，只怕豬一般的隊友。

當然，每個人在挑選夥伴的時候就會格外謹慎小心，對於這一點，我這邊也提出我個人的看法喔！

如果只是為了找人陪，創業本來就是孤獨的，那不如一開始就不要創業。

如果只是想要找人做自己不想做的事，那不如花錢雇用員工，夥伴和員工是不同的。

如果只是找人解決特定的範疇的技術，那不如花錢請專業的公司或團隊做。

如果只是需要資本合資，那不如和銀行或創投借貸、注資。

接下來也要講講找夥伴找什麼特質。

—————————————————

找夥伴的加分項與地雷項

找合作夥伴我認為有幾樣大大加分的條件或素質，也有幾樣極度地雷的素質。

加分項目：

極具創業者思維的人

擁有特殊的核心競爭力

只出錢不出力或聲音的人

地雷項目：

過分努力、守本分的人

愛抱怨、計較的人

[議題討論］被動收入真的存在嗎？

竹子日誌（竹子） — Wed, 19 Dec 2018 14:30:47 GMT

從Robert Toru Kiyosaki出版了富爸爸窮爸爸（Rich Dad, Poor Dad）後，提出ESBI財富四大象限理論，這波財富自由的狂潮席捲全球。以Amway為首大幅度的宣傳以及提倡，也改變許多人的生命，重新定義人們對「財富」的看法。

隨之而來的卻是另一波的批判，勞工的仇富情緒從來不因此而改變，甚至認為「被動收入」是少數既得利益者與資源既有者搾取勞動階層的收益，認為是不勞而獲的表徵。

那誰對誰錯？

對於這兩者你怎麼看？或是有自己的觀點？

兩派我都不同意

然而竹子自己的看法是兩方皆不同意。

我不既不認為有被動收入。

也不認同是資方搾取勞方。

「這世界流動的規則從來不是你想的那樣」

我們認知的世界是別人告訴我們的，但是你曾自己思考過自己所認知的一切是別人給的還是思考消化過的？

財富的原始狀態，就是一場交易

我們所汲汲營營追求的財富是什麼？其實就是供應產品的人與需求的消費者進行貨幣的交易，這就是最原始的狀態。能產生最大的財富產值是看完成了多少交易，交易的前提是產品足以與消費者產生價值交換，完成了這基礎行為後金錢的活動才就此開始。

每一個人努力在崗位上建構產值，每一個人銷售「自己」這樣產品，求職者更是如此，你不過是用自己的勞務去換取薪資，而這個薪資就是你這產品的「定價」，談好的合約內容就是運行的準則，沒有爭議，更談不上合理性。

我們會知道，要靠許多複雜的商業模式律定來創造收益，因為你用最少的勞務與時間來換取利潤。勞務的價格從來不是用「基本工資」來談，而是「創造價值」才可量化定義，不是用「我工作多久」，而是「我創作多少價值」。

資方榨取勞方嗎？先問產出值怎麼算

回歸正題，資方榨取勞方嗎？「勞工」這個產品的產出值才決定價格，沒辦法定義產出值，所有的薪水與報酬都沒辦法被價值計算，這也代表「薪資」從一開始就不存在交換價值，那怎麼談老闆是不是在壓榨？

回頭談被動收入的定義

最後回來談被動式收入，先談定義：

｛被動收入是一種只要付出一點努力進行維護，就能定期獲得的收益的收入模式。｝

很重要的一點是「付出一點努力進行維護」，代表依然需要勞務的輸出，依然能夠量化產值，並非是躺在家裡自然能生產的收益。也就是說依然能夠運用其他管道或辦法相對用同等時間單位獲得同等收益的行為均符合。

我想說的是回歸本質，還是追求時間與金錢的產值，這才是根本的東西。以最少的時間創造最大的利潤值，這件事本身就是在追求財務自由，剩下只是商業模式平台的建構和創作利潤技能的熟練與培養。

沒有最佳化的選擇，只要在現有基礎上的資源找到最大化的價值，逐漸轉化為實質的最大收益，這就是最理想的收入。

當然，也有人會不認同

也有人會不認同我的觀點，但我希望群組的就是能夠容納百川，我也希望未來能夠漸漸放入更爭議的議題，少點交鋒，多點交流。我認為最好的學習是大量的正反面觀點，互相比對思考，包含我自己也並非至頭至尾都保持同一個觀點。

這世界沒有絕對的正確與錯誤，全然在立場、觀點、資訊等等不同而產生截然不同的火花，也希望大家能一直交流持續下去！

［議題討論］不只為職場努力，更要愛自己

竹子日誌（竹子） — Mon, 17 Dec 2018 03:12:59 GMT

在現在百業蕭條的年代，在大公司上班求的不過是穩定，想要翻身人們必然就是提及創業。創業當道，市面上各種成功學早就積極向上的人們，可是卻也有利用這點，剝削著這些揮灑生命的員工。現今更有「慣老闆」、「慣主管」之稱的流行語，暗暗諷刺那些踩著別人屍體往人生上方前進的人。

不拼命，不成不就，公司不需要你的同時就被淘汰，大公司要規模裁員第一刀就是你。但拼死拼活為公司賣肝賣腎，被利用完卻又一腳踢開，讓你的辛苦歲月付諸東流。

如果是你，你要如何去解這個套呢？

解套的方式沒有標準答案

其實解套方式百百種，沒有絕對的答案，每個人的個性迥然不同，自然有適合自己的方法，多聽聽多嘗試，會找到合適自己性格和現在環境的手段。

而竹子自己有一套既有基礎的方法，經過親身實驗與經歷，摸索出適合我的方法。我就來與您分享我的手段，一起分享交流，讓我們一同成長吧！

一、苦工下在帶得走的東西

無論是哪個產業，最重要是凸顯自己的價值，把技術用「作品」來包裝，呈現方式可以是實質的產品、照片、績效等等可考可見的物體。千萬不要因為意氣用事而砸招牌，因為這些東西是可以帶動下一份工作的。

二、用成效來說話

任何公司創業就是要賺錢，雇用你不外乎是要盈利、省錢、省時間，這些是最重要的成效。及其所能把工作重點擺在有成效的行為，慢慢才能過深入骨幹成員，由此一來不可取代性提高，在公司內部的地位才顯的重要。但時間浪費在「配合主管」等沒有生產力的行為，縱使天天加班也只是磨耗生命。

三、找好備胎，分散風險

備胎的意思包含著下份工作、兼職、接案等等形式，也就是不要把正職收入當作全部的收入，收入結構一定要包含不同的收入來源。在這種情況，有效分配時間成本與分散風險，即使危險和惡劣的條件來臨也較具抵抗能力。

四、避開犧牲健康的事

健康是無價之寶，凡指熬夜、惡劣環境、高危險施工等類型工作絕對要避免，這些都會讓自己處身危機中。風險勢必要與「報酬」對等，若是高風險卻不附高報酬那根本不需要做，因為唯一錢換不回的資產就是健康和生命。

［短文分享］各司其職？小心穀倉效應！

竹子日誌（竹子） — Mon, 17 Dec 2018 02:20:06 GMT

在現在社會極度講究分工與團隊，任何事情不再能夠單打獨鬥，分工合作為王道的現今已經是常態。每個人都是社會和公司的一顆小小螺絲釘，每個人都有極爲重要的任務，堅守崗位職責成了運轉世界的齒輪。

然而，分工合作、各司其職真的是沒有缺點的嗎？

美國金融時報執行主編Gillian Tett提出了「穀倉效應」（The Silo Effect），其實這是把政府、公司、個人比喻成每一座穀倉，雖然穀倉讓世界井然有序，但當大家活在自己的小圈子，就會造成不知變通，看不見危機，並沒有辦法好好協調合作，容易犯下嚴重錯誤卻被全部人忽視。

穀倉效應，是一種文化現象，主要是因為我們的分工和分類系統本質上的缺陷。作者發現，穀倉效應無所不在，除了存在於社會組織，也存在個人內心與網路，因此，若想破除「穀倉」，必須顛覆管理學和心理學的思維，要更加客觀去觀察整個團體的運作哲學。

很多公司和團體在這經濟蓬勃發展的現代透過細微有效率的分工造就莫大的生產力，也證明團隊合作遠遠勝過單槍匹馬來得重要。一個人在事務處理容易分心，勞力處理更容易出錯，利用團隊嚴守細節。

人類其實也很自私，當有了分工合作，惰性就會產生，每個人只想顧好自己的範疇。當每個人自私自利，只會「把分內的事情處理好」，那代表團隊合作的價值又被削弱。此時，一個人犯了影響團隊的缺失，每個人不斷推卸或坐視不管，自然就會產生骨牌效應。

破除穀倉最關鍵的地方是，不要把生產了當作最高指導原則。發揮每個人的連結力與創造力，提高連結力讓團隊互助修補疏失，用創造力取代部分生產力，有時候產生的槓桿比率非常驚人的！

你身邊的團隊有發生穀倉效應嗎？

那領導者如何處理呢？

［短文分享］把你的技能帶著跑

竹子日誌（竹子） — Sun, 16 Dec 2018 05:09:15 GMT

大半的生命投入在職場中，能學習的東西多如牛毛，永遠活在歸零學習中，這無法止息。人生也就不過這幾十年在職場打滾，人類的成長空間與幅度顯得特別有限，浪費時間在沒有效能的學習更是白白損失掉光陰。

那麼，什麼樣的技能具有高運用價值呢？

判準只有一個：泛用性

以一個很好的準則來看，就是「泛用性」。那又何謂這個泛用呢？

這個泛用最好的定義方式就是換了一個工作崗位或是跨產業，過去付出的心血與努力是否可以保存沿用到下一個位子。只要是這方面的努力它產生的價值是一輩子，並不會輕易失去功能，這樣具有的優勢與競爭條件就會非常大！

泛用技能的六個先決條件

不過談這個泛用性技能是附帶先決條件的，這些技能必需要有一些特性，並搭配一些用心，如此才能夠將效能轉換最大。呼嚨說這麼多，具體內容呢？別急別急，這些小小的核心還是得先掌握！

1.技能要縮短學習時間，以最低的水平投入戰場，並直接在實戰面挫折成長。

2.使用的工具不能被特定企業體壟斷，最少相同的需求能用3種以上的工具操作。（具體舉例：像我學了影片剪輯，入門時只會用威力導演，但不能被單一工具限制，同時還要能夠操作Final Cut Pro、AdobePremiere、OpenShot等等工具達成一樣的目的。）

3.技能運作成本不能太高，要能控制在自己可負擔的範圍，或是可以借力操作的技能。（具體舉例：像駕駛技術，但自己卻買不起車，這個前提下就不是合適的技能。然而如果能借用家人的車或公務車，這又能變成合乎條件的項目。）

4.要思考可連結性與可整合性，觸類旁通來學習，減少學習成本和壓力。

5.通用性強，橫越各領域都用的上。（具體舉例：銷售和行銷，哪怕沒產品可以賣，你都可以賣「自己」這個品牌。）

6.先執行再來想學什麼，因為執行才會知道缺什麼，你會更清楚要學什麼。

這麼多條件似乎看起來又沒多少能夠符合條件的技能，但答案其實你內心一定有，只是你一直不願面對。技能不只要能夠帶著跑，累積的辛勞結晶要嘛收納起來，要嘛數位化放進電腦變照片、影片或檔案，這些是比履歷更珍貴的東西。

真的什麼都不會的話，該學什麼？

也許真的有一些新鮮人覺得⋯我就真的什麼也不會，那我該學什麼呢？那麼投入的產業別和實務工作內容就很重要了，最怕最怕到了不適合的科系或職務還硬著頭皮繼續，因為世界上最昂貴的成本就是時間，消費掉的再也賺不回來。

我來些現在熱門的項目大方向舉例好了：

工程類：板金模組、水電消防、土木營造、工業製圖

藝術類：多媒體修改後製、美術工藝、音樂演奏、拍攝運鏡、腳本企劃

網絡類：電商管理、社群管理、關鍵字處理

科技類：伺服管理、加密防護、硬體製造、軟體開發

食品類：料理烹調、食品包裝、調味開發

商業類：領導管理、行銷企劃、銷售業務、市場調查

物流類：倉儲管理、特殊車輛駕駛、物流管理

行政類：文書表格、簡報製作演講、文件紀錄管理

其實大方向一舉會發現根本不用舉例，因為這些你心裡都知道，只是突然的迷失而已。

最難的不是學習，是「創意的有效整合」

最困難最困難的並不是學習，也不是選擇，更不是執行，最艱難的是「創意的有效整合」。一個人和一個企業的成敗歸咎在技術的創作整合，讓你無可取代的強大，這個時候其實已經不是你一個人的問題了，這時候要的其實就是團隊！

其實這個時候整合講起來就比較困難，簡單舉例：

我想要做零售門市服務那要什麼技能呢？

門市Location評估、裝潢工程、室內設計、照片設計、線上社群行銷管理、門市銷售業務及服務、物流管理⋯⋯簡單隨便就能琳瑯滿目的列舉，有時候真的不是一個人能夠學完的，所以更是要有團隊分工。但是當一個人能夠做到越多連帶的橋段，代表在團隊越是無法取代的骨幹。但也並非要全部由團隊分工，有時候適當的外包，「讓專業的來」，不但可以省事，也能降低許多隱形成本。

如果是你，你有什麼自認不錯的技能呢？歡迎與我分享喔！

［短文分享］口頭的信諾沒有價值

竹子日誌（竹子） — Sat, 15 Dec 2018 05:36:54 GMT

俗話說，醜話講在前。一個人最昂貴的是他的信諾，最沒有價值的卻是口頭的信諾。

看過了許多人有種深切的感嘆，做不到的承諾不要做，拿出承諾就必須做到，千百種理由聽起來都是藉口。

有時候可能只是赴約，有時候可能是小小的幫忙，有時候會是商業上合作，也可能會是金錢的互通。但是，不管是哪一種，幫忙是份人情，但背後要承擔的風險與責任可能莫大！無論什麼時候，信用是一個人的品牌，沒有人會喜歡砸壞這塊招牌。

任何時候，寧可用金錢買到協助，也不要任意用「人情」來取得幫忙。如果用未來來作為擔保的承諾，更是沈重的包袱，一不小心就會玩壞關係。所謂君子一言既出駟馬難追，話不要隨便說死，說了就有做到的必要，人而無信而不知其可，對於諾言就必須做到。

然而，有時候就是有不得已怎麼辦？那就必須做到一半，可能不能十全十美，先道歉，先做到一半，事後再想辦法補償，這就是態度。

說了這些就像大道理，又有多少人做得到？

但承諾很重要，卻很多人不在乎。

自己的承諾值千金，但不是每個人都懂信守諾言，對於別人嘴巴的擔保聽聽就好，因為他們什麼也做不到，不需要抱持期待，事實發生前都是虛幻的。

無論是自己的勞力、自己的時間、自己的知識、自己的信用、自己的人脈、自己的金錢，那些都是過去的自己勞心勞力換來的，別人不會懂你多努力，別人不會懂你多辛苦，不需要輕易出賣自己。

也許有人拿情誼擔保，也許有人拿金錢擔保，也許有人拿任何利益向你支借你的所有。除非你欠他份人情，除非你甘願為他付出，除非對方拿出具體可觸的擔保物，否則就要有什麼也拿不回來的心理準備。

然而，宇宙是平等的，你甘心的付出，這個世界會用某種方式回饋於你。所以，在能力可及範圍去做、去努力、去付出，該來的終究會到來。不要爭那利益，如果在意，那就別付出了，你也不會感覺到滿足、愉快。

手心向上是央求，手心向下是富足。

［群友分享］深度思考能力是如何被毀掉的

竹子日誌（竹子） — Tue, 11 Dec 2018 14:20:16 GMT

商場門口排了幾十公尺的隊等著買髒髒包，我觀察了一遍整個隊伍，想知道人們怎麼消磨時間，我發現90%的人在玩《傳說對決》。

這些人為什麼這麼閒？為什麼他們願意把大把的時間，耗費在這些事情上？

從心理學角度，我可以毫不費力地列舉出十幾條“為什麼會有人願意排隊跟風”以及遊戲帶來的滿足感背後的機制。

每天把幾小時的時間耗費在遊戲上，仍然會讓我覺得：太奢侈了。有這麼多時間，看書或者思考，不是更好嗎？

20 年前那場會議，和「奶頭樂」戰略

大約20年前，在美國舊金山舉行過一次會議，集合了全球500多位政治、經濟精英，會議的主題是：如何應對全球化。

與會者一致認為，全球化會加劇貧富差距，會使財富集中在全球20%的人手上，而另外80%的人將被“邊緣化”。那麼，

如何化解這80%的人和20%的精英之間的衝突？

如何消解這80%人口的多餘精力和不滿情緒，轉移他們的注意力？

美國高級智囊認為，唯一的方法，是讓這80%的人口安於為他們量身訂造的娛樂信息中，慢慢喪失熱情、抗爭欲望和思考的能力—

這就是聞名遐邇的“Tittytainment”戰略，由Titty（奶嘴）與 Entertainment（娛樂）合成，中文譯為“奶頭樂”。

他說：“給他們塞上一個奶嘴，他們將會在不久的將來，失去自主思考和判斷的能力。最終他們會期望媒體為他們進行思考，並做出判斷。”

發洩性產業與滿足性產業

這個戰略，具體是什麼呢？

一、發展發洩性產業，包括色情業、賭博業，暴力型影視劇、遊戲，集中報導無休止的口水戰、糾紛衝突等，讓大眾將多餘的精力發洩出來。

二、發展滿足性產業，包括報導連篇的無聊瑣事—娛樂圈新聞、明星花邊、家長裏短，發展廉價品牌，各種小恩小惠的活動，以及偶像劇、綜藝等大眾化娛樂，讓大眾沈溺於享樂和安逸中，從而喪失上進心和深度思考能力。

一言以蔽之，那些被邊緣化的人，只需要給他們一口飯吃、一份工作，讓他們有東西可看，便會沈浸在“快樂”中，無心再做深度的思考。

這個戰略成功了嗎？目前來看，挺成功的。

日常視野裡的資訊，99% 對我們沒有價值

是的，我說的就是一切偶像劇、明星、娛樂圈、臉書IG、微博熱搜、情緒煽動、低幼化遊戲。我們日常的視野中，充斥著這些信息。但這其中，99%的東西對我們沒有價值。

在臉書在Youtube上，低能耍白癡的網紅破百萬訂閱，爆乳露奶照隨便破千讚，都市傳說無腦實驗破萬觀看，反之科普專業知識、分享社會議題、深度思考內容，這些沒有人願意看，你還能欺騙自己嗎？

在我們生活中，有著太多太多被人為創造出來吸引我們注意力的東西——偶像劇、大片、綜藝、娛樂圈花邊、網絡遊戲等，每一條推送、每一款遊戲和每一檔綜藝背後，都隱藏著一個龐大而專業的團隊。

他們群策群力，用專業的消費者行為學或認知神經科學做支撐，用盡各種文案技法，就是要讓你點進去，然後幹掉你的時間。

而反過來，無論是學習、閱讀、思考、寫作，這些事情，

哪一件有著這麼強大的陣勢？

哪一件有這麼容易讓人滿足？

這就是消費娛樂文化為我們創造的牢籠，而我們正心滿意足地一步步走進去。

低成本高回報的刺激，會讓你做不了高投入的事

一旦你習慣了娛樂這種“低成本、高回報”的刺激，你就很難去做那些“高投入”的事情——比如學習，閱讀，思考。

這是一個很可怕的事情。長此以往，你將失去自主思考和判斷的能力。

想留住獨立思考，可以做的三件事

如果你還對獨立思考能力懷有期待，現在給你下面幾條建議。

平時盡量撥出一定的時間，看深度的、優秀的書籍和文章，保持自己對語言的理解和運用能力，盡量遠離流行的網絡用語，因為“誰掌握了語言，誰就掌握了思想”。

如果可以，拒絕那些膚淺的綜藝、影視劇、熱點消息、娛樂圈資訊，只看最優秀的作品。什麼是最優秀的作品？至少，是有突破性的、不反智的、引發思考的、有誠意的、需要動腦子的，不要讓自己成為“愉悅感”的奴隸。

最後，請找到一件能夠帶給你長期收益和幸福感的事，把它安排進每天的日程中。這將幫助你對抗庸常、平凡、索然無味的日常生活，讓你不斷保持頭腦的清醒。

［短文分享］物業管理

竹子日誌（竹子） — Tue, 11 Dec 2018 13:50:01 GMT

因為竹子近期接觸這個產業，所以特別發這篇，想把這產業我看到的分享給大家！

很多人不清楚「物業管理」在做什麼，有的人還會誤會成「物流」這個產業，其實完全不一樣的～

物業管理到底在做什麼

物業管理本身是一個房地產相關的產業，當社區大樓、商業大樓、百貨大樓等等這類型已經開始營運的房屋都會有事務管理的需求，大樓的主人、業主、股東、住戶等等許多繁瑣事務不想要自己管理時，通常就會請有這種服務的公司委派專人來管理，這就是物業管理。

物業管理常見的職業包含保全警衛、保潔清潔、機電維修、總幹事⋯等都是屬於這個產業的從業人員，可以說是非常龐大的體系。

那利潤在哪？商機在哪？

一個產業可以發展成龐大的體系，勢必有豐厚的報酬，有了報酬，有錢能使鬼推磨，什麼都可以做，什麼都可以變成生意。

物業管理最基本的利益就是代理管理的服務費用，更直觀來說就是一種人力派遣。想當然，公司會有大量的員工，卻又沒辦法產生巨大的利潤。而員工面也是，因為是一種人力派遣的模式，所以員工的薪資是受到限制的，員工全部取決於服務費的多寡，經過比例原則調配給每個人。

那看起來似乎不管是公司還是員工都沒什麼利潤，單純只是大量的就業機會？其實事情並沒有那麼簡單喔！

從員工面看：賣時間，但也賣人脈

先從員工面來看。

如果乾領著薪水，物管業是一個賣時間又不足具發展潛力的工作。往高層爬也因為利潤不足難以突破高薪，卻又要負擔龐大的管理責任和規模。但因爲是一個跟客戶緊密接觸的服務業，所以非常容易展現自我的工作，所以有自己未來事業規劃的人可以間接培養人脈，畢竟業務法則中「賣產品前先賣掉自己」。當你個人的人格魅力足以吸引人時，服務給人的密切關係就容易帶來更多機會，職場上的人生跳板也是基於此。

當然還有一種比較不合道德的獲利模式，就是如果職務上會有廠商的接觸時，適時進行一些業務來往培養關係，牽成交易後從賣方利潤或買方介紹費獲取個人收益也是一種方式。小的是蠅頭小利，大的是龐大的改建工程。但業界也比較不喜歡這種運作，認為是不道德的行為。

從公司面看：一成不到的利潤

再來從公司面來看。

在每一筆交易和運作背後能帶來的利潤比例不如零售、貿易等以商品價值來定義的利差。事實上都被行政運作剝削了三成以上的費用，剩下的人事成本更是龐大，大概佔了六成多，可能不到一成才是利潤。利潤低更代表企業對於風險的承擔能力差，禁不起管理疏失甚至賠償，龐大的管理體系造就行政成本及人事成本難以削減，更造成低薪。低薪也間接造成員工的教育訓練成本提高、基層流動率提高、基層素質低下等等負面影響。

利潤這麼薄，為什麼還有人做？

然而為什麼依然有公司做這門生意？那為的是「穩定的金流」、「適當的節省成本」、「偏低的技術門檻」。

因為物管業是以合約制，員工的素質和技術需求不高，只要有一些足夠能力的管理者來處理這龐大的基層，在金流部分非常穩定，留住重要的管理人員會容易許多，也容易拉抬營運的穩定營業額，在金融業界是非常重要的因素。

另外一方面，因為高昂的人事成本下，可以連帶享受到許多稅法上優惠。甚至連帶建設類別的或金融類別的關係企業來運作，能夠有效降低總體營運的稅務，對集團本身也有莫大的幫助。

還有最重要的因素，因為技術門檻低，只要掌握客戶族群，請獵頭公司僱用員工便能夠較容易運作。也因為這個因素，慢慢看懂這塊餅的人爭相切入這個市場，形成一個人鬥人相互競爭的環境。

這不會是個賺錢的產業，但絕對是個「工具」產業，能帶領的附加價值遠遠大於收益。有誰也熟識這個產業呢？歡迎分享你的看法，提出自己的意見和見解喔！

［議題討論］領導統御

竹子日誌（竹子） — Tue, 11 Dec 2018 13:33:17 GMT

身為一個主管階或是團隊領導者，你會怎麼統領自己的團隊呢？每個人都有自己的一套模式，在不同的產業類別、團隊大小、團隊性質都有不同適合的方式。沒有十全十美的人，更沒有完美的領導風格，但是結果決定一切！一個團隊的生產力、穩定性、互助力決定這個團隊的價值。你的團隊呢？你用什麼樣的風格來領導大家？

竹子這邊提出我個人的風格模式，並不是最好的，不過可以與大家分享！

從執行面，凡事我喜歡親力親為參與首次運作，並做好初步決策，當律定運作法則後交給後輩嘗試。能力弱的，逐步指令教導，但絕不代為執行，要保留學習者的執行計畫與經驗累積。能力強的，明定目標方針和風險提點全權交由他執行，對其方式保留糾正與修正，觀察結果的呈現。

人家說帶人要帶心，但絕對不是一昧的對下屬好，更不是無盡滿足他們。對於他們領導者可以做的是「傾聽」。找出現場的問題，也找出部屬的優劣處，施以適當態度帶領，在不超出倫理、尊重、團隊利益的前提下，盡可能令他發揮。

我想要帶領的團隊是「夥伴」，並非「下屬」。所以凡事把問題拉出來考量，在不違反可行性、風險性、原則性前提的評估標準中加以運作，共同集思廣益研討執行面。

看起來完美無暇的方式其實是有致命缺點的，因為，沒有十全十美的領導風格。這種領導風格的領導者初期極其辛苦，屬於長期培養團隊的類型，通常需要半年以上的陣痛期。

另一個缺點就是，當遇上老鼠屎時很難處理。什麼叫老鼠屎？這種方式前提下是建立在團隊人員資質或能力不差的條件，而且真心願意為團隊付出。當遇上有人純心逃避或能力落差大時，常常會拖垮站在前面的人。

你們自己呢？有任何看法都可以提出異議喔！

自動回覆控制

竹子日誌（竹子） — Mon, 10 Dec 2018 14:12:36 GMT

竹子在專業部分均可提供意見諮詢與資源協助，品項包括室內工程規劃、電器健檢評估、家電維修諮詢、社區設備管理諮詢等等各式疑問，歡迎發問！

也不定期提供相關設備小常識，希望與您交流切磋，也希望給大家更加豐富的資訊～～

［定期短文］人類的奴性

竹子日誌（竹子） — Mon, 05 Nov 2018 11:01:35 GMT

生活中有很多前輩的遵遵教悔，熱心友善的前輩們會提供豐富的經驗和人生理念，然而出於好心的他們無意中也教導很多不適合於你自己的想法和觀念。任何人的教導不必要全盤接受，您覺得有哪些是誤區呢？

今天竹子對於幾樣特有感的事物提出看法，歡迎大家也提出想法。

老人家說的人生哲理有時候只是他們人生的履歷所萃取的經驗，但是一定是對的嗎？這倒未必⋯⋯因為本來就沒有正確與錯誤。

前人出於好心告訴你他的經驗值，但是這些畢竟還是他的經驗，對於自己依然是參考資料。因為沒有對與錯，也沒有正確與否，只能在不斷嘗試中跌倒學習。別人的跌倒引以為戒，修正調整，但不需要刻意迴避。

近期不少人談，你必須要付出，吃點悶虧不會怎麼樣。但是⋯真的是如此嗎？

這句老話其實必須建立在「你是為自己工作」為前提，如果付出都是為他人的成就努力，如果付出都是為不在乎你的人努力，那到頭來就是悶虧一場。因為，你的努力不會有人感謝你，那只是「應該的」。

你真的覺得自己的付出這麼廉價嗎？如何創造更大的價值？如何學習更多？這是要花時間去摸索的，這更需要時間去積累，但付出和努力卻是必然的。

那怎麼知道自己的付出是不是吃悶虧呢？其實只要把握一個原則，付出代價與犧牲，主要是為了成就「自己」這個獨一無二的品牌，那麼就沒問題了。打著個人這個獨一無二無法取代的品牌，那麼就會有所累積，別人會看得到，犧牲和付出很多人看得到。

那麼你呢？有不同的意見及看法嗎？

［議題討論］一技之長定論？

竹子日誌（竹子） — Thu, 13 Sep 2018 07:27:51 GMT

從小到大家人常常說，學有一技之長才能賺大錢。人人談一技之長就想說一個不可被取代的東西，但是真的有了這技術就可以生存走跳無煩惱？是不是真的學很多，什麼的都不精真的沒有用？

其實一技之長我們可以換一個名詞，就是「核心競爭力」。今天要立足市場需要的是一個不可取代性，但是要做到不可取代的技術是不容易的，每個人都力爭上游，怎麼能夠不可取代？每個人都很努力讀書，每個人都當工程師，每個人都做匠藝，每個人都搞餐飲⋯⋯等等，你又怎麼不一樣呢？

生存在這個世上，每個人最寶貴的資源就是「天賦」、「熱情」、「時間」。

所謂天生我材必有用，好馬要尋覓的只是那位伯樂，要讓更多人認識自己才更有機會找到那位伯樂。一技之長是被培養出來的，縱使一技之長很有用，但20年、30年之後呢？在科技飛速成長進步的現在，未來各產業的執行工具的進步，AI的崛起和革命，被完全取代不會那麼快。但市場上人力的需求勢必減少，原本10萬的技術需求可能會變2萬，你會是被淘汰的那個嗎？長江後浪推前浪，你確定永遠能當佼佼者嗎？看來就是未知數了⋯

但最難以被取代的就是多樣技能的整合者，當多種技能於一身，並進行有效的整合運用，你就難以被取代。但什麼技能能互相整合呢？這是創意的發想，只有懂的人才能想得到。所以盡心盡力去學習挑戰，找出屬於自己的那塊舞台，完成別人做不到的事情！

［議題討論］人才是最大的問題

竹子日誌（竹子） — Sat, 25 Aug 2018 02:46:18 GMT

許多在職場上折騰的人，很多時候並非真的是工作讓人痛苦，而是人與人之間的問題讓人難受。包含工作的不順利，事情處理的困難，或是堆積如山的工作未能解決，看似是自己能力不足不夠處理事情，但事實上都是自己在人的問題沒有處理好。

你認同這個觀點嗎？

技術永遠沒有界線，資源永遠都不夠用，總是有一群專精的人掌握市場上稀缺的技術與資源，若是你沒有掌握特定產業，那麼一定要會處理「人」。

有些人喜歡樣樣自己解決，包山包海無所不能。有些人會借力使力，但自己什麼都不會。你覺得誰厲害呢？

其實都很厲害，因為「解決問題」了。

在資源上有三個要素很關鍵：

技術、人情、金錢。

解決問題勢必要技術，通常花錢可以買到技術，只是價位的高與低。但有時候付錢別人不要時，看的就是「人情」，所以說人情債最難還。當沒錢沒人情時更是要去蒐集資源，以物易物，交換資源。

縱使你十項全能什麼都會什麼都懂，樹大招風，勢必會吸引不必要的麻煩，最後還是要回歸處理「人」的問題。人心叵測，鬥爭無所不在，你不害人不代表別人不會來陷害你，小心謹慎，步步為營。

有時資源都到位了，但是人事上的協作無法串聯，依然是人的問題。這是需要的是聯繫與溝通，能夠整合分散的人們成為團隊，自然是在處理人與人之間的問題。

沒有技術，再學就好。

沒有資源，再找就好。

先把人的問題處理好。

［議題討論］認識新朋友就是拓展人脈嗎？

竹子日誌（竹子） — Fri, 24 Aug 2018 00:35:27 GMT

俗話說：「人脈就是錢脈。」

多少人每天忙於交際應酬，除了維繫關係外，還要培養新的人脈。但很多人都有一種迷思，就是我想認識很多朋友，得以拓展人脈。但是認識很多朋友真的就很多人脈嗎？這點我是保持質疑的，因為只是認識是不夠的。

我跟你很熟嗎？

這是第一個關鍵，人與人之間是透過長時間的相處和關係培養，如果沒有信任感，那也不過是泛泛之交。出了社會，大部分的人都比較現實，很少人能心交心。

你沒有利用價值

雖然講利用價值，感覺講利用很傷感情，但是這點非常非常重要！如果你沒有利用價值，憑什麼要憑什麼要別人跟你培養交情呢？如果你想透過人脈獲取什麼，那別人勢必也是，你又可以給別人什麼有價值的東西呢？

認識卻沒交集

好不容易認識新朋友了，卻沒有繼續保持來往，日久淡薄，很快就形同陌路。所以如果認識有價值的人時，更要積極採取更多互動，培養關係，來日需要對方才會被對方記得。

除了認識，更要被記住

這件事就有很多技巧了，包含有一個人人好記的稱呼方式，包含讓人印象深刻的人格魅力，甚至包含無法忘懷的相處事件。和人相處都是有技巧的，慢慢內化這些技巧，漸漸跟別人相處就是一個話題人物了！

讀書的方法02:超速讀書法

竹子日誌（竹子） — Wed, 15 Aug 2018 13:38:41 GMT

看書時每個人都追求以最快的速度越讀完一本書，並且有效掌握書中的重點，而非只是看過去而已。

這種速讀法其實已流傳許多年了，但是非常好用，可以快速整理許多資訊。

速讀的優點無疑就是快速，現代資訊量過於龐大，能夠用最短的時間閱讀大量的資訊，其實無疑是最有效率的一件事情了。

速度的基本原理其實很單純，因為平常閱讀時我們已經習慣「眼>口>腦」這個順序，我們必須強迫自己在閱讀時跳過「口」的部分。什麼意思？其實我沒常常在閱讀時會不自覺去默念內容，但這個動作大大降低我們的閱讀效率。

通過速度的練習我們能達到古人所云的一目十行，其實也承如其詞，就是要你去做「一目十行」這種事。

但這個方法有一個莫大的前提，就是要有足夠的詞彙量，當詞彙量不足時想快也沒辦法快。在能夠快速閱讀的同時，這條件是建立在對於書本的文意是否熟悉。當然也未必真的要每字每句熟悉，還有一種方式就是用概覽的方式先讀一次，然後再重新快速瀏覽，如此的效率也會跳增許多！

你又是怎麼增加閱讀速度呢？

如果可以與我分享吧！

［定期短文］網路爬蟲

竹子日誌（竹子） — Wed, 15 Aug 2018 13:28:27 GMT

很多人說，網路爬蟲是什麼？真的在網路上活動的蟲嗎？還是病毒呢？其實這些答案都不太明確。

網路爬蟲並不是真的生物，而是一支程式。

其實網路所有的資料都存在現實中的伺服器裡面，而搜尋引擎的資料庫記載了有登記的所有網站的連結。

而這個叫網路爬蟲的程式就會針對你所想搜尋的「關鍵字」把所有有關的網站連結撈出來給你，這就是你平常用的google搜尋引擎。

網路爬蟲（web crawle）又常常被稱之spider，其實就是個名稱。

網路上其實有非常多的規範，不過這點這邊我不細談，這些爬蟲在訪問這些網站其實也是有一定的禮貌和規則的。

除了規範，當爬蟲將這些網路資料回饋給使用者時，其實還是有一定的排序。然而這些排序其實是經過這些爬蟲篩選並整理後它們認為優質的內容呈現給您。

這些內容排序，其實就是我們常常談的SEO排名了！

讀書的方法01:費曼學習法

竹子日誌（竹子） — Tue, 14 Aug 2018 13:37:53 GMT

看書有很多學派，依據目的不同，會有不同的學習法。每一種方法都有其優點，相對有其缺點。依據不同的學習目標和學習的物件類型決定學習方式，沒有正確與錯誤。

第一篇我介紹費曼學習法，我先不探討費曼是誰，竹子我直接導向重點。

費曼學習法最大的優點是內化高，記憶深，能夠把書中內容完整投映進反射裡面。

然而缺點也很致命⋯⋯耗時⋯⋯，而且極其麻煩，不過對於很精髓的書類很適合。

這個方法就是，閱讀的時候搭配朗讀、手部動作。念的時候不能死念，要用比較口語的方式念出來。

過程中持續把文字內容轉換成自己習慣的方式表達，逐漸去通順它。

最後找練習對象表達，傳授內容對概念。

此方法就是費曼學習法，學習效果驚人，能輕易內化，變成身上的一部分。

永遠不斷學習

竹子日誌（竹子） — Mon, 13 Aug 2018 16:13:24 GMT

我認為人要保持高度的競爭力就是要不斷學習，資訊淘汰速度過於快速，以至於不久前吸收的資訊即刻被淘汰。

如果是身在科技、資訊、媒體產業的工作者，想必要對新訊息非常敏感。

如果是身為行銷或業務，更要有迅速的消化力，能夠篩選新訊息納為己用。

如果是創業家，不但要對新知敏銳，也要立刻能反應市場。

沒有在成長的人，十年如一日，狗嘴吐不出象牙。過去很厲害的資訊即刻過時，沒有更新和改變，馬上就會被拆台。

能夠走在資訊前端的人才吸引人，能夠展現足夠魅力的人，才是真正的領導者。

停止學習，也代表停止成長，更是代表等待被淘汰。

社會問題

竹子日誌（竹子） — Mon, 13 Aug 2018 06:33:34 GMT

也許有人擔心人口少子化，也許有人擔心人口高齡化，台灣從高齡化社會邁入超高齡社會，過程只花短短7年這代表什麼呢？

現代孩子不婚不生，造成人口衝擊，這又代表什麼呢？為什麼會這樣呢？

其實每個人的看法不盡相同～

［好書推薦］未來年表

竹子日誌（竹子） — Sat, 11 Aug 2018 08:37:17 GMT

這個單元每次出現我都會推薦一本好書，或是我看完一本書做簡短書評，鼓勵大家看書，並且讓愛看書的人有新的書單。

本次推薦：未來年表

作者，河合雅思，是日本知名產業新聞倫說員。多次強調社會變遷的議題，非常重視人口高齡化的問題，著作的書籍多是討論此類社會觀點。

未來年表是本談日本未來即將面臨的社會變遷，包含的議題包含了「少子化」、「高齡化」、「產業變遷」、「社會資源殆盡」等等多項問題，一起來正視這即將面對的未來。

本書用非常科學和數據的方式呈現，因為都是真實活活上演，也是瀕臨的危機，讀者強烈能夠感受。

雖然台灣的現況不如日本嚴重，也可能你會覺得太誇張了，但是也能夠感覺出台灣即將面對這些問題。

書後作者也開了幾個處方簽，看似政府政策就能解決，事實上需要全面通力合作才能達成。至於哪些處方簽竹子這邊就賣個關子，大家可以自行去找來看！

讀過的人可以一起好好交流，還沒讀的人務必去看看。如果有什麼好書要推薦，還是希望我能消化後推薦給大家，歡迎告訴我喔！

［主辦活動］讀書分享會 EP01：一起分享一本書吧

竹子日誌（竹子） — Fri, 10 Aug 2018 14:54:13 GMT

讓我們一起分享一本書吧！EP01

最近有讀什麼好看或是有價值的書呢？

主辦人這邊會一本書來和大家分享

也希望大家準備一本

「自己看過覺得很有價值的書」

雖然不一定每個都會分享到

不過希望核心在鼓勵大家多讀書～

這次活動是我第一次辦

特別破費準備小小的點心和飲料

（別抱太大的期待）

未來可能會酌收茶點費用

但是本次，免費！

注意事項：

⭐️本活動無任何商業目的，請安心食用～

⭐️報名者切勿無故未到，以管理人數。

⭐️本活動歡迎帶朋友，不過請提前告知。

⭐️商業交流請自帶名片，切勿高調推銷。

⭐️活動地點為一般住宅，切勿影響其他住戶。

⭐️本活動依據狀況有異動會另行通知。

時間：8/19

地點：台北市中正區重慶南路三段16巷19號

讀書會：

竹子日誌（竹子） — Thu, 09 Aug 2018 07:00:16 GMT

#執行力

領先指標；落後指標

減肥：減肥方式；減多少重

創業：工作時數；賺多少錢

落實當者

找理想相同，不需要找最強

#給予的力量、被討厭的勇氣

弗洛伊德：受害者的心態

阿德勒：一切始源自己

自卑久了就驕傲

怕你成功了就數落我

#有錢人想的跟你不一樣

#富爸爸商學院

打有錢人，誰來投資

#主題

水電仲介

無法被競爭

被複製的B象限

［議題討論］讀書，你想追什麼？

竹子日誌（竹子） — Thu, 09 Aug 2018 00:03:15 GMT

讀書很重要，現在人人都有大學的時代，每個人都會想讀讀大學把這經歷走一遭。然而，有些人卻不這麼贊成⋯那究竟又為了什麼進修呢？不過隨著12年國教政策後，唯一有選擇權的從大學開始。

我這邊會分贊同派與反對派兩方思維來看「讀大學」這件事，沒有偏袒，客觀去分析這件事。

先說贊同派。

目前的社會人手一張大學文憑，少了大學就少了一點競爭力，履歷表就輸了一些。

甚至有些產業你沒有大學人家還不收你，這就是「門檻」。這張文憑不代表你多優秀，只是在企業面前你不過是張白紙。

知名網紅呱吉曾說：「我是建中台大畢業生，學歷確實不能帶給你什麼，但是它會讓你在人生這場遊戲的難易度降低很多。」

大學是座殿堂，研究學術的地方，許多人在這創造更多自己的價值。

再來是反對派。

在大學生泛濫的時代，一張文憑不能佔有更多優勢，連薪水都直達底線不帶優勢。

沒有文憑，依然能工作，沒有文憑，依然能創業，人們自會找尋辦法生存下去。

如果讀過大學的薪水能補足大學的學費倒還好，但是當今已不再備受尊重，更沒有明顯的薪水級距，職場要的是立即可用的人才。

經驗勝過秀才，只有抓牢技術和法則就能找到好的工作。

無論你是贊同或反對，社會依然運行，不要後悔，更不要遲疑。如果你衝刺了，去做就沒錯，生命自會有找尋到出口的一天。

［定期短文］執行力

竹子日誌（竹子） — Thu, 09 Aug 2018 00:03:00 GMT

最近竹子聽到一個關於執行力很有趣的說法，那就是「落後指標與超前指標」，而什麼是落後指標？什麼是超前指標？

這非常有趣，常常大家說目標很重要，但是訂目標卻是一個技巧，錯誤的目標制定只會阻礙你更接近目標。

這時我們先來比對一下「指標」這個東西，當理解「落後指標」與「超前指標」的差異後，你便會更了解目標制定的重點。

如果你今天想減肥，你的「落後指標」就是你減了多少重量。然而，你每天盯著你的體重，然而體重不一定能夠有很好的反映，那麼⋯⋯你會有什麼心情？沒錯⋯⋯就是想放棄。這時你需要的是「超前指標」，那減肥的超前指標是什麼？每天重訓的運動套組10次，或是每天跑步30分鐘⋯⋯這些都是精確的超前指標，你不必在乎減多少，你只要在乎有沒有確實完成，成功是伴隨而來的。

換個例子，如果你今天是業務，你的落後指標是什麼？獎金總額，這不就是你當業務所想要的嗎？但是看著這個獎金總額只是讓人失望而已⋯⋯因為一開始它根本難以成長。那超前指標是什麼？成交客戶數？好像不那麼精確⋯⋯因為成交並不是很明確的目標，甚至不可控制。那身為業務你的超前指標是什麼？應該是談了多少客戶！如果你一天逼自己談4個客戶怎麼樣？如果你每天開發10個新名單怎麼樣？如果你每天怎麼做累積多少？一個月談上百個客戶，開發300個潛在名單⋯⋯那持續1年後呢？這些經驗累積下來後還害怕數個月後完全沒有成交？或許有可能，但是你所做的事情應該價值也遠遠超過「成交」這件事情了⋯⋯

人家說，制定目標很重要，因為有目標才有前進的動力。但是，懂得怎麼制定目標更重要，執行力需要的是源源不絕的動力！

［議題討論］投資您怎麼開始？

竹子日誌（竹子） — Thu, 02 Aug 2018 08:35:01 GMT

每個人對於「投資」都有自己的定義和方向，但是對於不懂投資的人怎麼辦？常常不懂投資的人入場，第一次就投入錯誤甚至高額的品項，一次就賠光積蓄。但投資並不是這樣的，投資是一件量力而為的事，更要精確評估風險與收益！你對投資有什麼看法呢？用什麼方式進場呢？

投資之前，先把理財做好

投資商品百百種，但是要行投資之前，有一件事比投資更重要！

那就是「理財」。

你不理財，財不理你。

這是流傳已久的金句。

關於理財最重要的是「資產配置」。

從最基本來說好了，就是大家熟悉的「節流」，這是一件很簡單卻很重要的事。

不必要的開支不要花，把生活與收入抓出必須性的平衡，並強迫自己執行「儲蓄」。

儲蓄並不能以：

「這個月剩下的錢就是存下來的」

這種思維，這樣肯定存不到錢。

正確的存錢管理，是分開不同的帳戶，每個月在月初就提前把預計能夠存下的錢移動到「儲蓄用」帳戶。

如此一來，便會存下一些資本。

接下來，你就可以開始選擇你的投資工具了！

續⋯⋯

市場上的三大投資品項

承前日文章⋯⋯

投資前先了解市場上主流的投資品項，其實主要可以分為三大類！

1.法人機構：

包含注資企業、股票等等

2.實體商品：

包含期貨品、貴金屬、古董、房地產

3.金融延伸商品：

包含基金、債券、權證、貨幣、保險

各種小品項的特性各有不同，還是以自己合用的為主，評估自己的狀況去進場。

評估最基本的要素有：

資本、風險、報酬、操作難度

當然其他評估點是細項了⋯⋯

高報酬必定高風險，妥善管理風險才是重點。如果真的對投資的品項不了解，歡迎私下問我喔！如果我不熟悉的品項，竹子這邊也會介紹精通領域的人與您介紹～

第一次投資，推薦三個低門檻品項

不過這邊我相信大家一定想知道第一次投資要找什麼品項？這邊我特別推薦幾個進場資本低的品項，在操作練習和經驗累積非常有幫助！

其實⋯⋯剛開始投資有時還真要繳一些市場學費，千萬不要認為自己眼光精準患了大頭症，虧起來可是很嚇人的～

推薦1:債券

債券入場資本低，風險低，適合投資新手練習操作，或是懶人操作。

（台灣債券達多整合在基金內）

推薦2:基金

基金入場資本低到百元鈔票就可以輕易進場。獲利安定，配套工具多，適合投資新手進行資產配置及風險評估。

推薦3:股票

要練習觀察市場股票是最好的，因為市場敏感，反應速度快，零股進場也可以用小額累積許多經驗。

以上是竹子個人經驗所知，如果有專業人士願意修正和補充就更加感謝了！

［議題討論］投資與保障，保險理財

竹子日誌（竹子） — Thu, 02 Aug 2018 08:32:25 GMT

我真的很受不了身邊的朋友們，已經讓我感覺到他們自己都不知道自己做了什麼，理財概念完全出了大問題⋯⋯

很多人聽到「保險」，退避三舍。

保險是什麼？我認為他們搞不清楚。

很多人熱愛買保險，存錢買保險、投資買保險，反正錢多到沒地方花就是買保險。

保險的意義是什麼？我認為他們搞不清楚。

所謂保險求的是「保障」！並非是一個全套的金融工具。

如果想存錢，目的是強迫儲蓄，應該是選擇「定存」，並非是其他任何的金融工具。

為什麼？

因為風險低，彈性高，基本額度低，緊急時容易取出。以為定存很簡單？其實也有學問⋯⋯

如果想投資，目的是希望年複利率能讓資本增長，應該選擇的是股票、基金等金融工具。

為什麼？

投報率高，平均低風險標的都在3%以上，高風險的槓桿更高，保值力強，隨市場決定價格。

那保險是做什麼？

保險要分為兩大類，一個是非保障型保單，像儲蓄險、投資保單、外幣保單等等。

另一類，是保障型，像壽險、意外險等等事故理賠保單。

非保障型保單有其操作方式，適合有年齡且無法承擔投資風險的中年人，有閒錢想找標的將錢有好的去處。

保障型保單才是保險最重要的一環！

因為事故發生非人預期，希望以最小金額保障自己最大化權益。然而許多人貪小便宜，選擇終生期滿還本或是綜合特性等等保單，但根本不知道自己買到的保障有多少⋯⋯

竹子我並不是賣保險，但是看到許多人年紀輕輕就丟了一堆錢在買保單上，難道是業務員推銷所以買？難道是好像很划算所以買？難道是有閒錢所以買？

這些我都不認同。

年紀輕，學怎麼理財，學會操作投資工具。

中年時，學怎麼分配，學會資產配置管理。

每個人有不同的條件和狀況，並非齊頭式標準，更不該人云亦云，家人、朋友怎麼說就怎麼做，要自己學會去分配資產。

如果真的不懂，不知道怎麼開始學，歡迎諮詢我或群組中有經驗的專業人士！

創業是什麼？

竹子日誌（竹子） — Thu, 02 Aug 2018 04:31:54 GMT

創業沒比較偉大，那只是一種生活方式。

我從看到各式各樣老闆身上看到許多特點，也看到很多現象。

大部分的人認為創業是開創成功，創業能夠賺大錢，創業可以取得財富自由。

然而，事實並沒有這麽容易。

其實我們受到定錨思維影響，活在一個工薪階層，吸收、感受、生活的方式就是有一套法則。

然而，「創業」這件事情並非如此。

時間往前推至千年前，我們過去的工薪階層幾乎是「當官」，然而也是當代定義的「成功」。

當商人是被瞧不起的，那個時代「仕農工商」，商人比起工人和農夫更沒有社會地位。

每個年代都有每個年代的史由，大家追求的「成功」定義更是不盡相同。

現在看來，「創業」是很厲害的象徵？並非如此，「創業」只是一種生活方式。

自由調配時間工作、承擔必須的風險、負責自己和所以工薪階層的收入，每天有不同的煩惱，每天面臨即將盡頭的恐懼。

大好，大壞。

責任莫大，難以拋下手邊事。

這不就是創業家的寫照？

活著，追什麼？活著，求什麼？

活著，拼什麼？活著，做什麼？

若是清楚，你便走在理想的旅途。

若是你仍然不知道，那和一塊會動來動去的肉塊有什麼不同？

創業並不是難，只是你所學的一切是教導你如何成為優秀的工薪工作者，但從來沒有人能教你創業。

思維模型的差異決定差別。

差在哪？

生活的方式不同罷了⋯⋯

創業是你追求的東西嗎？

［主辦活動］竹子分享會 EP03：人生藍圖

竹子日誌（竹子） — Mon, 30 Jul 2018 05:52:27 GMT

竹子分享會EP03:人生藍圖

這是一個描繪自己人生方向的測驗，根據自己的性格、理想、經歷描繪出屬於自己的人生藍圖。同時，也能夠找到自己被經歷過程所壓下的定錨，意識到定錨存在。如果自己願意，未來仍能夠透過練習的方式拔除（連我自己也在努力）。

這是一個最近學到的測驗，技藝不精，還在練習，但是真的覺得是好東西。想學流程的也可以來，不過只能收一個受測者。

人生藍圖出處是源自於「有錢人想的和你不一樣」的作者”哈福•艾克”所設計的「財富藍圖」，後來經過台灣的團隊改良後所誕生的一種測驗模式。這套方法由極少數的人流傳，學習困難度高，適合學過心理學的人學，一般人學習上較為困難。但是不具備相關背景的人在測驗上的效果較良好，可以真正描繪內心那塊藍圖。

這藍圖本身就潛藏在每個人內心，但是常常因為現實而迷失方向而看不到，施測人只是協助對方進行描繪，並不是由施測者說了算。

注意事項：

⭐️飯主無意銷售任何產品，請安心食用。

⭐️報名者切勿無故未到，否則一定給黑評價

⭐️切勿局中有推銷等不當行為

⭐️本活動要帶朋友可以，但無法參與測驗

⭐️測驗可能需要2～3個小時，因人而異

⭐️如果很介意往事給飯主知道，建議不要參加

⭐️本活動為試水溫，如果反應不良列入備案

時間：

地點：

歐客佬咖啡農場信義店

106台北市大安區信義路三段109-1號

千古一問；鄭問

竹子日誌（竹子） — Thu, 26 Jul 2018 13:58:11 GMT

這是一個千古難得的人才，然而被埋沒。

年輕出走海外，在香港日本扎根。他遠方名聲響徹，然而台灣卻沒什麼人認識他，默默在深造他自己的技藝。

他的名作，刺客列傳、阿鼻劍、東周英雄傳、深邃美麗的亞細亞、萬歲、始皇、鐵血三國、鄭問之三國誌等等都有每一個時期的經典。

傳神的臉孔和精緻的筆法，人物向來都栩栩如生，就像是真的在面前的人。

鄭問老師也喜歡挑戰，曾用過毛線、滾輪、油漆、白膠等等極限美術素材來呈現作品。每一種手法都是創新與震撼！

他的圖畫很少是全開的圖，很多都是用A3和A4大小的紙張。但是每一張原稿的精緻程度經過時間蒼桑洗禮後仍然宛若真實，絲毫不失真。

後期的鄭問慢慢走向意象的風格，每一張原稿和人物設計都有很深遠的意涵，表現已不再拘限寫實或印象。

鄭問的人生不斷突破，手繪技藝登峰造極，在他嚴格的培訓下帶出數個優秀繪畫藝術家。

然而，就在去年鄭問老師在家中突然心肌梗塞，送醫不治，享年58歲。

現今手繪已經過時，普遍走向電腦繪圖，但是他精湛的技藝仍然不可抹滅，值得我們同樣身為台灣的創作者永遠流傳。

時隔一年多，故宮博物院收錄他工作室內畢生原稿，經過整理和處理，將這些快要失傳多手繪技藝重見光明，供予我們緬懷這位台灣之光。

［好書推薦］有錢人想的跟你不一樣

竹子日誌（竹子） — Thu, 26 Jul 2018 09:58:12 GMT

這個單元每次出現我都會推薦一本好書，或是我看完一本書做簡短書評，鼓勵大家看書，並且讓愛看書的人有新的書單。

本次推薦：有錢人想的跟你不一樣

這本書是暢銷名書，由哈福艾克所著。

這本書有莫大的爭議，內容並沒有任何有關財富的實戰技巧，也沒有太著重觀念邏輯的分析。內容主要在於人格與習慣的養成，甚至是很多你可能認為根本沒有意義的行為。

然而，真的沒有意義嗎？

事實上來說，很多都是潛移默化。每個看起來沒有意義的行為和習慣都有想不到的能量和效果，因而造成為數不小的聲浪。

當然，樹大招風。

不少人批評他這種書根本不實用，甚至哈福艾克開的MMI訓練課程有許多批判，價格也非常高昂。

然而事實呢？

很多事情本身就是一體兩面，同一套方式或許不一定適合所有人，但是有些人就是有效。

事實上他鼓勵的行為是「提高產值」、「善的能量」、「正面影響力」等方向。

這些東西真的不好嗎？

其實原本的含義是希望世界能更加美好，但經過包裝、炒作、造謠等狀況，其實事情已經不再簡單，有些名聲更是被玩壞。

內容我就不再劇透，其實還是鼓勵大家多看書。書是每個人人生步道上的精華，如何精準吸取別人表達的知識，這才是讀書的真諦。

哪怕，整本書只學到一句話的含義，那也是賺到。

不過我相信這本書能夠帶給大家不只一句話的衝擊。

讀過的人可以一起好好交流，還沒讀的人務必去看看。如果有什麼好書要推薦，還是希望我能消化後推薦給大家，歡迎告訴我喔！

［定期短文］資訊的落差

竹子日誌（竹子） — Wed, 25 Jul 2018 08:02:00 GMT

資訊的落差代表懂與不懂，古時候線人會「賣情報」，這就是仰賴資訊的落差產生的價值。

然而，現今因為互聯網的興起，資訊落差不再是優勢，漸漸被透明化的情報改變。

但是有兩種情報仍然值錢，「金融商品」的內線操作情報與「能力知識」相關高難度的技術情報。

然而情報也含帶市場的稀缺程度，這攸關情報價值高低，所以很多人擁有的情報自然也沒有價值可言。

很多地方都可以應用所謂的資訊落差，縱然網絡資料查起來很方便，仍然有許多人不會使用，甚至是仰賴衝動去選擇。

善用人性的貪小便宜再運用迫切性的技法，現場的資訊落差導致消費者作出錯誤的決斷，這種方式是銷售常用的伎倆。

你是銷售者還是消費者呢？

資訊落差是技術，也是方法，不道德的運用只會造成更多人受傷害。

但是合理的運用叫提供價值。

最清晰的就是「技術工作者」與「顧問」這樣的職業，他們不只是賣資訊落差，更是節省你吸收資訊的時間，你心甘情願購買這樣的情報。

你，是在賣什麼樣的資訊呢？

旅遊業的對接

竹子日誌（竹子） — Tue, 24 Jul 2018 09:27:38 GMT

環島這件事，這是屬於台灣的浪漫。

無論你是住大的島國，還是小的島國。太大，環島變得是一件艱鉅的任務，太小時是件沒有意義的事。

然而台灣的大小得天獨厚，使得環島變成一件成就，也是一段浪漫的旅程。

奇怪的也在這，縱然台灣這麼特別，卻沒有一個旅遊業者包裝這個行動。

環島是項夢想，

環島是個憧憬，

環島是種浪漫，

環島是樣成就！

在前幾天前的自由工作者早餐會發生了有趣的碰撞，一名旅遊新創的董事長，遇上浪漫藝術的文字工作者。

文字工作者環島旅遊，在東港靈光一現，如果把機動書店投入東港魚市場會怎麼樣？這個靈感需要實踐。

文字工作者他駐足兩週，嘗試買書這件事。這個行為引來漁會的注意，書、市場這兩者如何結合？書的類型很重要，包裝更重要。

新創董事長她也有感觸，是否可以包裝東港魚市場，能不能發展的跟日本築地市場一樣？沒錯⋯⋯問題在觀光包裝，因為我們的市場不差啊！只是缺少包裝、美化、規劃～

當不同的思維碰撞，趣味就發生了！

你，在什麼產業呢？

一起試試結合新的產業模式吧！

創作者的門道

竹子日誌（竹子） — Tue, 24 Jul 2018 09:27:25 GMT

聽了人分享關於魔術的事，我體會到原來一段創作或演員最大的差異並不是在技巧，更不是演技，而事「詮釋的手法」。

無論什麼創作，技巧、技術人人都可以學，核心也不會差太多，這就太容易被模仿了⋯

然而，一個人的人格魅力在於詮釋手法！

一種理念、一個想法、一樣思維⋯怎麼讓人知道？用什麼方法？

藝術就是如此令人著迷～

滾出趣人生旅所

竹子日誌（竹子） — Tue, 24 Jul 2018 08:59:03 GMT

前幾日參加了一場聚會，名為：

「自由工作者醒腦早餐會」

這場聚會與各種不同類型的自由工作者交流，包含文字創作者、導演、工作室負責人、國際旅遊搭建、駐外華語老師、社區區塊鏈開發、魔術表演等數種不同的類型。

自由工作者的世界可能我們會認為是隨興，事實上他們比上班族更加自律、積極、勤勞。

如果說他們有什麼不同，他們並不是在領域上特別厲害，而是他們更懂的「實踐」。

這些人都是不折不扣的「創業家」。

衝撞、挑戰、創作，提供各種產業超越一般的價值，因此他們的核心是為自己的理念工作，不是為任何人⋯⋯

這些人都是踏踏實實的「夢想家」。

人生不懂什麼叫浪費，每一刻珍視自己的人生實現每一個階段的夢想。

創辦人，許鈺煊、林倩伃、余佳紋、姚映竹四名女孩。募款33萬打造一個給自由工作者享受工作的空間，希望帶來更多的靈感與創意的碰撞，也是她們的初衷。

這裡也有許多過客，只要付費後可以在這裡沈澱、辦活動、尋找靈感、享受生活。這就是一個這樣的空間，一個帶給創作者夢想的起點。

希望大家能滾出自己的人生趣味，這個旅所帶給過客們體驗，釋放更多的夢。

滾出趣人生旅所

地址：台北市大安區和平東路二段96巷20弄6號

［定期短文］資本主義的遊戲規則

竹子日誌（竹子） — Sun, 22 Jul 2018 09:00:22 GMT

在資本主義社會下，富者越富，貧者越貧，逐漸形成M型化社會。在這些規則下運轉的齒輪，難以輕易調整或調動，他們都在崗位上運轉著。

你是大齒輪還是小齒輪呢？亦或你是整個機械的操作者呢？這個世界並不是你想的那樣。

很多資本家玩的遊戲是資源串連，還有借力使力。承擔一定程度的風險，槓桿舉起資本市場，回收可觀的收益。

資本世界的鐵律：

1.你不承擔風險，就會承擔更大的風險。

覺得挑戰是很累的事？亦或不敢冒險投資？更甚是做一些超出能力的行為？

這些都是跳出規則的框架的機會，更是前置條件，然而一般狀況都是不敢突破的。

2.靠自己永遠不夠，要串聯更多人的力量。

這句話是修飾過的說法，然而更直接說就是要能夠掠奪更多人的資源後壯大自己。

市場零和法則，總是要有人買單，總是要有人負責去做，便有人會得到那些支付出去的東西。

3.資源是越多越好，匱乏資源只會被淘汰。

資本主義社會是強者恆強的地方，社會不斷提供資源擁有者更多的資源與機會，而資源匱乏者仍然什麼都沒有。

那你擁有什麼？有什麼無可被取代？那就是你的稀缺資源！

以前我就常常聽到，沒有資本根本沒辦法創業，更沒辦法獲取資源。對於這點，我的答案絕對是：「否定」

而創業的根本其實是「整合資源」，資源呈現的方式除了資本、資產、人脈這種有形資源，還有技術、人格、熱情這些看不見的資源。

我不否認，「運氣」確實也是一個資源，一種實力，一種難以定論的東西。但是它並不是全部，只是有時候還不得不考慮它。

一般人會想，沒有資金，創業怎麼開始？

其實反過來了。

應該是「創業隨時可以開始」。

你的規模可以很小很小，但是你的格局可以很大！那怎麼開始？就是賣可以賣一輩子的產品。什麼東西是可以賣一輩子的商品呢？

答案是「自己」。

你可以選擇等有資金再開始。

你也可以選擇現在開始。

🎋［定期短文］

竹子日誌（竹子） — Sun, 22 Jul 2018 07:39:48 GMT

Facebook貼文與演算法

臉書是目前台灣使用人口最高的社群工具，也是價值非凡的網絡銷售的主戰場，是每個廠商和廣告商們的兵家必爭之地。

然而，近年來使用臉書的人口近達極限，而粉絲團、社團、個人帳號等數量仍然急遽攀升，個人追縱的對象逐漸增加。

難道，你不會有一個疑問。

我的頁面瀏覽不會滑不完嗎？

答案當然是不會。

臉書為了防止這件事，大概在4～5年前就開始有感修正演算法，幫用戶篩選一些貼文。

這個行為帶來什麼影響？

當一個貼文被貼出來時，不會每個人都看到。

沒有錯，「不會」每個人看到。

傷害的就是那些想宣傳價值訊息的粉絲團，因為沒辦法把每一篇文章曝光給粉絲們看，訊息就不再有影響力。

其實粉絲看不到事小，他們還會去追尋訊息，如果是想觸及更多人呢？根本發散不出去。最後，最大贏家是臉書，你必須投下更多廣告。

在臉書演算法的威壓之下，許多人紛紛撤出臉書的廣告市場，但是臉書真的不適合廣告嗎？

臉書是台灣使用人口最多的平台，族群也是最為廣闊，如果放棄這塊平台真的很可惜。

所以該怎麼做才能提高擴散力？根本來說，應該是要去提高「觸及率」。

而實戰來說，就是避免臉書下修自己粉專貼文的觸及率，也要提高訪客留言與分享率，如此才能夠高速擴張。

然而人心難以捉摸，又要如何使人們願意幫自己的貼文分享和留言呢？其實還是要追求人心渲染力了⋯⋯

［定期短文］任何東西都有代價

竹子日誌（竹子） — Thu, 19 Jul 2018 09:37:13 GMT

有些人先天就擁有資源，付出微些的代價就可以取得你拼了命也得不到的龐大回饋，這世界從來沒有公平過。老天從來不公平，只有公平給予每個人24小時，除此之外就是現實與殘忍。看看索馬里，看看阿富汗，看看中非⋯⋯你仍然認為老天爺待你過分了？其實已經太幸運太幸福了⋯⋯是人類天性太過貪婪。

當擁有的資源越少，要槓桿獲得更大的資源就需要更多的代價。運氣也是一種資源，風險更是一種代價，只要存在這點，就不能不輕視。

看起來很像宗教勸世文？但是我在談的是「風險管理」這件事情，彰揚成功學祈禱每個人能達到理想，完成夢想與自我實現是人類的終極目標，然而現實世界的規則並不是按照這個方式運行。

此時此刻，認清自己的資源擁有多少，按照自己合理的步調，勿貪多勿貪快，該來的東西都會來，該屬於自己的都會擁有。如果自己的根基不紮實，就像是曇花一現都會消失，畢竟那是運氣所得。

打一個最實際的例子，創業。創業需要很多東西，你可以說技術、商品、市場⋯⋯但是資金不能少吧？運氣也很重要！這時候風險管理就是以此存在，因為運氣成分佔太重時，失敗率代表就高了，而創業家把所有不確定因素進行風險評估、管理、籌備就是一點一滴去減低運氣影響的成分。當你創業魯莽，在很多不確定下就投入資金，就開始瘋狂衝刺，說傻也好⋯就是不成功便成仁的概念。

另一個例子就是投資。當你身來什麼也沒有，身上不存在任何價值，這個時候你自己什麼值錢？人脈的信任、口袋的貨幣、公平的時間、健康的生命⋯⋯你想拿什麼東西去換？越大的槓桿風險就越大，那勢必要投注更多更多的東西，你還剩下什麼？

［定期短文］可以被複製的成功是假的

竹子日誌（竹子） — Thu, 19 Jul 2018 00:54:31 GMT

相信許多看到這段話的人一定有滿滿的話想說，不管是否定也好，認同也好。

我自己的經歷上，因為我先碰上了傳直銷這個商業模式，裡面的人總是告訴你要複製成功者的行動，照著成功法則和模式，然後就會成功。事實上真的是如此嗎？我曾經反覆思索這個問題，日日夜夜思索很多次，這是真的嗎？

那段時間發生的事情太多太多，我認為已經沒什麼好能夠去一件件翻出來提起。但是並不是完全照著別人做的事就順利，因為你失敗了身邊的人或自己會給自己100個甚至更多的理由告訴你失敗的原因⋯⋯但是我們完全忽略了所謂的倖存者偏差（survivorship bias）。

倖存者偏差：那些沒被寫出來的失敗者

以下舉幾個網路上的例子：

「賈伯斯勇於挑戰體制而成功了，所以大家應該都去嘗試挑戰體制。」

上述例子中卻沒有提到一樣是挑戰體制卻失敗的人，僅僅只是以一名成功者說明，卻沒說明失敗者的下場。

「每個成功者都很努力，所以只要努力就能成功。」

此例卻無提出努力卻失敗的人，直接無視了失敗者。

經商致富的成功者出書介紹自己的成功辦法。

與該書作者做了相同事情的其他人，未獲成功，但失敗者是無法出書的，所以我們會誤以為該書介紹的辦法就是成功的途徑。

某電台記者在高鐵上採訪乘客是否買到車票。

因為買不到車票的人根本上不了車。

把運氣的成分降低，先掌握規則

這就是倖存者偏差，成功是需要運氣的。那我應該告訴你不該努力嗎？不，更因為成功需要運氣，我們應該把「運氣」的需求成分降低，掌握所謂的「規則」，剩下才是等待運氣來敲門。到底有什麼差別呢？

1.別人成果過的模式不需要完全照做，原因是別人做過的跟他一摸一樣你有什麼不同？大家都一樣就沒有區別性。就像30年前讀大學是人生快速成功必備的條件，過了30年讀大學就會成功？那就不過是張文憑，因為大家都有這個條件，你並不會很稀有。

2.人生來不同，每個人擁有的先天條件不同，自然，每個人的成功手段或必備條件也不同。就像有些人先天有個富爸爸，縱使老爸不給予資本資源，最少老爸他不會跟你說：「下個月家裡需要你幫忙10000元」，這就是先天條件。也有的人生來認識的人手頭寬裕，你要做生意時大家都有實力捧場，創業初期就馬上搭上順風車。有些人先天擅長表達和行銷，就是容易銷售商品，輕易突破收入界線。那自己優勢在哪？如果不能掌握那就沒有競爭力。

3.失敗是必經的過程。有句老話，年少成功大不幸，意思指你輕易突破界限，達到人生成功，但是沒有紮實的經驗當底子。時運走了，條件不在，還妄想認為自己無所不能，可不是著輸光場嗎？

4.當事情不斷累積，那會營造出一種氛圍，複製出一群自動化付出工作的機器人。這群機器人失去思考能力，同化並影響身邊的人，更甚是局外人。因為人不會去否定自己，當活在同溫層久了自然被同化。複製變成是一種操作，最好的例子就是現階段的填鴨教育，過去是一個好的成功公式。然而現今都不再是，現在已經成為機器生成廠，生產工業社會的螺絲釘。

那什麼時候成功才能被複製？

那什麼時候成功才能被複製呢？

其實真正的複製成功並不是商業模式、商業行為、商品等等的複製，因為每多一個一摸一樣的商業體在運作就多一個對象瓜分市場。那究竟如何複製？其實只有心態與性格。無論運氣好壞，當心態、性格符合「理想者」的樣子時，就會逐漸吸引接近理想者的人，然後互相影響更接近理想者。而此時，機率概論上成為這位「理想者」的機率自然會高上許多。但是只要跟身邊的人做一摸一樣的事，慢慢的就被同溫化，慢慢的身邊的人成為自己的競爭者，慢慢的⋯⋯成為機器人。

找出自己的路，勝過盲從別人的成功法則

所以想找到自己的成功法則，不斷不斷吸取知識和經驗，不斷不斷去挑戰嘗試，找出適合自己發展的平台，去驗證去執行。別單純去相信不會有效的他人成功法則，篩選吸取有效益的內容，結合自己無可取代的競爭力，勝過那盲從在複製別人的人，你會更快找到自己的路。人生成功沒有捷徑，掌握規則後就能夠生存。

［定期短文］SEO優化

竹子日誌（竹子） — Wed, 18 Jul 2018 01:17:35 GMT

說到SEO是多少人又愛又恨的東西。它好，因為免費，高曝光，打開搜尋引擎每個人都有機會被行銷。上門的客戶是自己找上來的，很精準，很有效，客戶更不會有被推銷的排斥感。

那麼，這麼優質的行銷模式既然人人愛，那為什麼又令人討厭呢？因為很難搞！

那它到底是什麼呢？

SEO全名search engine optimization，意指搜尋引擎最佳化。

它始源1995年，最早站在搜尋引擎龍頭的是1997年的Yahoo!，當時大家爭相要站在搜尋引擎的排行榜，所以早在哪個年代就開始鑽研的技術。到近幾年已經有數十種搜尋引擎爬蟲，但最主流的還是Google 和百度。然而大家爭相搶SEO排名，所以在演算法、排名判斷等等設計越來越細緻，期待能夠給使用者更加高品質的網頁內容。

那麼，SEO究竟該怎麼做才能搶占排名呢？

［議題討論］台灣的餐飲業

竹子日誌（竹子） — Wed, 18 Jul 2018 00:47:06 GMT

以下摘錄「什麼是市場？供給與需求。」

先講什麼是市場：供給與需求

市場就是由「供應」和「需求」所構成的交易存在體。市場沒有地點的限制，任何地方只要發生交易就是市場。

要講市場就必須從供需開始說。

什麼是供應？就是提供了某種產品或服務。

什麼是需求？就是某種產品或服務被需要。

可能你需要吃飯，所以有就有食物的需求，這個食物就是產品，所有你會跑去菜市場買菜。誕生你可能不想自己煮，所有你跑去餐廳吃飯，餐廳賣你餐點並幫你烹調，他們同時賣了你產品和服務。你可能跑去餐廳吃飯不想自己開車，計程車司機賣了你交通的服務。而等等賣給你的產品和服務就是一種供給。

市場平衡是怎麼來的

當市場上供給多需求少，因為產品的滯銷囤積，那產品的價格就會降低，自然需求者因為消費門檻降低而增加。如果市場上需求多而供給少，僧多粥少的狀況，那麼產品價格就會上升，因為消費門檻的上升，所以消費者因而不願意購買，逐漸需求就會下降。而以上的這種現象就是市場平衡。

有人可能會說，所以先有需求才有供給囉？那麼世界上第一台電腦被發明以前有人會說需要電腦嗎？當然沒有。所以這個先有需求還是先有供給是不一定的，但是市場的產生就是供需兩者某一種先誕生，亦或是一個先有雞先有蛋無解議題。

獨一無二的產品，市場就無限大嗎？

那我發明世界上第一台個獨一無二的產品我的市場就是無限大嗎？那也未必，這時候也要考慮市場接受度，如果市場上沒辦法接受這樣產品，那麼就不產生需求，產品再怎麼優秀還是厲害都沒有用。一個很重要的地方，就是你的產品或服務能夠解決什麼問題或是預防什麼問題這個產品的市場就會產生在哪裡，而能為多少人提供這樣的價值就會決定它的市場大小。

所以說，任何的創業第一步絕對是市場調查，如果單純因為對自己的產品感到自信，那你將會狠狠摔上一跤。完成市場調查來了解產品的市場大小，而不是因為一時的衝動而創業。

以下正文

回到餐飲業：平均一間店服務 200 個人

餐飲的市場可以說是最龐大的，但也是老闆們最火熱的「紅海」。雖然每人一張嘴，三餐要顧，生活要顧，市場龐大可觀。然而相對的，每個人一天三餐，頂多加個點心宵夜，他的市場還是有其限度。依據台灣人口數和餐飲業的創業密度來說，未申報的不計，民國104年的數據已突破12萬家，人口數為2350萬，供給比高達0.52%。意思是平均每一間餐飲店服務200個客人。200個客人看似很多，事實上扣除自家煮飯、大餐廳的服務數、未申報店家等因素，可以說是一片殺紅的市場。這個比例在已開發國家可以說是非常之高。

平均月營業額只有 34000

在競爭市場來說，就是搏鬥而已。那到底獲利值多少呢？依據目前餐飲業平均月GDP為400億左右，意思是平均每間的月店營業額只有34000，比台灣國民平均薪資還要低。

數字來說，台灣的現況就是這麼競爭，服務業服務過剩，餐飲趨勢集中。內需市場不足，外部供給的觀光更是逐年萎縮，現在進場餐飲界根本就是瓜分市場而已。

［主辦活動］竹子分享會 EP00：尋找人生道路

竹子日誌（竹子） — Sat, 14 Jul 2018 09:43:56 GMT

竹子分享會EP00:尋找人生道路

🤔你還不知道未來要做什麼嗎？

🤩還是做了一大堆卻不知道自己適合什麼？

🤑還是根本連自己在追求什麼都不知道？

大家大學畢業後投入職場

辛辛苦苦工作好幾年

也不停轉行轉行再轉行

我曾經也有過那段不知道未來該怎麼辦的日子

👉

🎉

本次活動依據人數、天候因素可能異動

🔥盡量及早報名我會快速審核並開啟滿團🔥

［定期短文］龐式騙局，Ponzi scheme

竹子日誌（竹子） — Wed, 20 Jun 2018 06:56:20 GMT

這篇文章比較地雷一點，我也是用自己的誠信去撰寫這篇，勸告大家小心，因為這個市場和社會太多這種遊戲。

出處是一位名為Charles Ponz的義大利籍美國人，它利用當時的經濟動盪設計了一場騙局，徹底利用人心的脆弱與貪婪。龐式騙局又名資金盤，台灣人俗稱老鼠會，是一種前資金補後錢的手法組成的一種金字塔遊戲。用後面的投資客的資本利潤彌補給前面投資客的收益，當規模日益擴大後到無法控制時收盤結利。

這種模式看似簡單容易，破綻百出，但經過縝密佈局後仍然可以騙過資深的投資客，且投資客卻渾然不知還自以為沒有中計。依據市場零和法則，資金沒有所謂無中生有，一定有其模式回到初始者的循環，所以不會有憑空產生的資金。

那麼⋯⋯

龐式騙局怎麼分辨呢？

龐式騙局跟一般的金融商品的複利有何不同？

不是以資金作為商品就不存在龐氏騙局嗎？

只要合法就不會是龐氏騙局嗎？

我現在的投資項目會是龐式騙局嗎？

如果深陷其中如何脫身呢？

龐式騙局的分辨方式主要要看資金利潤的來源，透過售出產品的利潤值來計算。沒有錯，有產品一樣可以設計騙局，以精算毛利率來看，依據相似產品大廠的毛利率為標準，若是過多就是賣貴，並且後資補前利。另外的辨別方法就是看以產品為主軸價值還是誘動人性貪婪為主軸，因為就算本意不是設計龐式騙局也會因為行銷手法的錯誤導致瓦解。

龐式騙局的設計跟合不合法無關，而是用規則來玩，以人拉人的病毒式行銷消費群眾資源。若是沒有公司本身合理獲利，那勢必會崩盤，只是時間早晚的問題。

那現在的投資項目是否屬於龐式騙局呢？其實要端看配利，若是總和配利不合理，或是資金流向不明，那都可以合理懷疑是龐氏騙局。

那如何脫身呢？其實龐式騙局就是後資補前利，抓準時機搶佔前利尋找後資，那麼就不會是那位損失。但如果站在道義和道德上來評估，那麼很可惜，永遠不會是獲利出場的投資者。

［議題討論］傳產與資訊科技的對接

竹子日誌（竹子） — Wed, 20 Jun 2018 06:55:02 GMT

科技新知日新月異，我們這時代飛快成長。電腦、手機、穿戴裝置、智慧化設備這些科技硬體不斷突破。網路隨著2G、3G、4G等演進即將邁入5G的時代。多媒體傳播由廣播、電視、電腦網站、行動社群等等不斷突破，再也抵擋不了資訊的爆炸來襲。

然而我們可以見到，台灣的傳統產業沒什麼前進，更沒有什麼飛快的變革，縱使科技這樣前進。傳統產業難道只能繼續夕陽嗎？沒有其他新時代的出入嗎？

如果是你，要怎麼對接科技與傳產？

傳統產業真的面臨夕陽嗎？

難道傳統產業注定被淘汰嗎？

我個人抱持樂觀的態度，這就是產業轉型和升級。結合現在互聯網科技，傳統產業仍然能夠產出不凡的價值。

我認為最為代表的就是體驗式觀光農業，近年經濟部大力推動的產業轉型就是體驗，把原本傳統農業的技術轉化為觀光農業，吸引觀光客來做觀光消費。包含農產種植、養殖、工藝等傳統產業，不但技術得以傳承，又帶動另一個層面的商機。

另外就是科技整合，台灣就有間畜產公司把大數據分析、AI工廠管理兩種高科技整合到養雞畜牧業。透過自動化流程高效率管理工廠運作，並用大數據研究提高雞蛋生產量和品質，並大幅降低禽流感的傷害。一年可以產出1億2千萬顆的高品質雞蛋，市場產值更是高達200億元，許多知名企業與之合作。

還可以另外一提，巴西的Havaianas原本是傳統拖鞋生產，透過網路行銷營造獨樹一格的品牌形象，帶動一個國際的拖鞋流行，營銷49個國家。它透過網路帶來高額銷售額，把傳統品牌搖身一變成為潮牌，拖鞋不再是隨便和不文明的象徵，而是另一種潮流。

所在產業沒有所謂沒市場，端看如何變化拓展新需求，任何產品有時候只是缺少了一點新鮮感、行銷手法，甚至是品質再升級。怎麼做？怎麼變？這已經是當今產業存活的尖頭問題了。

［定期短文］真假莫辨？！

竹子日誌（竹子） — Tue, 19 Jun 2018 07:57:20 GMT

在資訊爆炸的時代，我們生活中每天有海量的知識、資訊不斷流動，無論是停止接受，或是不再驗證，那麼你所得到的訊息都是別人幫你所捏好的。如果不能從本質了解所有的事件運作和目的來源，那一切都顯得虛假，一切都是被人灌輸，唯有驗證才是真實的。

今天無論你經綸飽滿，亦或知識豐富，或是經驗充沛，如果毫無實際驗證⋯⋯那麼都是被人所捏出來的。你，也許比你想像中的更加無知，比想像中的更加不思考獨立。

那麼，如何分辨眼前的訊息是真是假？

辨別是非的能力從根基開始，那就是建構世界的能力。先培養對邏輯性的推倒，重新組織對這個世界的思維模型構成。以後我會介紹一些「思考盲點」的書籍，幫助在思維上突破，而不受錯誤的引導。

當清楚何謂思考盲點後就要去懷疑每一個「理所當然」的邏輯和現象，因為那些並不是別人給你的，並去更加深入去驗證和思考。好比一個社會新聞，媒體記者文案怎麼說，你都照單全收嗎？還是會去重新思考它哪些訊息少說了，哪些訊息被加油添醋了，這些都是訊號。

或是使用另一個思考方法，「目的論」。思考整件事情的動機和目的，並不是指訊息中的當事人的目的，而是「為什麼訊息會到自己眼前」這個目的，然後再重新邏輯整個事件。

如果分辨不出來更不要貿然去定義，也不要輕易去評斷覺定，多花一點時間查，多一點時間建構思維模型，多一點深入的數據研究，就會不知不覺強化自己的判斷能力。

希望大家沒事多用大腦思考看看身邊每一個瑣碎的資訊，有時也會有意外的發現！

［心得感想］

竹子日誌（竹子） — Sun, 10 Jun 2018 08:31:11 GMT

這兩年來一直不斷鼓吹一個風，就是「創業」

經常看到放棄「博士學位」「某某科技主管」「年薪200萬」跑去創業當老闆，炸雞店、咖啡店、熱炒、義大利麵等等，所以吹起了這個創業風，因為創業就有希望，不用被現在的公司綁住壓榨！

但是創業開店當老闆真的有那麼容易，爽爽過日子？不好意思這邊我得告訴你，當老闆是沒日沒夜的，沒有所謂的下班時間，一開始也沒有絕對你發號施令就會有人幫你賺錢，全部都得下去親力親為。

創業前請你先想好幾件事情

資金：你是否擁有足夠的資金去做事情
資源：你是否擁有一些好的貨源人脈等等
週轉金：如果你做買賣業，貨的週轉，錢的周轉
運氣：有時做生意真的是嗆司嗆司
手段：你是否擁有一些該有的技能，面對同行的競爭
態度：你是用什麼態度去面對你的事業

以上這五點只是非常基本條件

下面幾點更是殘酷

每個月店租辦公室是錢（2萬～5萬）
每個月的營業稅（5%）
每年綜合所得稅（5%~45%）營利事業所得稅（17%）感謝粉絲提供修正
每個月會計師的費用（2000~7000 簽證更貴）
員工薪資（平均3萬）
勞健保（2個員工大約1萬初）
店裡所有雜支支出開銷（水電、碳粉夾、通訊費）
國稅局是否會請你去喝茶（請誠實報稅否則GG）

這些煩惱以外，還要煩惱哪些？

公司的產品是否有持續更新？
下一季的新的產品如何？
庫存如何打銷？
網路行銷策略怎麼做？
實體店面鋪貨？
對外業務誰來跑？
公司庫存是否正確？
公司每月報表檢視
進銷存系統，POS ERP 好的幾十萬套

還是你要開著excel記帳呢？

競爭者、對手公司分析擬訂策略
所以公司流程SOP誰設計？
採購上游供應商是否穩定
採購貨運報關稅金等等問題

…總總一堆屁事都需要您來顧的

「請專業的來就好」，你願意開多少錢？

或許你會說，我們請專業的來就搞定了！

我只能說你願意開多少錢？3萬？5萬？

而且上面這些事情需要幾個人去分擔

如果不願意可能就是請一個業助小妹2萬初

那你得全部重新訓練，那訓練之前這些誰會？

那就是你了！！！！！！！

以上都還不包含員工臨時性離職、員工效率降低、業務獎金配置、平衡每個人的業務量、振奮士氣等等你要想的事情，開公司是一個團體，

以上還得再檢視，公司健不健康，你公司毛利是否能支撐公司的開銷，如果公司毛利太低，是否業績掉了1成就會賠錢GG呢？那你賠錢又準備了多少錢可以燒呢？

但是講了以上這些不是說創業開公司不好，而是你真的準備好了嗎？

常常聽到當老闆的說「還是回去當個打工好了，比較輕鬆業績做到就可以領獎金」。

各位創業的老闆一起加油吧！

如果你看完認同，分享出去吧！

有任何想交流就留言吧～

想傳達給朋友或學生的兩個概念

們想傳達給朋友或學生的概念很簡單：

時間的力量很重要，儲蓄和正確理財，當你累積10年，也才25歲，但過去的打造的資產會變成你最得力的加薪工具。
斜槓世代已經來臨，10年後正式出社會時，多元收入會變成常態，準備好自己的腦袋，才能更優雅的迎接未來！

我看到這篇文章有些感觸，所以打了這篇文章。

國高中該放手去玩、去嘗試

我倒覺得國中高中就該，放手去玩樂，放手去嘗試，放手去體驗。不要重複在單調重複的事情，儘早奠定人生的指標與方向，讀書不會是最重要的，讀的好是加分，讀不好並不會減分。反而無所適從盲目讀書，沒有好好與同學朋友互動，沒有認真思考未來的方向，那才會走更多冤枉路。

理財也是一樣，去體會錢的價值，去消費，去賺錢，去投資，去做小買賣。消費花光了，不要負債就好，投資賠光了，再賺就好，做生意沒賺，學到就好。國中高中煩惱賺錢的事對嗎？我認為賺到多少賠了多少無所謂，這個年齡是學習力最巔峰的時期，儘早培養自己的財商對未來的幫助更大。

大學時因為成年了，就要小心社會險惡，父母不可能一直保護自己。此時也得開始學習獨立管理自己的收入與支出，並瞄準未來的目標計畫、學習、執行。

出社會之後，多維度擴充自己的資源

出了社會的新鮮人，不要好高騖遠，也不要安逸舒適，盡全力嘗試和挑戰，因為年輕就是最大的本錢。不要認為一份工作就足夠了，更要去思考「萬一我現在待的產業消失了我能去哪？」這件事，並去多維度擴充自己的「資源」。我常常說，資源不少限制在資產、貨幣、人脈而已，興趣、性格、技能更是稀有的資源。

斜槓時代來臨，如何結合自己的優勢，搭配不同領域的專業，有效的整合，打造獨一無二的自己，這就是無可取代的「斜槓青年」。

［知識小補給］發電系統（下）：火力發電

竹子日誌（竹子） — Sun, 03 Jun 2018 07:45:10 GMT

第一節：火力發電

蒸汽發電是最原始的工業化發電機，原理是使用鍋爐燃燒純水，當水沸騰後產生的蒸氣後形成高壓動力，利用這股動力推動葉輪產生動能，動能再推使發電機運轉。這種汽旋發電機雖然很基本，也有很多優點，不盡然舊而沒有優點。

火力發電（汽旋機）

優點：

1.噪音小

2.廢熱少

3.性能曲線穩定

缺點：

1.效率及轉換率差

2.體機龐大

3.造成的空氣物染大

另一種火力發電就是內燃機，說直接一點就是像汽車引擎這種機體。利用壓力產生爆震，再利用爆震的力量

［知識小補給］發電系統（上）：台灣的能源難題

竹子日誌（竹子） — Sat, 02 Jun 2018 14:42:02 GMT

現在台灣面臨極嚴重的能源問題，竹子我剛好有一些電的相關常識，我會解說一些關於電的知識。當然，也會主張一些價值觀，無論是認同或不認同，站在專業人士的立場就有我自己的一套觀點。

每一種能源背後都有它的優點和缺點，當然也有它的商業價值和連動產業。因應時事，最近吵著油電雙漲和缺電停電等等問題，其實背後都有其不可告人的因素。所以，除了知識和科普外，也讓大家隨著我的思維去觀察產業的連動性，藉此也可以去了解「當什麼產業蓬勃發展會帶動什麼產業」這樣的思維。市場的風向也是從這裡去觀察出來的，當然也包含了許多的外在因素。

這時不得不推薦一下史蒂芬的「蘋果橘子經濟學」這本書，是一本從經濟學為出發點看現象的書，日後我再敘述一些裡面有趣的小故事吧！

接下來的文章暫時著重在能源發電這個部分。

［議題討論］思維定錨

竹子日誌（竹子） — Fri, 01 Jun 2018 08:22:56 GMT

你們是否有一些別人給予自己的思維？那些思維真的是合乎邏輯合乎世界運行法則？那倒不一定。這世界確實有運行法則，但是不一定符合我們的既定觀念，甚至我們有時候被道德、倫理、科學、教育等等既定的印象而影響思維，但那些都是事實嗎？

就拿最經典的例子，「努力會有回報」。

有回報嗎？未必，那事實是如何呢？

事實是「努力是快速嘗試各種方法和規則，縮短找到成功與回報的法則。」但是運氣成分不就很重？重點不就是掌握規則？

當然，這個論點也非常龐大。但是思維定錨確實是個大問題，綁死著你的方向。

那麼，你覺得生活中有哪些常見的思維定錨呢？

蕭老師舉例的「吃虧就是佔便宜」說得很好！

正確來說不該吃悶虧，吃虧就是吃虧，佔便宜就是佔便宜，但不是指表面的「吃虧」和「佔便宜」，而是事實上的狀況。事實是什麼？是由多向的分析和詮釋由精確的數據得以結論的狀態。

那我也推舉幾個我常發現的思維定錨吧！

1.要穩定有一技之長才不會沒飯吃。

正確應該是說，要有「具市場價值的技能」，如果一身技藝卻沒有市場價值，那還能怎麼打混？一樣沒有人要，反而要深掘多維度的能力，並去結合新興產業產生無可取代的優勢，並開發市場價值，那才真是長遠。

2.只要認真學習，才會成為有用的人。

跟上一則有相同的道理，學了很多東西，但是都是在特定範圍才有用的知識，當轉換跑道和去向，自然就沒有可用之處。應該是去學習通用或現缺的知識，如此才會學到真正用的到的東西，而不是侷限在地域和環境限制的東西。

其實還有很多，但是牽扯到價值觀問題，所以就不再多說了。

其實還包括善惡有報、按規定執行、下班還得多努力⋯⋯其實舉例不完。

不過也希望大家多加思考，不要陷入定錨思維，多嘗試用不同的角度看事情。

［議題討論］一份薪水夠了嗎？

竹子日誌（竹子） — Sun, 27 May 2018 06:38:45 GMT

從107年勞基法基本薪資的修改，現在起薪22k的年代，你怎麼活？我尋訪許多人，薪水分別在未滿22k，已及到40k以上的35歲內的年輕人，每個人生來際遇不同，但總看得出些什麼。先天的資源、後天的努力、努力的方向、生活的態度這些都實實在在影響著。只能說雖然認真努力不是絕對的，但是不做任何努力什麼都沒有。那麼，要多少的薪水夠養活自己的家庭和自己的一輩子呢？那看看現在的收入肯定是不怎麼足的。那到底多少的薪水才足夠呢？究竟除了薪水外還有什麼方法可以突破現狀呢？

很多人，每天工作等著領那份死薪水。也許22k，也許全勤加個3000元，也許工作多年加個5000元，也許加班加到爆表才衝上40k。但是這也是大量的心力與勞力換取的，還是只有這樣，距離年薪百萬也是頗有距離。年薪百萬是夢想，也是一個糊口飯吃。

當然也有人認為我一個月22k活的好好的，我幹嘛去拼那麼多薪水？但認真算，如果自己在外租屋低生活需求，平均一個月也要25k。如果要養家糊口，一個家庭也要35～45k。如果要買房買車，貸款算一算沒有60k實在很難支撐整個生活，除非更加擁擠更拮据。

問題來了，那扣除薪水還有什麼提高收入的手段？不外乎「兼職」、「創業」、「投資」三大方向。你又是屬於哪一項呢？

［議題討論］499之亂

竹子日誌（竹子） — Wed, 16 May 2018 09:14:15 GMT

這次中華電信在母親節前夕大舉出手，祭出了499方案，引發空前激烈的客戶搶奪，台灣大哥大和遠傳電信也相繼跟進。此時引發許多人排的現象，趕著要解約續約，也造成諸多社會問題。雖然結束了，但是可以一同看看，是否發現到些什麼呢？

從經營面看：一塊搶到見骨的餅

從經營面來講，台灣的客戶就是一個死邦邦的市場，這塊餅就這麼丁大，能有多少人能搶？能有多少人能爭？除了中華電信，遠傳電信、台灣大哥大、亞太電信、威寶電信等等，還有急起直追的台灣之星，各方人馬都來吃這塊電信的餅。現在真是誰吃到的多誰就肥，綁約一個客戶就決定後面多個月的收入，能不競爭嗎？雖然中華電信的老牌過去非常霸氣，價格就是跟大家很硬，從開放1499網路吃到飽加網內通話吃到飽已經是大家跌破眼鏡的讓步，加上後面的電信來勢洶洶在搶攜碼用戶，看來營收勢必衝擊。之前軍公教499方案已經殺紅眼，多少人用盡手段想讓自己通過這個方案。看來一個試水溫試出甜頭，加上近年手機市場競爭激烈，利潤持續縮水，乾脆來一個薄利多銷搶客戶的全民499，這下衝擊整個電信產業。遠傳電信和台灣大哥大見到這個狀況，立馬跟進，一樣推出499專案想制衡市場，這下真的搞的整個市場動盪不安。不過也足足惹怒不少老客戶，他們紛紛抗議都不照顧忠實的客戶，他們之前續約的都虧大了。這下覆水難收，盈利後還要整頓混亂的市場，現在電信業者該如何處理呢？那消費者的心態又是怎麼回事？

消費者搶這波，究竟合不合理？

消費者搶這波究竟合不合理呢？其實在中華電出手當下其他電信業者也是保持觀望，不料反應熱烈，也是跌破電信業者的眼鏡。為了制衡市場不得已混入這場戰爭。過去大家使用手機，依據使用狀態，100元以內的資費，以及上看近千元的資費都有。近年網路電話漸漸取代傳統通信，只要吃到飽等於不會超棒電話費，消費者一個算的比一個還要精明。但是大家為什麼會對這種現象這麼斤斤計較呢？恐怕這並不是好的兆頭⋯⋯

斤斤計較的背後，是 M 型化的社會

怎麼說？這代表這社會走向更加M型化社會，富者恆富，貧者恆貧。那資金的流向逐漸更加靠攏大企業老闆，中小型企業資金逐漸流失，所有資金遊戲將由大企業掌握。大公司敢拿錢去爭取市場，而小公司沒有資金能夠抗衡，最後流失市場。

而會去搶便宜的消費者永遠是社會底層的人才會計較這些東西，又是被宰割的羊兒。真正手中擁有一定財富的人是不會花時間去做沒有生產力的行為，一定還是朝有生產力的方向邁進。那資金又單向往大企業流動，底層仍然無法振作。

沒搶到的別難過，明年還有 5G

另外，沒有續約到的別太難過，明年還有一波浪潮。那就是今年高通公司發表，5G已經技術成熟，估計明年會開始商業化，勢必會推出5G手機和5G的新方案，互聯網邁進即將下一步飛越！懂的人應該就嗅到錢的味道了～

［議題討論］工作在哪？

竹子日誌（竹子） — Thu, 26 Apr 2018 04:27:06 GMT

說到找工作，真不知道是多少人的惡夢，有些人在不斷找工作的循環夾縫求生存。找工作有的人說很難找，投履歷後輾轉就過了數數週仍尋不著邊，待業依然在待業。你覺得工作很難找嗎？你有哪些找工作的方式呢？

其實找工作大家最害怕的還是遇到慣老闆吧？待遇不好，動不動加班，沒有前景之類的⋯⋯相信這都是大家恐懼的部分。這些細節太多，以後我們再一一提出討論。

為什麼那麼多人卡在待業

我們先問問四周的人，是不是很多很多人待業很久呢？或是待在一份工作嫌東嫌西，卻遲遲不敢辭職推託外面工作不好找。這到底怎麼回事？事實不外乎以下列出的原因⋯⋯

1.好高騖遠：有些人自認清高，覺得自己能力出眾，巴蛇吞象，一開始面試就獅子大開口要求不合理的薪資，或求的職位遠超過能力所及。

2.履歷不好：這有分兩個層面，一個是不會修飾履歷，沒辦法用理想的履歷內容博取審核履歷的人員他們的眼球。另一個層面是硬傷，就是社會新鮮人或學歷不好看的人。一般人看到這種履歷就先刷掉，連給你面試的機會都沒有。

3.數量不足：找工作不能只去一個地方找，而是要用各種不同的地方找，不要認為等通知就不敢繼續找，因為企業不差你一個。甚至去嘗試10幾間10幾種公司都沒關係。也不要只用投履歷的方式，應該是多種方法，比方說去出門找直接詢問、去問親友哪裡有缺人、去社群版詢問是否有相關需求。

4.要求複雜：比方說不要輪班、不要有加班、要特別的上班時間、要見紅休和週休、要離家近、指定專長領域、短期性工作⋯等等不勝枚數。

以上簡單提出癥結點，但是也有提到「薪資待遇」是一個嚴重的問題，總不能餓肚子工作吧？懷才不遇怎麼辦？說找簡單，真的沒有啊？我後面幾篇依序說下去。

老闆為什麼要雇用你？

首先，很多人會苦惱履歷的部分，為什麼？就是沒有專長，就是沒有特殊經歷，就是沒有學歷，怎麼辦？那就要有「為什麼老闆要雇用你」這樣的思維。

老闆沒有義務要養你，更沒有責任要雇用你，不要認為是別人欠你的。要用，先提高競爭力，什麼競爭力是有效有用的呢？

當你要投入的是技術工作，那就要有相符能展現實力的作品、證照。當你要投入的是服務工作，那要調整說話口條，整體自我形象，外貌打扮等等。當你要投入業務工作，就要有銷售的實績、經驗，對相關品項的知識必須非常熟悉。也有不管去哪都萬用的，「外文」，這是目前任何產業都有需求的，首當其衝的就是英文，近年台灣市場日文、韓文也在蓬勃發展，有外文能力就是大加分。

那我都沒有都不會？要技術沒技術，要外貌沒外貌，要口才沒口才？那就去擁有，沒別的方法。學習、練習、見習，擠出一切空餘的時間。打扮、減肥、化妝，無所不用其極。社交、網聊、搭訕，增加更多人際經驗。這些都急不來，但是你都沒有就不被需要。

光是滿口的怨言沒有辦法改變現狀，唯有直接去改變現狀，讓自己不擁有的東西將它擁有才是解決之道。

沒學歷、沒證照、沒經驗的時候怎麼辦

但有些時候就是資源缺乏，但是就是要有工作才能夠賺錢，才能夠取得相關的條件，或是根本上需要時間。比方說學歷、證照、經驗，如果是社會新鮮人根本有困難。

這時，你該怎麼辦？

如果你還在求學，也有家人的支柱，或是你開始工作，也住在家中，那恭喜你，你有最珍貴的資源「時間」。如果很不幸，你是獨自在外打拼，舉凡的開銷與生活都要承擔，或說家中的一切都有困難，需要經濟支柱，那我也恭喜你，你會更懂的去管理和珍惜「時間」。

單一維度已經不夠，自學是必備技巧

為什麼要這麼說？因為無論如何都要不斷學習，這個社會已經不能再用單一維度去縱橫，而是要多維度打造全新的技術人才，用你獨特的專長組合出有競爭力的能力。「自學」已經是一項不可或缺的技巧，不再是過去等著別人去教授你的時代。

假設，你是行政人員，你單單只會操作電腦文書軟體是不夠的，可能你還需要行銷能力、協調能力、操作修圖軟體、程式函數撰寫、外語能力⋯⋯等等。你可能會認為，我會那麼多還會怕找不到工作？我要是那麼厲害老闆是不是要付我更多的薪水？這就是重點！就是要多維度展現自己，這樣你才「不可取代」，這樣你才擁有獨一無二的價值，才有和老闆談判薪水的優越能力。不然？你走了還有下一個，現在不辛苦一點，永遠在社會底層。

另外就是學歷和證照的問題，考試要錢、讀書要錢、補習要錢，什麼都要錢和時間，我現在什麼都沒有怎麼辦？光是被看到履歷表就先刷掉，連給我面試的機會都沒有。

從 0 打造履歷：先走出門去問

履歷內容不良，該怎麼辦？

沒有好的履歷內容，就只能從0打造履歷。首先你先走到戶外，到家中方圓5公里內所有店家門口，也許你會看得到徵人的廣告張貼。如果，你嘗試挨家挨戶問有沒有缺人？也許你會問到更多工作，你就越級突破到「面試」。或許你也可以上網到論壇、社團、社群詢問，你可能被砲轟，但是也會有人找上你要提供你工作，可以直接用電話聯繫到老闆或高階主管。這時只要展現談吐能力、技術展示、作品等方式，都可以立即博取面談者的信任感。

有些人卻更煩惱，真的沒有任何可以表現的東西，好比畢業的新鮮人，那還真沒辦法要求什麼。除了靠運氣跟親友介紹外，就是隨便找份「有薪水的工作」，利用閒暇時間培養自己的「資源」。

有些人可能仍然質疑「有薪水的工作」的工作是哪些？依據現今，從軍、保全、服務業、工地雜工⋯等等，完全不擔心真的沒工作做，只是「想不想」做的問題。

［議題討論］商品價格

竹子日誌（竹子） — Fri, 13 Apr 2018 08:11:40 GMT

這個議題真的是極其爭議的議題，每個人對於產品的想法和概念不盡相同。一派人認為，價格就是鬥出高下的地方，每個人割喉競爭殺紅眼，對於每個客戶極其所計去爭奪。那另一派認為，我要建立的是高品質品牌，絕對不輕易降價，我要以高水準的品質取代低價。

然而這兩派都有成功者和失敗者，難道任何一方是對的嗎？或是陷入迷茫的爭執？

這個議題比較複雜，我首先以兩派思維的思考模式進行敘述，後面再詳談評估點和手段。因為這問題是一體兩面，不存在正確與錯誤。

那你又是贊成哪一派呢？

低價派：價格是最快擄獲消費者的東西

首先我講述主張低價的一派。

其實人們就是希望以最低的價錢取得最理想的商品和服務，這是一個最常見的消費者心態。縱使宣稱高品質高價值的東西，價格超出一般消費者所能接受的範圍仍然是不買單的。價格就是每個競爭對手廝殺的東西，極其手段降低成本，對上游在上游爭取更多的利潤，最終拿出最划算的價格，這就是殘酷的市場競爭。

降低價格無疑就是降低利潤，所以才有薄利多銷一說。但是如何有效降低成本來鬥市場也是很高的學問，任何獲利只要能壓低成本就能夠在價格上得到更加漂亮的數字。

縱使品質再優秀，但消費者若感受不到價值，就只是昂貴的商品。這時，只有價格能第一時間擄獲消費者的心，你夠快速打動消費者進行消費。價格低廉的同時，只有通路打開，不需要多餘的廣告、行銷、宣傳便快速有許多消費者買單，進行基本的曝光就有非凡的效力。因為商品的數字就能最快吸引眼球矚目，只要讓消費者物超所值有感覺就可以輕易打響。

價格戰的另類手段：門檻價格

當然，價格戰也有另類手段，就是「門檻價格」。一般可能會對某種品項商品有一個價格的天秤，在那個基準範圍中的低標就是門檻，在同類產品中犧牲它的份量、大小、範圍、尺寸而擁有較低的價格，讓其他人認為「這個價格我可以嘗試看看」的感覺，以達到綁定客戶的效力，以便下次進行重銷，養育客戶群。這也是一種手段，同時達到在價格戰勝出的一環。

那有必要犧牲價格去投資品質嗎？

那有必要犧牲價格去極力投資品質嗎？

當然，價格低廉是如此極端吸引人，但是也有一派說法是品質才是真正的經營之道。

品質一說是一個盲區，有許多業者會追求價格犧牲掉品質，導致很多人都有錯誤的品牌迷思，認為高價品擁有高品質，而低價都是瑕疵品，導致大家對價格的要求與看法更加複雜。比方說，1杯30元400cc的手沖咖啡你敢喝嗎？1件50元的潮T你敢穿嗎？1罐50元300ml的化妝水你敢擦嗎？這都是我們常常會遇到的「暴利產品」，如果貼近成本的時候有時我們不禁產生懷疑，事實上材料成本大概是上面價格的3分之一不到，那這意味什麼？

但是就鼓勵你買低價產品？我想告訴你的正好相反，我要說的是業者一樣要經營管銷，這些成本不只無形，還非常巨大，為了維持通路和名聲，大量砸下大把大把的鈔票。那高價不一定有品質，更何況低價？所以站在消費者的立場可以思考為什麼貴？真的是高品質嗎？消費者要的事實上不是低價，是物超所值的保障和產品體驗。身為老闆的你就有頭痛，我要低價嗎？還是調高品質與成本呢？

為價格而來的客戶，也只會因價格而走

行界有句話：「什麼樣的價格就會吸引什麼樣的客戶，為了價格而來的客戶，也只會因價格而前來，也只會介紹為價格而來的客戶。」

這就告訴我們對價格必須有所堅持，當品牌之路步向低價路線，自然會養慣消費者，當日後價格上漲自然就衝擊業績。就好像習慣打折促銷的產品，消費也喜歡等促銷才願意掏出錢包，所以價格也不是能輕易讓步的部分。

那麼，你是支持低廉價格還是支持高價高品質？還是有更好的方法嗎？

淺談網路行銷

竹子日誌（竹子） — Tue, 27 Mar 2018 11:23:56 GMT

台灣的市場實在太小，加上台灣經濟陷入瓶頸，資金的流動可以說是非常差。做生意的都知道一定要做有市場的生意，但是如果你的族群是小眾市場，那更是要往世界發展。加上現在人手一支智慧型手機，網路的侵蝕力可見一般，非常可怕。

消費與否的三個要素：需求、信任、能力

行銷這件事目的是要降低銷售的難度，權衡一個人是否消費產品在幾個要素：「需求」、「信任」、「能力」，三大要素。

需求指的是對於產品帶來的「問題解決」能力有關，消費者卻是在生存上產生痛點，因而誕生需求，而滿足這個問題被解決的產品就是滿足需求。

信任是對於商品品質及價值的信任感，或是對於品牌形象的信任感，對於人則在於其好感度和專業度來建立自己的信任感。

能力指的是消費者的消費能力，白話說就是他夠不夠拿出產品最低標的資金。

行銷真正在累積的是信任感

而行銷目的除了在「傳遞」產品訊息外，最重要的是累積潛在客戶的信任感。信任感的累積是透過一「價值的提供」來取得層層的堆疊，讓客戶感受到品牌或產品本身能有效滿足需求。其實最有效的方式就是深植人心的廣告和行銷訊息，但是普遍人看到銷售訊息是「不舒服」的，那該如何有效去傳播不讓人反感的行銷訊息呢？就是提供「價值」，輕鬆詼諧的廣告文案、專業知識的訊息提供、超過期待的服務項目⋯⋯等等，這些都是提供價值的手段。一昧強壓把訊息塞給消費者帶來的是不適，就像不希望老師及父母強灌他們的期待在自己身上，那是一種具抗拒的心理狀態。

行銷的策略延伸就多不勝舉，廣告方式這麼多：活動、宣傳、推播、業配⋯但是什麼才是有效的呢？

過去有效的手段，現在都失效了

過去在資訊流通速度緩慢的年代，可能發傳單、打廣告刊板、廣播電台、電視廣告等等都非常有效。但是人類的感官是會疲乏的，每個人每天都被數以千計的廣告轟炸，過去有效的手段都不再有效。但是我們進入互聯網時代後，人手都有手機，自媒體時代興起，多媒體廣告金人戰國時代。包含影音業配、社群經營、網路插件廣告、直播推播⋯⋯完全是無時無刻都離不開網路，利用這點，網路行銷的技術孕育而生。

哪一種網路行銷適合自己？

那麼多的網路行銷方式到底什麼適合自己呢？其實這就牽扯到產品品類、品牌品類、營銷市場、品牌風格有關係，並沒有要衝堪稱萬靈丹的手段，每一種手段都有其優點和缺點，但是唯一不變的就是價值提供這件事情。再搭配促銷的「急迫性」，常常成交就是這一推一拉之中成立。

［議題討論］夾娃娃機

竹子日誌（竹子） — Tue, 13 Mar 2018 12:45:01 GMT

有沒有發現近幾個月夾娃娃機店的數量狂飛猛增，網紅們四處朝聖各地機台，掀起一波風潮。夾娃娃機是真的有那麼好賺？業者為什麼那麼快可以拓展那麼多的機台？

這個議題可以讓大家去觀察看看，是不是真的多了這些機台呢？

夾娃娃機其實都有管道可以購買的，這種商業模式就是開一間迷你的店，它的營運上幾乎是自動的，能夠帶來被動收入的一種模式。

夾娃娃機的營運方式很簡單，挑一塊好的地段承租，要有人流且容易注意到的地方。再來是挑選標的商品，然後選擇一個適合的機台，基本上就可以開始營業。所有需要的勞務就是地租電費的繳納、商品的補貨、機台的維護等等。

其實在管理上可以說非常單純了，門檻也不算太高，相較一般的創業也簡單許多。但是心態上卻也很重要，因為必須抓住人們對於夾娃娃機的心態。

首先我們能夠先思考，為什麼會想要夾娃娃？因為想要機台裡面的娃娃嗎？好像案情不單純吧！其實跟吃吧費一樣的道理，就是人性的「貪婪」而已。許多人認為我只要投10元的銅板就有機會可以夾到超值的商品，所以夾娃娃機除了娃娃什麼都看得到，包含著日常用品抑或是高價品都是屢見不鮮。

但卻有另一類人，他們不計代價去玩，夾娃娃所繳納的學費遠遠超越夾到的東西。他們要什麼？成就感！一個技術的認同感，一個完成某件事的成就感。反而是這群人更能夠登峰造極，用最划算的銅板取得商品。但是他們也是付出許多的「投資」，培養出超越一般人的技巧才有對應的回報。其實在相對的數據算下來，業者還是有一定程度的獲利。

我的目的並不是鼓勵大家去夾娃娃或是買娃娃機要開業，那其實都不重要。最重要的是什麼？是思考，思考為什麼要夾娃娃，思考商業模式背後規劃了什麼？

［議題討論］Uber的衝擊

竹子日誌（竹子） — Tue, 13 Mar 2018 12:27:13 GMT

大家都知道「共享經濟」的發展，最具有代表性的就是Uber，它可以說是共享經濟體系成長的標竿。但是它的誕生重重衝擊原始產業的生態，新的東西勢必會影響或是取代舊有的東西，而Uber影響的就是傳統計程車運輸業。

那Uber的引入競爭，國內吵的沸沸揚揚。一派說Uber根本不合法，也沒有對應的保障，國家不該讓Uber合法。另一派說這是趨勢，國家應該立相關法規，促使這種科技與經濟體融入社會。

那你是贊成還是不贊成呢？我會依據兩派人馬的意見提出看法，講述利與弊。

贊成派：便利、公正、還多了一份資產利用

首先說贊成派的吧！Uber是共享經濟跨時代的進步，帶動出新經濟體的誕生。它提供每一個擁有車的人平等的對待，每個人只要上網註冊登入，就可以簡單做這門生意。它便利，隨叫隨到；它公正，設定好目的地價格全部由系統運算；它安全，無論開到哪全程衛星導航定位你的位置；它可以奢華，你可以用最划算的價格達成高檔的車種。

買車過去是一種高昂的開銷，沒辦法帶來任何經濟上的反饋，保養、加油、停車、稅金⋯處處是花費。Uber的誕生讓每個人的汽車除了代步工具外額外賦予全新的價值。它將會是一種投資，一種價值分享，一種資產利用。

現在時代的進步，找出租車不再要仰賴事先電話叫又講不清楚，也不需要找便利商店叫，更不用在路邊攔，手機互相定位對方的位置立即配對合適的車。對於使用者端來說可以說是帶來巨大的便利。

由於全部的系統線上作業，屏去過往司機喊價的弊病，也除去過往跳錶繞遠路的行為。全部的路徑、價格、目的地等等要素在發車的當下全部計算完畢，沒有弊病存在。真要說有弊病大概就是Uber系統的演算公式，然而還是比計程車便宜。

還有就是安全，系統要求駕駛要開啟定位，任意關閉定位會被系統追蹤。乘車者也隨時可以發求救訊號給Uber公司，任何狀況能立即追查位置，確保乘車的人身安全。

尊爵優步這項功能，這要有Uber官方認可，由高檔的車種來駕駛，並提高載客的服務標準，讓乘客有賓至如歸的感受。這種服務也帶來不同層級的市場需求滿足，給予不同的差異化服務與體驗。

特別要提的電子支付，它不再是現金交易，出門不仰賴現金，與電子帳戶進行同步，由第三方Uber公司作為把關。

科技的進步全部在Uber上面徹底展現出來，緊密結合共享經濟、行動上網、衛星定位、物聯網、電子支付。你認同它嗎？

反對派：不用考照就能上路，對誰公平？

再聊對Uber的反對。

其實對於Uber的反對大宗在運輸業，特別就是原有的計程車市場，畢竟生意被搶了嘛⋯⋯

首先來說的是計程車業的反對，他們認為Uber是不合法的，也不安全。安全這點不管是Uber還是計程車業都有漏洞，並沒有哪一項可以說特別安全，都有它的限制。

以Uber的缺點來說，直接性的就是駕駛本身。Uber的駕駛不需要任何的考試和證照，更沒有公會團體的限制和資金的體制機制，大大的降低入行門檻。這種體制下自然對原有的運輸業十分不公平，也不符合法律的規範。

直接說，就是Uber來破壞現有規則，鑽著法律漏洞來運作。很多職業都需要證照的國家認可與公會的營運認可，但Uber完全跳過這些東西，不合理不合法經營，成為法律的死角。

法規與課稅的死角

法律目前並沒有任何規範允准Uber用這樣的方式經營，當然，台灣Uber已多次被罰款。

政府為什麼不認同呢？因為這種營運方式政府在課稅上比較困難，並沒有相關法令以及依據可以課稅，目前要被國家認同也尚有難度。

當然有人會說Uber也容易發生駕駛和乘客糾紛，因為沒有公會和營運執照保障。不過我倒認為這是空談，兩者各有缺陷。

趨勢擋不住，但台灣跟得上嗎

Uber贊同也好不贊同也好，世界共享經濟的趨勢無法擋，一波波襲來。這種商業模式的誕生代表電子支付的潮流到來，不再受限現金支付，台灣跟著世界趨勢腳步緩慢前進，是會迎頭趕上還是被甩在後頭呢？

說我是贊成還說不贊成？本身Uber這件事沒有對錯，只有觀點不同而已。但是透過Uber你看見什麼？台灣計程車業者的病態？世界的趨勢？都好，都是一種學習。

［技術分享］傳統燈具和LED燈具

竹子日誌（竹子） — Tue, 13 Mar 2018 11:47:37 GMT

家家戶戶都需要照明的設備，隨著LED的技術成熟，價位越來越平易近人。但是大家都說LED比較省，是真的省了嗎？LED的價格雖然降價，但似乎沒有低價到和傳統燈具平起平坐，仍然貴上數倍。

首先幫大家回憶一下國中理化教的「功率」，功率代表電在作用過程中消耗掉的電能，而台電在計量的「度電」就是功率演算出來的。在相同的性能與功能下，如果標示功率的數值更低，那麼就是「省電」。

普遍傳統鎢絲燈泡每顆的消耗功率大概40～100w，依據規格亮度不同而不同。傳統家用燈管長型的每根40w，大概就是客廳那根快一公尺的那根。後來人發明了一種燈具就是電子點燈，因為更省電，也用來製造省電燈泡，就是外面看到的螺旋形省電燈泡。但是價格大概貴上4～12倍不等，卻省20～40%的電而已。再來是近年極其興盛的LED燈泡燈管，價格大概比傳統燈泡貴上8～20倍，省電效能提高到40～60%。那是否真的有投資必要？貴這麼多！

那真的有換LED的必要嗎？

待續⋯⋯

其實LED還有其他優點。第一，沒有傳統燈管的「啟動」，因為傳統燈管打開的瞬間會消耗的電量大概是持續亮著15鐘的電量，小時候教的隨手關燈如果開開關關反而是燃燒你的電。第二，壽命長，因為LED是由許多小顆的LED燈泡組成（發光二極體），當一顆失效時其他都仍然有用，加上是弱電的系統穩定性高非常多。

所以是慫恿大家換LED嗎？並不是，其實端看你對燈具的使用量，有的人很少開，或是每天回家也才開那4～6小時，其實真的沒有必要花大錢買LED。除非你有營業用途或是工作用途，LED相對壽命、亮度、電力消耗是比較優良的。另外，現在很多人開始會使用LED燈管，但是因為供電特性不同，把整個燈座都換掉，真的非常浪費。如果外觀和結構堪用，其實傳統燈管的燈座是可以改裝成LED使用的⋯⋯只要買燈管耗材就可以，方法嘛⋯⋯就來問我吧！

［議題討論］衛生紙的搶購熱潮

竹子日誌（竹子） — Wed, 28 Feb 2018 03:42:27 GMT

前幾天發生激烈的衛生紙搶購風潮，其原因為國際紙漿即將調漲，未來衛生紙會有一段波幅的上揚。然而，這種搶購風潮帶來什麼影響？你會去節省這些未來即將的開支而去投入這段搶購熱潮嗎？

其實衛生紙的搶購熱潮非常嚴重，聽人說，賣場的衛生紙區一件不剩都被掃空。

但是，真的有搶購的必要嗎？其實早在發放國際紙漿上漲的消息前，衛生紙的價格已經被上漲一波，價格早已不是最划算的時間。有時候世界的物流期貨價格是波動的，現在漲了不代表未來不跌。

但其實最昂貴的並不是在這些貨幣上看到的數字，還有許多「時間成本」、「空間成本」、「機會成本」。排隊或是開車特地去買，這趟過去無形中消耗掉的成本可能遠遠超過你帳面上省下的錢，時間、交通⋯⋯。台灣地價不便宜，在台北更是寸土寸金，囤積這些衛生紙浪費這些空間是一種成本。

從其他面向來看，不談省不省這件事。

這波搶購，直接去促使「漲價」這件事發生的必然性，需求增加了，供給追不上。世界紙漿價格雖然漲，但是廠商從中獲得的利潤也不過這樣。然而，透過消息的傳播形成恐慌，使銷售單品數量增加，獲利也跟著來。你認為其中不包含操作嗎？有時候很多價格的波動都是有跡可循，這波的漲價又是因為什麼呢？

這種商業消息的操作常常都是一種行銷手法，既然你圖利不到也省不到，那誰圖利了？誰從這事件獲得最大的利益？

認真思考後會發現生活中的事件佈滿陷阱，多思考多站在不同人的角度，就會發現更多有趣的事。

［議題討論］抱怨問題與面對問題

竹子日誌（竹子） — Tue, 27 Feb 2018 08:22:58 GMT

雖然抱怨是一種抒發，但很多人認為職場上抱怨職場問題是不好的，但是非常正面積極又是好的嗎？另一種人，會明確點出問題點，積極點出問題並追究問題點的發生原因與責任追究，這是對的嗎？兩面各有其說法，大家怎麼看待呢？

這邊依然提出我的看法。

我先講後者，積極追尋問題，然後針對問題提出異議，然後去追究問題發生原因，這顯然是好事。但是，如果只是把問題抓出來，並且去「敘述」它，這只是在抱怨而已。如果遇到了問題，去追究去處理不對嗎？這並不是針對問題本身，去追究問題相關責任人，然後去處理問題造成的結果是一個治標不治本的概念。怎麼說？一般的追究問題是請相關問題的責任人去解決「已產生的問題」，但是並沒辦法杜絕問題一再產生。

前者，積極正面相信是大家一致認同的，不抱怨、樂觀取進、正面能量、努力向上、遇到問題不會拘泥，看起來是多麼完美！事實上這樣真的好嗎？如果對於事情抱持過度的樂觀反而不會去思考許多問題的本質，去根究本質才能夠思考面對問題。我也見過許多樂觀單純的人，但是常常過多的正面變成忽視問題的人，也不會去發掘問題給大家處理，最後也是不知道自己在做什麼。

依照我的觀點，我贊同提出問題但不是抱怨，我贊同正面積極但不是忽視問題。我最認同的是積極思考，面對訊息去思考它多面向的含帶意義，而不是傻呼呼看著事件和訊號發生到結束。更不是人云亦云看著事情運轉，沒有任何自己的主見邏輯，「別人的邏輯建構就是自己的觀點」這種荒誕可笑的現象。

當你順著一件理所當然的事情前進時，你反覆去思考過它嗎？是用什麼角度去看待呢？還是跟過去的自己一樣沒有任何的思維轉換與跳脫？試著再多思考一下吧！

［知識小補給］健康手環如何檢測運動

竹子日誌（竹子） — Sat, 24 Feb 2018 16:14:38 GMT

運動手環能夠計步和測量距離是由硬體和軟體算法兩方面組成，缺一不可。

硬體：三軸加速度感應器

硬體：指手環裡面內置的三軸加速度感應器，一般為軍用級，其實三軸加速度感應器不神秘，在大多數中高檔手機里都有配備加速度感應器，只是在偵測精度上達不到手環的級別。

三軸加速度感應裝置的三軸是指空間中的X，Y，Z三個維度，有了這3個維度，手環就可以捕捉到手環在使用中的加速度變化，從而生成數據。重力加速度大家初中物理課上都學過，它就是用這樣的原理感應。

軟體：從三軸資料算出步數與距離

軟體運算：程序源根據三軸加速度實時捕捉到的三個維度的各項數據，經過濾波、峰谷檢測等過程，使用各種算法和科學縝密的邏輯運算，最終將這些數據轉變成手機APP端的可讀數字，步數、距離、消耗的卡路里數值等呈現在最終用戶面前。

基於重力加速度的基本原理去實現工作的，加速度是個空間矢量，一方面，要準確了解物體的運動狀態，必須測得其三個坐標軸上的分量；另一方面，在預先不知道物體運動方向的場合下，只有應用三軸加速度傳感器來檢測加速度信號。三軸加速度傳感器具有體積小和重量輕特點，可以測量空間加速度，能夠全面準確反映物體的運動性質，在科學上已經被廣泛應用。

第一次設定，資料一定要填準

手環內置的加速度傳感器和算法是極其微妙的東西。總體上來說，大家在拿到手環第一次設定時，一定要誠實準確填寫各項信息！包括性別，身高，體重，年齡，這些稍微不准都會直接影響到加速度傳感器的數據捕捉，進一步影響到算法運算，導致的結果則是計步不准、距離數據不對，消耗卡路里數值欠準度，從而得出不理想的數據，影響到個人運動數據。擺臂姿勢、步幅、身形、路面的平整度、上坡下坡都會影響到計步數值。

為什麼各家手環算出來的步數不一樣

然而有的人還是覺得手環測不準，手環在一定範圍內存在公差是正常現象，殊不知物理學上還有「測不準定律」，各家手環均使用加速度傳感器來作為計步的主要依據，但是由於採用的器件和算法水平不同，於是就產生了各款手環記錄步數不一致的狀況。

https://youtu.be/bTDsPBjGwoQ

［網誌轉述］何謂資源？

竹子日誌（竹子） — Sat, 24 Feb 2018 09:22:00 GMT

這個主題多半是推我個人網誌上的訊息，我會做一個轉貼。如果有什麼想法都歡迎交換和分享，希望我們思維一同融合與成長。

wearabledevicewilly874.com/bamboodiary/2018/02/08/財富法則/

常常有人問，怎麼賺錢？

我們每個人生來到現在累積了許多資源，

時間的資源

勞務的資源

貨幣的資源

資本的資源

健康的資源

技能的資源

性格的資源

人脈的資源

信用的資源

這些東西常常大家都搞不清楚，有些更不把它當作一種可貴的東西。

時間資源，它價值難以衡量，但是我們可以去量化它，去計量它。重新衡量現在每一個行為它背後的經濟價值，你會發現過去的一切變不值，自己不斷在浪費自己的時間。

勞務資源，自己付出的勞動力，過多的疲累導致就算下班後你也不再有力氣去付出，選擇休息，選擇什麼也不做，這個代價阻礙了你精進成長的空間。

資本資源，指的並不是錢，這指的是你的房子、車子、手機、衣服、電腦等等，這通通都是你的資源，把這些看似無價值的東西為資源，都可能為自己創造產值。

貨幣資源，指的就是握有的貨幣，這就是資本主義社會的一個牽動因素，如果不能握有這樣資源，那就成為社會的底層。

健康資源，這是最容易被濫用卻渾然不知，包含熬夜加班、高風險工作、高職業傷害工作等等損失，揮霍消費卻渾然不自覺。

技能資源，就是過去到現在種種學習到和培養到的能力，技巧、技術、專業等等通通都屬於能力資源，它擁有極高的價值，值得用許多代價資源來換取它。

性格資源，它是很好用卻容易被忽略的一個，包含著熱情、興趣、個性、反射等等，這些它時時刻刻影響著我們的行為模式，有效掌握掌控它能帶來的收益十分驚人。

人脈資源，這樣雖然被許多人拿來說，但是沒人能懂，並不是認識的人多人脈資源就多，人脈資源重質不重量。而人脈的質就攸關這人背後隱含的「資源」，越是資源豐富越是有價值，還有就是親近的關係，這更是稀有而不可任意消費的資源。

信用資源，產生這種資源是來自於人脈開始，然而人類首次量化這種資源是因賒帳這種交易方式產生，便誕生銀行這種金融產物。然而，這種資源的力道在現代可以是一個陌生人的基本量化數據。

如果把自己的一切資源都當一回事，那威力非常強大。我常常跟朋友說，天下不存在一種通用的「賺錢的方法」，因為每個人擁有的資源截然不同。真正賺到錢的人永遠是有效整合自己所有資源並有效開發有價值資源的人。所以去整合你的資源，去量化你的整合模式，如此你也看得到自己的財富。

財富是屬於掌握資源運用規則的人，那也許…創業對你來說很重要，但創業聽起來卻很難。

如果真的還是看不懂，沒關係，我其實很願意教導別人，我只害怕不願意改變的人，或是不接受打破常規知識的人

當你看透這個世界後，你不會覺得錢是一個大問題，但是你看任何事情的角度也許跟一般人真的不太相同……

［議題討論］如何建立個人品牌？

竹子日誌（竹子） — Fri, 23 Feb 2018 02:39:26 GMT

在現在的時代，個人品牌尤關重要。不管你是要找工作還是要創業，擁有個人品牌的時候，你的價值就會很不一樣。人家憑什麼找上你？重點是為了凸顯不同凡響的價值，競爭能力的差異性。那麼，如何去宣傳「自己」這個品牌呢？你又是怎麼做？

其實品牌常常都是一個人開始累積，慢慢去傳播名聲，建立影響力。那怎麼去推播自己的訊息呢？如果沒有訊息的傳遞是不會有人認識你的。

首先可以先釐清自己未來提供的服務或產品是實體的還是虛擬的，如果還不確定就先定義自己的「核心價值」。什麼是核心價值？就是你認為你本身可以帶給其他人的使命，或是自己的熱情與專業。

如果還是不知道那可能代表這一段距離你還很遠，你還可以認真思索一下。

有了核心價值後，就可以鎖定市場，你的市場族群屬於哪一類呢？依據你的目標決定方法。

如果你認為世界上有可以做全世界的產品服務市場，那你還說省省吧！那種東西是不存在的，只有瞄準目標才能精確命中。

有了核心價值和目標，你其實就可以著手開始進行個人的價值推廣。對！是「價值推廣」，不是推廣你的「產品服務」，是推廣你的價值。如果沒有價值，你是不會讓人感到興趣的。

再來是方法，方法很多。你可以靠實體平面，可以靠口耳相傳，可以靠網路媒體。什麼方法最好？沒有最好的，重點在你的市場的人會接觸哪一種傳播方式？那就是最好的。

［知識小補給］PDCA流程化

竹子日誌（竹子） — Wed, 21 Feb 2018 02:52:14 GMT

PDCA 這套法則沿用商場多年，但真正紮實跑完一輪的人有多少？這篇是關於流程化的知識小補給。

［議題討論］複業工作很折磨嗎？

竹子日誌（竹子） — Tue, 20 Feb 2018 22:13:29 GMT

在多元的環境下，你除了自己的本業之外，你還為自己準備什麼？第二份工作和第二份專長？但是下班後累到快要塌陷，竟然還要工作，這是何等疲憊！但是第二專長、第三專長是為了抵抗職場風險的一環，第二收入和第三收入也是抵抗就業風險的一環。但是⋯不要說第二，有的人真的連第一個都照顧不好。

關於這個問題大家有什麼看法呢？

群友的看法：連第一份都顧不好是現實

仁：第二第三專長是理想，第一都照顧不好是現實。除非工作特殊目前能準時下班還不用繼續管工作的畢竟少數，人通常下班、放假想的都是休息能否投入去做專長培養很難，連基本的閱讀很多人都做不到更何況專長培養？

榮：工作中也有機會學習到不同的第二專長，像我現在在空中美語當電銷業務，但工作中仍有機會接觸到英文。當然下班後加強自己的英文能力除了第一專長工作能用到之外，未來到其他行業當然也有機會用到。當然也有同事完全不把學英文當一回事，所以要看面對目前第一專長工作是什麼心態而決定吧！

如果只是賣8小時給公司，下班後額外學習當然會痛苦，但如果能工作融入生活，生活融入工作，就不太會有所謂收假症候群或BLUE MONDAY的狀況。

萱：通常受薪正職人員，待在公司時數約8~12小時，有時下班後還必須在家裡加班，或者照顧家庭等因素，能培養第二專長，並且能將第二專長轉為收入，確實不容易，

但其實最大根源，應該要問問自己到底想要甚麼?大部分的人也都覺得一份工作生活過得去，何苦為難自己?個人認為會思考第二專長或兼差，大概可以分成以下幾種情況：

目前可能生活(金錢)壓力大的人，學習第二專長機會比較高，這種人通常有充分且必要的理由去執行。
再者為正職中必須使用的技能，如語言、專業證照等，由於職場需要，自然學習有動力，也比較不容易半途而廢。
另外就是對某項領域有興趣的人，但是興趣有程度之分，這個”興趣”值不值得你在忙碌的正職工作下班後去執行? 會不會投入幾個月後就放棄?通常這種人頗多的，但走到最後的人，可能是少之又少。

如果不是第一種狀況的人，把第二專長培養當作一個抗風險或是賺錢為主要”目的”或”心態”的話，我認為是蠻容易失敗的，因為當正職工作一忙，就容易找到理由怠惰，因為一份工作就能養活自己不是?更何況這還是大部分收入來源，大家都想有錢，但仔細想想生活也還過得去，然後…然後就是今天很累，明天再開始，就會發現”明天”還真多。

我的看法：複業是熱情，不是多打一份工

竹：複業工作並不是要你去兼職很多份職業，而是要你用熱情去享受「複業」。很多東西都是非常有趣的，在熱情之中鑽研、努力、深挖，讓自己在某個領域成為佼佼者，你就會有超凡的價值。

但是如果自己完全沒有「被利用價值」，你唯一剩下的只有時間、勞力、少的可憐的錢。這些資源都是被用完就沒有的東西，你只是在消耗你僅有的珍貴資源，但卻不能將它化為最大產值。

如果你的「被利用價值」是知識、技術、供需關係，那這些是可以反覆被利用，消耗掉的勞務和時間也可以最大化提高產值。東西常常是稀缺的情況下，那麼市場爭奪上勢必會開始競爭，自然就不存在所謂的高價值。

單技能、單收入，本身就是一種風險

話說回複業，或許你可以有千百種理由說我沒辦法經營複業，也許是沒有時間、也許是公司規定、也許是沒有技能、也許是沒有特別興趣、也許是覺得沒必要⋯⋯⋯。但是不論你是否覺得要不要去經驗，只要你只有單技能單收入模式的狀態，那勢必要去經營，不然就是生存在某種程度的風險當中。人家說，雞蛋不要放在同一個籃子裡，但是你對於自己收入的態度是這樣嗎？也許只有自己清楚。或許你很想花時間經營，但就是有困難，其實不是你有困難，只是你不斷給自己藉口和有割捨不了的東西，也就是這樣。

［知識小補給］有哪些商業模式？

竹子日誌（竹子） — Sun, 18 Feb 2018 04:52:34 GMT

姑且排除行銷、營運、物流⋯⋯等等細部，大致把商業獲利模式簡單列出幾種。

40 種常見的獲利模式

1.撰寫文章彙整成一本書，然後自薦給出版商替你出版。

2.撰寫文章彙整成電子書，到電子書的網站拿來賣錢。

3.經營部落格，以內容引導流量後，讓部落格網站或Google 付給你廣告費。

4.經營部落格，以內容鎖定市場，讓其它廠商找你業配或做行銷聯盟。

5.包裝自己擅長的技術或知識，經過推廣收取會員，以直播、實體課程、線上影片等方式銷售出去。

6.運用網路爬蟲去爬特定產業資料，並經過篩選整理賣給廠商或大眾。

7.運用網路爬蟲去爬特定產業銷售資訊，並經過篩選整理後給大眾比價，導入銷售後收取抽成。

8.創建教學指南、懶人包、軟體的電子檔導入網站，運用導入流量收取點擊廣告。

9.創建導入實體工作室、企業、工廠等廠商的導入站，藉此收取抽成及廣告費。

10.運用網站、社群、廣告等，建立一個導入外包的機制，提供不同類型的技術或服務，藉此收取仲介費。

11.撰寫貼圖、手機App、線上App、電腦應用程式等拿去上架，藉此收取利潤。

12.購置自動機台，自動販賣機、自動洗衣機、遊戲機、加水站、夾娃娃機等，然後租一個小店面或小空地運作。

13.購置或置讓出一部分的房地產，經過整理後出租。

14.建立一個YouTube的頻道，收取Google 的廣告收入。

15.建立一套投資組合，操作金融衍生商品。

16.建立一個圖片、影片、文字的內容庫，收取會員或包裝成套件來銷售。

17.製作一個直接導入電子商務平台的網站，收取導入費用。

18.購置高昂的設備、器材、交通工具等拿來出租給廠商或需求者。

19.整合數位資訊後透過網站發布，由中間抽成以及收取廣告費。

20.出租一個「空間」，拿來租給人休息、過夜、辦活動、會議、倉儲等。

21.執行社交借貸，收取利息。（迷你銀行、當鋪、借貸公司等等都是）

22.開發一個實體的商品直接從店面、租售商、零售商、電子商務進行銷售。

23.直接從工廠、批發商、外國商城尋找低價商品，然後在電子商務平台銷售。

24.建構一個有效的獲利模式，開放給其他人加盟連鎖。（許多知名連鎖都是，像7-11、五十嵐⋯⋯之類的）

25.包裝自己擅長的技術或知識，直接在課程銷售平台出售課程。

26.參與投資實體企業，收取份股獲利。

27.設計一套紀念品Logo，有系統有套組去平台或自己的網站銷售。

28.建構一個自己的論壇，集中流量後進行業配和廣告。

29.運用網站、社群、廣告等，建立一個求職空間，提供不同類型的技術或服務的人才，藉此收取仲介費。

30.建立一個彙整課程的平台，銷售各種領域教授的課程，收取仲介費用。

31.利用各類型平台舉辦直播活動，收取贊助費和廣告費。

32.出售一個能獲利或有噱頭的點子，以此收取贊助費。

33.購置一個稀有的網域名稱，出租給別人。

34.找出資商負責器材、工具、保證金，連結其它有工作需求的臨時工及有能力的技術廠商，完成複雜度高的包案。

35.提供技術加工服務，把原成品加工成為另一個成品。（一般工廠或餐飲業都是）

36.協助其他人購置商品，於出貨商壓低成本，從中抽取利潤。（這就是團購）

37.取得代理權，運用社群、交友圈銷售產品。（其實保險、傳銷的銷售模式屬於這類）

38.取得代理權，建立分利制度，組建銷售團隊出售商品。（組織行銷都是這樣做）

39.直接從批發商進貨後再銷售。（這就是零售業）

40.設計藝術作品，登記著作權後拿去給出售商銷售。（像是音樂、畫藝、工藝⋯有點範疇）

這些模式共同要克服的事

看過也許有很多的疑問，但是很多商業模式都是從這些基本概念去衍生。包含市場大小、行銷策略、銷售方式、通路建構、組織管理都是每一個商業模式都要想辦法克服，最後獲得利潤。

［知識小補給］打造自己的品牌

竹子日誌（竹子） — Tue, 13 Feb 2018 23:04:22 GMT

你有屬於自己的產品嗎？你能夠去包裝你的「價值」嗎？客戶會找你消費絕對不單純是「產品」本身，優秀的產品確實客戶會自行上門，但是那是人家做出來的品牌。那你屬於自己的個人品牌是否去打造了嗎？

打造個人品牌的方式千百萬種，網路文章、書籍、課程⋯到處都有教，但是你應用了多少呢？今天我來告訴大家如何「從現在開始」打造自己的品牌！

［議題討論］沒有夢的世代

竹子日誌（竹子） — Tue, 13 Feb 2018 22:42:16 GMT

在現在，我們看到大環境的殘酷，極限的物價和極限的低薪，生活已經困苦。但是在這極限的社會，我們下一代的教育和訓練還是使用17世紀的教育思維，一個過時的教學。在教育部積極的「多元教育」等國際化的教改下，目的不就是想開發孩童對多元社會的銜接度？但是終將被家長和學校扭曲⋯⋯

還是在無盡的死讀書，升學升學不斷升學⋯⋯出了社會後你可以問問大家，再經過我實驗後，大約有70～90%不等的人約略是以下回答。

你現在讀的書（或工作）是你想做的嗎？

「不是欸」

「我其實不太清楚」

你未來有想做些什麼嗎？

「不知道欸」

「再研究看看」

「到時候再說啦～」

「隨便，過得去就行」

其實我們都可以發現，我們台灣社會其實缺乏了所謂的「生存動力」，對他們來說活著就只是為了活著而已⋯⋯甚至在忙弄茫然的學習下迷失在人生，他們連自己都不認識⋯⋯有的連培育個人興趣都沒有。

基本上你問現代人你們休息日做什麼？會有以下回答。

「不知道欸」

「睡覺吧」

「滑手機」

「打電腦」

不要說投資自己，連自己的「熱情」在哪裡都不知道，這⋯⋯怎麼辦呢？你可能發現了，每次問問題常常會得到的答案是「不知道」，通常不是明確的姓名、性別、工作、星座⋯⋯等等的問題就容易得到「不知道」這個答案。是現代人放棄思考了呢？還是已經不會思考了呢？我最近發現這樣的現象，年齡層從15到50都是如此⋯⋯

這次議題我不會追加論述，給大家思考，如果有迴響我會再追加。

［議題討論］國外的IT素質培養

竹子日誌（竹子） — Tue, 13 Feb 2018 22:33:03 GMT

在一些先進國家，有一些人從小就開始做程式語言的編寫訓練，但是我們似乎把這門技術當作是很高級的技術⋯⋯

事實不是如此，只要你會認「A~Z」，那麼就能夠開始進行演算法的思維練習。神童之所以為神童是他們的天才受到重視而且被開發，在台灣制式不革新的教育訓練只會埋沒更多的人才⋯⋯

24小時後我會提出我的看法和實際的方向！

www.setn.com/m/news.aspx?newsid=277067

群友的看法：舊思維等於安全牌

仁：社會意識仍未改變，父母仍是希望小孩升學再升學來”找”好工作，但奇怪的是父母都知道工作不好找、待遇差卻不改思維。

歸咎原因是因為舊思維等於安全牌，「至少」還找得到工作是主旋律，在此影響下，小孩被壓到大學才能在較自由氛圍下覺醒，甚至根本無法覺醒找到自己的興趣轉變成工作。

這篇其實主要在於「開明父母」會引導並教小孩循序的學習，不然通常小孩表達興趣就算有些父母察覺到也不會放心上，放心上也不會教。

畢竟..以後你有興趣再學

現在你先把學校書唸好

洧琳：我的見解是教育分為三類：學校教育、家庭教育、自身教育

1.各國對於教育體制的基礎與培訓是不一樣的，全球教育體制最完善的國家『芬蘭』，對於孩子的啟蒙教育是開放的，相對於台灣是模仿美國的教育體制，當然模仿的四不相，對於孩子的『未來』是渺茫的

2.家庭教育需要搭配學校教育一同實施，台灣傳統家庭對於孩子想要學習的機會會給予意見，反而不會讓孩子『思考』與『判斷』，只會讀書上好大學可以找到好工作的觀念，孩子自然不懂的爭取

3.孩子18歲是成人且獨立的分割點，這個階段的孩子有獨立思想，針對他想要的，他會去打工賺錢學習，但父母過度的保護與充滿物質的追求，學習能力端看個人想要追求什麼生活與未來

我的看法：程式考的不是英文數學，是演算法

竹：在我近期學程式語言過程中我了解，程式語言考驗的並不是英文、不是數學、更沒有什麼要建構在物理化學的知識，而是一個全新的東西，它叫「演算法」。那是一種邏輯概念，雖然讀英文和數學確實對學習程式語言有加分，但是它核心的需求只是一個「邏輯」。

其實國外有很多資源可以教育孩子學習邏輯演算，其實也有翻譯資源，但是台灣很不盛行。所以台灣的學習資源非常匱乏，人才缺口也十分大，企業想僱人也僱不著。因為實際的從業人口遠遠不足，人才外流和轉出行業還是頻頻發生，真是一個殘酷的社會現象。

大家一窩蜂搶公務人員，誰來培養人才？

台灣落後於現今國際社會的教育是事實，人才培育並沒有發揮價值，大家一窩蜂搶「公務人員」，連垃圾車、清道工這樣的工作只要是政府的仍然大家搶破頭。為什麼？就因為是公務人員，有國家福利和權益的保障，不然真的有人興趣在這樣的工作？我想大家內心有數。但是普考、高考等都是靠專業本職能力？去準備過的我相信會更清楚。那麼，誰去培養社會真正的人才？

其實政府知道趨勢，也大力推動工程師的訓練，然而事情並沒有那麼簡單。許多職訓、第二就職培訓、產訓等，仍然不斷在開發人才，有成功培育的，卻也有失敗的⋯⋯

職訓開了那麼多，為什麼還是失敗？

為什麼失敗呢？

任何技能都有學習瓶頸，但是台灣人習慣師傅手把手教導，認為只要在付出學習後就應該馬上有成果。這時你可以想想，自己目前的主力技能是別人教的呢？還是自己看書研擬鑽研出來的呢？這個其實就是「學習」這樣技能。

不斷嘗試學習新東西，磨練「學習」的能力。學錯學了用不到又如何？只有不斷突破的過程中才有飛躍的成長，一個技能你哪天用到你自己都會驚訝！

［議題討論］商業模式

竹子日誌（竹子） — Sun, 11 Feb 2018 00:46:45 GMT

任何企業能夠規模化、商業化、系統化，這個方式就是商業模式。規劃出一個新的商業模式並不簡單，從模仿、組合、創新，慢慢去雛形。你們認為商業模式可以用哪些方法呈現呢？

大部分人對「商業模式」這個詞彙感到模糊，有人知道到底什麼是商業模式嗎？

老樣子～24小時後我會提出我的觀點。

商業模式到底是什麼意思呢？

傳統的三種：生產、加工、批發零售

這大概是對於創業陌生的人不能理解的，首先來依序解說「商業模式」。

生產零售

最基本的一種就是出售你的商品，比方說農夫賣出自己種的蔬菜水果，自己完成生產製造，然後拿去賣給批發商或消費者。

加工零售

把原物料經過加工後變成不同的商品，再轉售給批發商或消費者。比方說工廠製造的加工食品或是廚師進行料理的烹調都是。

批發零售

找到產品的來源，批量採購後再轉售給客戶端，過程做運輸、行銷、通路等服務。像是便利商店集中大量的商品進行販售。業務員販售公司的服務或產品也是。

後來衍生的兩種：共享經濟與資源轉售

以上是傳統商業模式，再來說後來衍生的。

共享經濟

把自己的閒置資源、資產拿出來租借或運用，屆而產生租借收益。比方說漫畫書店、租車行等等，連房地產租售也是這種。

資源轉售

這是一個「羊毛出在狗身上，豬買單的概念」，透過收取大眾的資料數據、注意力、人潮流量等等，由其它商人來支付這筆費用。比方說廣告公司、人力銀行、房屋仲介公司、百貨公司等等都有用到這些隱含的概念，這是一種比較高端的銷售，也比較能確定資金的穩定性。

為什麼後兩種最難，也最好？

上述五種模式就足以延伸組合變成千百種商場的商業模式，但是仍然是最後兩種最重要但最難以掌握。許多人常常想設計出最後兩種商業模式卻慢慢變成前三種模式，主要是模式設計出了問題。然而為什麼最後兩者產生的模式最好？因為它會帶來「被動收入」。但常常大家卻經營到變成在「買賣」，而非創造收入系統，這也是被誤會的。

能夠產生被動收入的商業模式目前我所知道的大概接近一百種，透過自建的通路及系統出售商品、服務、資源等等。但是通常有其條件、代價、技術。相信，天下沒有白吃的午餐，這點認同吧？

接下來我會舉例出幾種身邊常見的現代商業模式，仰賴不同的通路管道和資源去建構。許多商業模式的發現是靠累積、觀察的，細微去體察每個消費背後的模式都可以發現端疑，這都是要仰賴不斷的思考。

［知識小補給］工業化的演進

竹子日誌（竹子） — Fri, 09 Feb 2018 02:14:30 GMT

現在我們常常聽到所謂工業4.0，那工業4.0是什麼呢？竹子來稍微敘述一下工業的演進吧～

工業 1.0：蒸汽機與工廠機械化

自蘇格蘭的詹姆斯·瓦特改良了蒸汽機後，開啟了工業革命。人類首次開始以蒸汽或者水力作為驅動機械的動力，實現工廠機械化，用機器代替生產所需的龐大人力、畜力，以大規模的工廠生產取代個體手工生產。這個年代大約是1760到1830年間，社會經濟從手工業、農業為主的產業體發展成為以工業機械製造的方式帶動經濟快速發展的新模式，這就是工業1.0時代。

蒸汽機就是利用「水」在加熱沸點後，水在物理上轉化為氣體時，空間的需求增加，在有限空間內壓力大幅上升，利用這個高壓突破的衝擊力產生一個力道，而這個力道拿來帶動機械的運轉。在能量取用的過程水的溫度降低，這些水蒸氣凝結成水，再把這些水回收回去重新加熱，這個循環現象我們稱之「汽水循環」。我們生活中的鍋爐、核能其實都是運用這套系統在運作。

工業 2.0：電力與大量生產

使用蒸汽和水力的機器已無法滿足人類社會高速發展的需求，分別是艾蒂安·勒努瓦發明了第一台實用內燃發動機，西門子公司發明了第一台實用發電機。並且電器被廣泛使用，進入了由繼電器、電氣自動化控制機械設備生產的年代，機器生產分為零組件加工與產品裝配相互結合的生產方式，使產品得以大量生產。這段日子約是1870到1920年間，無論是電力交通工具還是通訊產業技術也有長足進步，這就是工業2.0的時代。

說到電的技術，其發現演進一直到應用歷經很漫長的時間，一直到磁生電方法被發現後，就開發出發電機，直到被應用在工業上。真的要把「電」這個現象說到清楚就是一個很複雜的問題，它的觀念和概論建構需要很長的敘述，這邊就不多說了。

待續⋯⋯

工業 3.0：電腦、網路與自動化

1940年代，從第一代真空管電腦發明，逐漸從真空管計算機變成電晶體電子電路，最後由羅伯特·諾依斯引領一群工程師發明積體電路。電腦取代複雜而笨重的電力系統，工業模式開始走向自動化。隨電腦之後就是網路，李歐納·克蘭洛克發明了電腦與電腦連結的方法，資訊得以快速連結全球各地，各種精密機器的發明，大幅提升工業生產的效率與品質。而電子計算機的自動化逐步代替人們體力及腦力的勞動，原子能、太空技術、個人電腦、人工材料、分子生物學、遺傳工程等科技都在這個階段飛速發展，這就是工業3.0的時代。

從電被發明後，一直到延伸出計算機科學，其實電腦只是單純把兩個高低不同的電壓訊號辨別為「0」和「1」，透過二進制演算達到各種複雜的指令。

工業 4.0：虛實整合與智慧工廠

德國於2013年正式於漢諾威工業博覽會中提出「工業4.0」的概念。核心概念是利用互聯網虛實整合系統，將製造業、零售業、金融業進行整合，讓產業供應鏈互聯網化。特別是大數據構成新一代智能工廠的重要動力，由智慧設備進行分析、決策、調整控制來生產客製化產品，實現生產智慧化、設備智慧化、能源管理智慧化、供應鏈管理智慧化的目標。在工業4.0年代的現今，互聯網以迅猛的速度改寫產業結構和模式，生產不再是為了效率，而是要更加綠能化、人性化、客製化。

工業 4.0 的核心其實是人工智慧

其實工業4.0最重要的一個概念是「人工智慧」，它具有高學習力、高效率、低失誤率等等優點，是不容小看的。他能夠取代昂貴的人力成本，並且取代相當多重複性、複雜度不高的工作，高難度的分析演算工作也可以處理得很好，所以未來最大的產能就是「數據」。在「大數據」的趨勢下，數據量只要夠大、夠精準，那就會產生非常高的價值。

在這樣的世代你選擇怎麼前進呢？

［主辦活動］竹子分享會 EP02：網路行銷概論

竹子日誌（竹子） — Mon, 05 Feb 2018 21:20:22 GMT

竹子分享會:網路行銷概論EP02

✨因應有飯友要求追加開

⚡️本次是同主題追加場次

如果參加過想偷挖飯主更多的人⋯⋯

🎉歡迎再次參加🎉

🤔你有自己的產品想要行銷嗎？

🤩還是你就是要行銷自己呢？

🤑還是你是新手想入門這片版圖？

網路行銷新手最大的問題就是不清楚怎麼做⋯

其實行銷的心法都差不多～

但是卻會因為一些細節而有很大的差別！

那麼如何避過行銷上的誤區？

我會淺談何謂行銷、網路行銷

並且簡單介紹目前的主流行銷策略

👉架設網站

👉SEO優化

👉社群行銷

👉廣告投放

👉O2O整合

內容主要針對：

✅資本不足的新創團隊

✅剛開始做個人品牌的人

✅想賣個人產品或服務賺外快的人

✅想交流不同行銷領域的人

如果時間充裕我另外幫大家做個入門

💫順便健檢你適合用什麼方式開始

💥讓你跳過重重新手障壁！

注意事項：

⭐️本次活動優先讓上次沒參加到的人參加

⭐️飯主無意銷售任何產品，純分享

⭐️報名者切勿無故未到，否則一定給黑評價

⭐️切勿局中騷擾、推銷等不當行為

⭐️有要帶朋友請提前私密飯主安排

⭐️報名時可以說自己想行銷什麼東西

本次活動依據人數、天候因素可能異動

歡迎更厲害的專業人士也來分享～～

這是「分享會」，不是「演講」。

🔥人數達到會馬上審核並開啟滿團🔥

時間：7/29，14:00

地點：

歐客佬咖啡農場信義店

106台北市大安區信義路三段109-1號

好禮加贈

1.訓練行銷能力的方法

2.架站入門

3.網絡銷售漏斗

4.集客式行銷

5.長尾效應

6.解決的痛點

7.行銷5A

8.競爭對手

9.國外怎麼做？客戶在哪裡？

10.key man是誰？

11.有需要網絡行銷嗎？

12.大公司的行銷怎麼回事？疲勞轟炸。

13.廣告的5秒鐘效應。

14.B2C和B2B

15.邊際效應

16.廣告類型

行銷、銷售、產品、商業模式

［主辦活動］文字重生計畫

竹子日誌（竹子） — Mon, 05 Feb 2018 21:03:47 GMT

這個計畫參照了前陣子在YouTube 舉辦並火紅的「文字重生計畫」，希望可以促進一點活動氣氛。

內容是，參加者寄一本自己已經沒在看但是認為是非常棒的書，然後我會把所有的書隨機再抽給其它參加者，促進我們的讀書風氣！

書的厚度、價格、年代不限。我會經過篩選，瑞托是很空洞的書我可能會退回，因為不希望是保持隨便的心態參加。盡量避免是小說、百科全書、條列式工具書（比如字典）的書，除非格外有意義你力推的類型。

如果參加人數滿5人我就會舉辦，請有興趣的私訊我，我也會另行公布。

心情旅誌

竹子日誌（竹子） — Mon, 05 Feb 2018 20:31:30 GMT

很多人問我

工作已經夠忙了

為什麼不好好放鬆自己？

放假跑去取什麼材

PO個美食文如此大費週章

甚至想些別人無法理解的事

這事或許看起來天花亂墜

但這是我的夢想

問題又來了

又很多人問我我到底想幹嘛

我總是沒辦法給人滿意的答案

我思考了很久

真的不太想讓人知道太多

因為多的是打擊自己的閒言閒語

那我還是精確說明一下我的計劃

如果你認同給我加油打氣

不認同那你就默默就好了

計劃分成遠、中、近三段

首先說明計劃

凡計劃要分出遠、中、近三個階段

所要做的事也是完全不同

遠程：用創業達成自我實現

從遠程開始

其實就用簡潔的語句形容就是

“夢想”的實踐

太抽象嗎？

那用大家馬上能懂的實際作為敘述

就是“我想要創業來達成自我實現”

同時解決“經濟壓力的阻礙”

很令人瞧不起的理由嗎？

抱歉……讓你們失望

對我來說非常重要

中程：先把能力和人脈養起來

再來是中程計劃

在這份令我極不滿意的工作結束前

我勢必要先培養好自己的能力

人脈建立

行銷能力

公眾演說

金融概念

營運手法

當然我本家技術也不能荒廢

因為那是我萬一中的B計劃

凡事總是要有退路

然而實戰經驗一定要有

我會一最精簡的成本下去建立

並非要有一大筆資本

所以建起基本的系統結構

我會用盡手段營運它

實務工作也盡量以業務類為主

如果有現況困難再吃工科老飯

另起爐灶東山再起

近程：先從部落格開始

最後是近程計劃

也就是現在要做什麼

先從部落格形式來“創業”

衝奇摩搜便利的讚

積極洽談擴大社團人數

為什麼是幾乎是美食呢？

因為一頓飯局攸關生意成敗

好的談話佐美食不是畫龍點睛嗎？

那我便要有一個適合相約的寶地

所以個人美食圖鑑不就很重要了？

再來可以藉由社團和搜便利的主題

進而增加陌開的主題性

目的還是人脈培養

同時增加人際互動及交涉力

保險業務員討厭嗎？

直銷員討厭嗎？

問卷調查討厭嗎？

房仲業者討厭嗎？

其實這些人都是人脈的寶庫

剩下就是彌補自己的不足

剩下就是多花時間彌補不足

多看看書擴充知識

多看商雜和立志書籍提振積極心態

多出去走走看看並體驗未知領域

少玩點電腦及手機遊戲

少跟每天只知道揮霍玩樂的人相處

少挑戰自己的人性脆弱面

我深知自己的缺點及缺口

我也想努力克服

為了達到目的

我一次又一次改變

有挫折

有損失

但我多次去修正方法

我要活出自己

創造屬於自己的成功

要加入我的行列我歡迎

支持我的人我感謝你們

今日言止

日後詳述

淺談創業

竹子日誌（竹子） — Mon, 05 Feb 2018 20:29:39 GMT

創業的定義是什麼？

因人而異

對我來說就是“創造事業”

但是許多人對於此有諸多誤解

事業是不一定有金錢上的盈虧

但是經商做生意是有的

經商是泛指所有買賣的行為

但事業可以是一個無利益的存在體

一個俱形象或是系統性的結構

可以去操作或是各自發展

然而大多人會想把它跟“賺錢”混淆

但那是截然不同的

再來是創業的行為順序

傳統的創業：

資金=>商品=>團隊=>行銷=>收益

但是我並非這麼想

不是本末倒置

而是這種方式很有很高的風險

功虧一潰的機率太高

所以我的方式：

行銷=>團隊=>商品=>收益=>資金

為什麼可以用完全不同的方式？

我就要先解釋傳統方式是怎麼運作

然後逐步區別出我的方式

首先籌備一筆資金

可能是存的也可能是借的

並買進商品後運作團隊販售

以取得資本利得

但是背後承擔的風險極大

萬一商品並不符合市場需求

亦或是無競爭力

最後該事業體將面臨時間的挑戰

然後被環境淘汰

所以說要跳脫舊有思維

先將個人的品牌形象行銷出去

並過程建立人脈建構團隊

成形後規劃出運作系統

擇出有效益的商品後找出通路

通路構築完成也代表商品的售出

現金流自然達到穩定

資金便會逐漸累積

事業體的形態

有自己建立店面經營

亦或是一個辦公室運作

也可以是一個部落格做資訊交換

甚至是一種買賣的手段

但是最終要建立完整的現金流

那勢必要進入管理階層

不是單靠勞力付出維持

也許初期要自己操作

但是一定要訂出一套標準流程

改良後並複製

系統能夠高度自行運作

便可以為自己創造更多的時間

人究竟為了什麼？

金錢嗎？

時間嗎？

正解是獲得想追求的東西

有足夠的時間和金錢滿足需求

建立認同以及尊重

與自我的實現

這不就是人生？

淺談健康

竹子日誌（竹子） — Mon, 05 Feb 2018 20:26:51 GMT

談這個我就不是專業的，真的有點關公面前耍大刀，不過還是要推廣一下好觀念。

我很喜歡問人這個問題

因為得到的答案都不是我想的

但是大家回答的同時也幾乎沒思考⋯⋯

“平常看醫生吃的感冒藥的功能是什麼？”

大部分人會毫不遲疑回答

“治感冒的”

但據我所知並不其然

一般生病分為“細菌感染”和“病毒感染”

細菌感染通常使用黴素治療

俗稱“抗生素”

這是十分有效的

然而普遍感冒是病毒感染

以及各種器官疑難雜症

包含了癌症在內

本身可說是毫無特效藥

只能仰賴抗體的攻擊而消滅

那我們吃藥是為了什麼？

答案是“抑制症狀”

首先我們要知道免疫力的保持需要什麼

其實大家都知道答案

“正常生活作息”、“適當的運動”、“均衡的飲食”

但生病又是發燒、全身無力、食慾不振等等

都會影響我們的生活每一個行動

也是在傷害我們的免疫系統

所以要抑制症狀來達到“正常生活”

然而台灣人普遍醫療知識水平不足

強大的全民健保造成醫療資源濫用

藥變成補品在吃

這是非常傷害“腎”的行為

那不吃藥病怎麼好？

讓我來告訴大家！！！

要你每天睡足8小時，並早睡早起

你一定會告訴我“做不到”

因為普遍都市人沒那麼閒

那麼第二招！

政府推廣的“333”

每週3次，每次30分，心跳每分要達130次

你可能猶豫一下還是告訴我“做不到”

沒關係～還有第三招！

飲食均衡～

保持五穀類、蛋豆魚肉類、水果類、蔬菜類

四種食物以1：1：2：3的黃金比例攝取

每份約一顆自己的拳頭

用吃的容易點了吧？

蛤？！“有點困難”？很難服侍誒……

我知道大家蔬果類普遍都攝取不足

所以大家不但疾病纏身也肥胖纏身

其實聰明的人就發現了

關鍵在“營養攝取不足”

這就是為什麼外國保健食品產業那麼競爭了

因為看醫生吃藥都是天文數字

預防勝於治療

所以生病與其只吃感冒藥再多補充點營養吧！

有想愛護自己身體了嗎？

為了工作犧牲掉“睡眠”和“運動”真的不划算

還有飲食均衡也很重要

別賺了錢卻賠了身體啊……

你賣了什麼？

竹子日誌（竹子） — Mon, 05 Feb 2018 20:23:45 GMT

為什麼我們總是如此而已

想要與身旁的人拉出差別

究竟要會些什麼東西呢？

為什麼我只有如此？

因為啊………我們不懂真實的世界

學識是一種結果

健康是一種結果

能力是一種結果

財富是一種結果

生活是一種結果

我們周遭一切都是一種結果

由過去與身邊的人造成的結果

不要再怨天尤人

銷售概論

銷售分為三個層級

商品>價值>信任

首先是商品

如果只是因為商品本身吸引人

那你也不過是個最差勁的推銷員

人見人厭

不會有人平白無故去向你購買

你的市場是最狹隘的

所以如果可以

不要賣“商品”

接著是賣價值

你掌握了消費者的需求

你充分發揮產品的價值

讓消費者體認到產品是我需要的

你是在做一件善事

幫助人解決他的問題

提升他的生活品質與生存價值

最後是賣信任

不管如何

信任的朋友做生意

朋友間義氣相挺或捧場

這是現代人常有的狀況

而且由可信的人為自己來服務

讓人開心放心又安心

不用怕被耍被黑被騙錢

無論一個推銷員再怎麼努力說服

也贏不過朋友的一句話

淺談業務員

竹子日誌（竹子） — Mon, 05 Feb 2018 20:22:59 GMT

最近和朋友在聊“推銷員”

普遍大家對業務員的觀感都不好

那是些不懂業務的人所造成

給民眾不好的印象

其實這是個非常令人欽佩的職業

業務員

對我來說

這是個了不起的職業

他們必須要面對龐大的挫折

而且要跨出原來的舒適圈

你會主動去加深不熟朋友間的關係嗎？

你會主動去認識陌生人嗎？

你可以挺著胸膛向朋友介紹自己的商品嗎？

你可以用積極正面和堅持的心態工作嗎？

你可懂惜字千金和一寸光陰一寸金的道理嗎？

你可以用空杯之心學習每一件事嗎？

這些都是業務員的課題

一等一的業務員

不是在”推銷產品”

而是在“結交朋友”

你可知全世界的大企業家都當過業務？

因為它俱備所有當老闆前要學習的技能

學校是不會教你這些

所以我真的極力推薦去當個幾年業務

人生觀會有不一樣的成長！！！

可以被複製的成功是假的

竹子日誌（竹子） — Mon, 05 Feb 2018 19:23:51 GMT

相信許多看到這段話的人一定有滿滿的話想說，不管是否定也好，認同也好。

倖存者偏差：那些沒被寫出來的失敗者

以下舉幾個網路上的例子：

「賈伯斯勇於挑戰體制而成功了，所以大家應該都去嘗試挑戰體制。」

上述例子中卻沒有提到一樣是挑戰體制卻失敗的人，僅僅只是以一名成功者說明，卻沒說明失敗者的下場。

「每個成功者都很努力，所以只要努力就能成功。」

此例卻無提出努力卻失敗的人，直接無視了失敗者。

經商致富的成功者出書介紹自己的成功辦法。

與該書作者做了相同事情的其他人，未獲成功，但失敗者是無法出書的，所以我們會誤以為該書介紹的辦法就是成功的途徑。

某電台記者在高鐵上採訪乘客是否買到車票。

因為買不到車票的人根本上不了車。

把運氣的成分降低，先掌握規則

找出自己的路，勝過盲從別人的成功法則

貪快沒生意

竹子日誌（竹子） — Mon, 05 Feb 2018 18:38:16 GMT

有許多草創時期的創業者，他們總相信有快速的方法能幫助他們解決問題，特別認為我只要下廣告就會有生意，我只要花錢就會看到效果這種瘋狂的思維。

客戶是培養出來的，從第一個、第二個、第三個到第十第一百，這些都是價值提供過程中誕生的，沒有人會平白無故買你的單。唯獨有漸漸提供出價值和信任才能夠被客戶接受，直到買單。有句話，做一次的交易叫買賣，有商業模式反覆的交易叫生意。

每個人在創業的初期最頭痛的是「我該去哪裡找到客戶？」，因為任何的問題常是有收入都好解決，但是收入增加並不是這麼簡單的事。一昧追求要更多更多的交易和收入，等著的是一頭空，因為你還是只會卡在那個階段。在資訊爆炸的時代，每個人不愁資訊，一天到晚都有無數吸引你注意力的事物，怎麼去爭奪更多消費者的眼球？這才是重點。

所以不要貪快，紮實培養好自己的每一個客戶，哪怕一個還是兩個，當你整個商業模式被你架構出來後，收入便是手到擒來。

竹子的人生日誌2

竹子日誌（竹子） — Sun, 04 Feb 2018 18:46:13 GMT

進入軍校的生活，其實非常有趣，也非常辛苦，過著超乎正常大學生想像的生活。

在軍校，學長學弟制非常嚴重，學長叫你趴下就得趴下，學長沒叫你動你連抓癢都不行，這就是軍校的養成教育。每天早上折豆腐干，有限的吃飯時間和休息時間，覺不能睡飽，洗澡也匆匆忙忙，可以說是一個非常忙碌充實的生活。但那就是一個習慣養成的生活環境，一個高壓逼出你潛力忍耐力的環境。

我其實還蠻慶幸的，當時我算是一個天兵，傻裏傻氣。不懂看學長和同袍的臉色，事情老做得不好又搞砸，可以說非常欠揍的天兵。因夠天，我遭受非常多的「整理」，也練就那高抗壓的忍耐力，我的紀律力也非常強，一切仰賴當時的折磨而磨練出來的。

當時並不是優秀的人，是躲在團體中的人，沒能夠被學長列選為幹部，相對在態度和能力上頗為不足，不過這些東西是沒人教導的。這個時候的我多麼不起眼，多麼沒用，未來看起來一點光澤也沒有，相信也不會有任何人會認同。其實如果當初我選擇唸普通大學，或許人生真的會被我頹廢下去，幸好我選擇了這條道路，並且堅持下去。

［好書推薦］斜槓青年

竹子日誌（竹子） — Sun, 04 Feb 2018 17:49:39 GMT

這個單元每次出現我都會推薦一本好書，或是我看完一本書做簡短書評，鼓勵大家看書，並且讓愛看書的人有新的書單。

本次推薦：斜槓青年

這本書我必推！在我退伍後這本書對我的影響非常大，但是非常適合推薦給剛出社會找不到方向的年輕人，以及出社會後迷惘的人們。

在紐約，人們不會安於一份工作，常常身兼多種職務，所以在職稱後面還會加上「/」來代表第二種身分，稱之SLASH。但身兼多職並非要你下班後還要多兼幾份打工，那樣只會累死你。SLASH的含義是擁有多重收入的意思是透過技能的廣度，在各種本職技能相關的技能延伸發展，新技能能夠為你帶來更多或不同形式的收入，讓自己的收入結構更有保障。

作者詳述細節和舉例，還有自身發生的各種例子，讓你有了全新的方向。

同時，她點出了一些誤區，還有現實生活中的許多謬誤，希望不要有人陷入其中。思想上她的想法很可能跟大家原本所認知的東西有許多衝突，不一定全部的想法都一定是對的，也不一定全部的想法你都能接受，但是你務必要好好去讓自己的大腦思考。

我稍微提出幾個作者獨特思維的部分：

1.作者否定「全面發展是平庸」這個思維，他認為葛拉維爾的「一萬小時定律」是有問題的詮釋。

2.效率已經是過時產物，未來必走向去中心化、扁平化的方向前進。

不要被堅持綁架，選擇「不堅持」不斷去嘗試錯誤才是合理的。

3.利他主義才是利己，美德只是文化的虛構產物，利己才是真正推動社會的推手。

4.成功學是殘害社會的產物。

讀過的人可以一起好好交流，還沒讀的人務必去看看。如果有什麼好書要推薦，還是希望我能消化後推薦給大家，歡迎告訴我喔！

［知識小補給」冷氣保養

竹子日誌（竹子） — Sun, 04 Feb 2018 17:48:18 GMT

冷氣跟你家的房子和愛車一樣都是要保養的，希望它耐操有持久就必須定期檢查定期保養。如果把它當作操人就放任給它風吹雨淋日曬，你將會看到機體一片慘況。陳年污垢、蝕銹泥塵，這真的非常慘烈。不但越吹越耗電，也越吹越溫暖。如果真的有一點點狀況找專業技師來維修，恐怕只會告訴你：「你這台冷氣沒有維修價值了，換一台新的比較快。」

1.省電：內外機都有散熱鰭片，原本調吹27度就會冷，結果散熱鰭片太髒散熱不良，要調吹23度才會感覺涼。冥冥之中冷氣裡面的灰塵為你額外支出了不少多費用給台電，這種損失是沒辦法計量的。

2.空氣品質：除了平常冷氣濾網，內部還有很多構造是自己沒辦法去清潔的。這樣可以提高冷氣吹出的品質，特別是家裡有老人、小孩、過敏體質的人等等，提高冷氣過濾品質有效減少屋內的塵蟎循環。

3.冷氣的壽命拉長：一台沒保養過和一台兩三年保養一次的冷氣壽命一定不同，但是有在定期保養的冷氣壽命絕對會比那些沒保養過的壽命更長些。包含環境、使用頻率、裝機處理、機體品質等等跟壽命都有關係，但是有保養就一定能延長使用壽命。花少少的錢保養幾次延長壽命也比常換新的好，現在新冷氣都貴的要死，好一點的機子都要半個月的薪水以上！

4.提升穩定性：如果能兩三年做一次保養不但大幅減少要換機的可能性，定期檢查冷氣的機體狀況，也減少冷氣的故障率，也不用擔心冷氣動不動跟你鬧脾氣了呢！

［議題討論］虛擬貨幣（加密貨幣）

竹子日誌（竹子） — Sat, 03 Feb 2018 09:01:25 GMT

最近火熱熱的虛擬貨幣大家了解多少呢？因為虛擬貨幣帶動多少經濟的影響和新興經濟體的誕生？從最基本的區塊鏈到挖礦等等，雖然可能你們並沒有直接的感興趣，但是可以好好了解看看，或許連動的產業就跟你有關。

以下準備了懶人包，讓大家初步了解什麼是虛擬貨幣（加密貨幣），區塊鏈是什麼。

https://m.cnyes.com/news/id/3955051

https://youtu.be/KYnM\_dNo81Q

我先提出這個議題，有想法的可以先提出來，一樣24小時後我會提出我這邊的想法和論述。

虛擬貨幣會是未來的趨勢

虛擬貨幣應該是一個未來的趨勢，會有越來越多去中心化的虛擬貨幣誕生，除了區塊鏈外，也會慢慢有更多形式的虛擬貨幣誕生。但區塊鏈之所以為人們道之，就是因為他的流通貨幣數量是有限的，加上去中心化的特質，使其更加穩定。

看漲還是看跌？風險藏在資訊結構裡

未來看漲看跌？在短期來說幾個比較大的虛擬貨幣還是會漲，挖礦的方式也是一種收入模式，也比較像是投資。但它背後蘊含高度的風險，當資訊解構不穩定，還是發生資料災害，那貨幣價值會瞬間被解構，立即失去穩定性，此時的崩盤像通貨緊縮般一文不值。

為什麼是通貨緊縮，不是通貨膨脹？

聰明的人可能發現到，為什麼是「通貨緊縮」而不是「通貨膨漲」？這個時候就考驗你對這兩個詞的見解度，還有對虛擬貨幣的認知。首先我們必須認清虛擬貨幣不是「貨幣」，它嚴格來說算一種「貨物」。它的價值取決於市場的需求，所以不能單單靠「面額」去輕易定奪價值，更沒有人會去控制它價值的穩定性，說漲就漲說跌就跌，跟股票一樣刺激。

真正有趣的是挖礦潮帶動的產業

但挖礦潮這個現象讓我感到十分有趣。這個挖礦潮可以說帶動了電腦生產線的蓬勃發展，大量的人為了挖礦組裝高階電腦，從零售商、電子零件製造、半導體製造、礦物採集等等上下游廠商一線影響。電子股長紅走勢一段時間，相關產品整個凍跌，甚至還有漲價趨勢。這個現象說明了什麼？也就是市場供需平衡，實實在在衝擊市場，某個層面急需被滿足，這就是商機。

別人做發財夢的時候，你想到聯動產業了嗎

那為什麼我沒有感覺？我去挖礦好了？我來賣電腦和電子零件好了？我來投資電子股好了？

當你這麼思考的同時你已經錯失市場，我想表達的是產業帶動。無時無刻都有新的趨勢和產業的帶動，當別人靠表層的趨勢在做發財夢時，你是否先想到聯動產業哪裡被需要？這才是莫大的商機！

［議題討論］資源概論

竹子日誌（竹子） — Thu, 01 Feb 2018 20:38:18 GMT

這是我的核心價值，可能很多人還沒有看過，可以到我的網站上面大致上翻閱。雖然都是過去的文字累積出來的，但是我認為都頗為重要。

常常有人問，怎麼賺錢？

我們手上其實有八種資源

我們每個人生來到現在累積了許多資源，時間的資源、勞務的資源、財產的資源、資本的資源、健康的資源、能力的資源、性格的資源、人脈的資源。這些東西常常大家都搞不清楚，有些更不把它當作一種可貴的東西。

時間資源無價，但是我們可以去量化它，去計量它。重新衡量現在每一個行為它背後的經濟價值，你會發現過去的一切變不值，自己不斷在浪費自己的時間。

勞務資源，自己付出的勞動力，過多的疲累導致就算下班後你也不再有力氣去付出，選擇休息，選擇什麼也不做，這個代價阻礙了你精進成長的空間。

財產資源指的並不是錢，這只的是你的房子、車子、手機、衣服、電腦等等，這通通都是你的資源，把這些看似無價值的東西為資源，都可能為自己創造產值。

資本資源指的就是握有的貨幣，這就是資本主義社會的一個牽動因素，如果不能握有這樣資源，那就成為社會的底層。

健康資源，這是最容易被濫用卻渾然不知，包含熬夜加班、高風險工作、高職業傷害工作等等損失，揮霍消費卻渾然不自覺。

能力資源就是過去到現在種種學習到和培養到的能力，技巧、技術、專業等等通通都屬於能力資源，它擁有極高的價值，值得用許多代價資源來換取它。

沒有通用的賺錢方法，只有整合自己的資源

大家若是有一套自己的邏輯思考或人生法則願意與大家分享，那就非常感謝您為群組的每個人的貢獻。

PS.最近個人網頁關站整理中

［議題討論］網路行銷

竹子日誌（竹子） — Thu, 01 Feb 2018 20:18:06 GMT

大家對於網路行銷的手段和方式了解多少呢？可以點出自己知道的部分提供給大家參考喔！如果在這方面有所技術，也許會有人有興趣找您合作😄

一樣24小時，我會提出我的知識範圍，不懂的當擴增，懂的我們一起交流！

薇：網路行銷這塊我不太懂😂

竹：沒關係～可以找找相關資料，培養不同的能力都有用的！

薇：目前公司有涉及架設網站，應該多少有點關聯性。

竹：我會把我知道的一些看法打出來

消費與否的三個要素：需求、信任、能力

行銷這件事目的是要降低銷售的難度，權衡一個人是否消費產品在幾個要素：「需求」、「信任」、「能力」，三大要素。

需求指的是對於產品帶來的「問題解決」能力有關，消費者卻是在生存上產生痛點，因而誕生需求，而滿足這個問題被解決的產品就是滿足需求。

信任是對於商品品質及價值的信任感，或是對於品牌形象的信任感，對於人則在於其好感度和專業度來建立自己的信任感。

能力指的是消費者的消費能力，白話說就是他夠不夠拿出產品最低標的資金。

行銷真正在累積的是信任感

行銷的策略延伸就多不勝舉，廣告方式這麼多：活動、宣傳、推播、業配⋯但是什麼才是有效的呢？

這個留著給大家再討論並思考看看囉！

明天晚上一樣會接這篇主題繼續，今天就先到這裡啦！

過去有效的手段，現在都失效了

哪一種網路行銷適合自己？

那你找到自己的產品該如何行銷了嗎？

可以分享看看自己的方法或想法喔！

品牌價值不是經營者自己定的

題外話，我最近四、五個潛在客戶分析行銷，其實發現很多人都有一些對行銷的了解很不清楚，不知道怎麼去打造自己的品牌價值。品牌的定義不是經營者自己定，而是端看經營者提供什麼價值後讓消費者來制定。市場上每一次的交易的是場投票，必須好好爭取這些選票。如果這兩天講的東西還是聽不懂，代表在相關商學概念還是很欠缺，請持續關注我，未來在不同的議題上你慢慢尋找更多知識的建構。如果很需要直接做「經營模式健康檢查」，那麻煩私訊我，我們約一個充裕的時間，我會盡我所能去協助您找到問題。

［主辦活動］MBTI性格解析

竹子日誌（竹子） — Tue, 30 Jan 2018 22:43:32 GMT

人生迷惘不知道未來想要做什麼工作？工作不是自己想要的，想轉職但不知道要往哪裡發展？學習學了好幾年才發現不是自己想學的，我該往哪些方向前進呢？

很多人還不了解自己，想要更了解自己嗎？

這個活動主要幫助還沒找到人生目標方向的人，透過網路現有的適性測驗，以及我整理出來的部分報告資料，能找出自己自我認知特質中適合的工作或方向。

本測驗需要約1～2個小時的時間，以及1小時以上的解說，如果有需要的聯絡我報名，可以採用網路會議視訊，所以不用擔心距離。

可能有些人做過了，不過只要覺得迷惘都可以做，每次結果都不同，代表人生階段的改變，我也會不斷更新每次舉辦的題庫和延伸說明。

我也歡迎群組外的人參加，請另外知會我。

［議題討論］旅かえる

竹子日誌（竹子） — Tue, 30 Jan 2018 22:36:25 GMT

最近很流行一款日文手機遊戲：旅かえる（旅行青蛙），即使不懂日文，也有許多人下載，我的臉書頁面，幾乎至少被攻陷一半。

我先提出這個議題，有想法的可以先提出來，一樣24小時後我會提出我這邊的想法和論述。

群友的看法

薇：其實這款遊戲也反映了日本青少年的心態

竹：這次我分享一下別人的想法，不過我認為他說的很好，關於這個我多日前已在臉書發布想法，所以我招來一些不錯的文字來給大家觀賞。

這隻青蛙教會的十件事

這隻青蛙，教會我的事情是：

1.不要擔心宅在家裡的孩子，他哪天想通了，就會走出去。

2.真正的信賴關係，不是建立在佔有，而是隨他去。對生命尊重，就是對自由尊重。

3.關係，不是付出多少就能回收多少。一分耕耘一分收穫，這種事情不存在現實生活中。

4.付出如果有回報，都要當作是意外的驚喜。情感勒索孩子，他只會離你越來越遠。

5.不要想操縱任何人，包括自己的孩子。更不要強迫孩子去複製別人的人生，每個個體都不一樣。

6.旅行，是療癒自己與別人的一種方式。

7.面對分離，不願意放手，難過的只有自己。

8.要告訴你的家人，不論他遇到什麼困境，隨時歡迎他回來。

9.人生本來就是孤獨的，善待那個在你身邊的人，因為他隨時會沒有原因的離開你。

10.生命自己會找到出路，青蛙也是。

擷取自：Facebook呂秋遠

它為什麼會紅？因為它背道而馳

當然，也可以聊聊為什麼它會紅。現在絕大的遊戲拼死想用「獎勵」的模式留住使用者的注意力，但是旅行青蛙則背道而馳，有個性的青蛙你永遠不知道他什麼時候出門、什麼時候回家。

這家公司Hit-Point曾出品「貓咪收集」這款遊戲，也是紅及一時，主要是操作簡單直覺、不受語言限制等等特性，抓住大眾胃口。這次的旅行青蛙也相同，據統計，這款遊戲深深受女性用戶的青睞，也突破歷年來的下載量。

其實這件事告訴我們，現在消費者的注意力大量被分散，要有足夠的突破框架才能夠取得截然不同的反應。現在商場上、生活上更是如此，想要有突破，有時候背道而馳或許是不錯的手段，嘗試看看也許會有不同的結果。

［議題討論］7-ELEVEN 「X-STORE」

竹子日誌（竹子） — Tue, 30 Jan 2018 19:08:49 GMT

https://youtu.be/UaURDH2K4PA

https://youtu.be/MXSU4ACPiDE

我先提出這個議題，有想法的可以先提出來，24小時後我會提出我這邊的想法和論述。

先開放大家講

竹：有什麼想法都可以講喔！

不管是從投資者、經營者、消費者角度都可以。

薇：嗯⋯我覺得是說給我們自己使用的話，比起有員工的商店這種無人的有點費時⋯還有機器耗損律的問題😂😂

蕭老師：人事成本大幅降低

仁：投資者經營者：機器買入後只需定期維護，不需考慮薪水、加班補貼勞健保等等的，無人商店以目前來說如果推出也是的吸引客人的噱頭。

消費者，麻煩在全要自己動手，但一大部分看影片是拿了就走還不錯

所以其實這個還有卡到線上支付的問題這影片沒直接弄出來就是了

X-STORE 用到的跨時代技術

竹：他們使用跨時代的技術，包含「人工智慧」、「RFID」（射頻辨識）、「大數據物流管理」、「圖像辨識」等新時代科技，提供超越現在思維的UX（使用者體驗）。

本身我認為這間店的出現不是單純為獲利誕生，而是商界龍頭的一個指向標竿，初期無人商店其實要考驗的項目非常多。

無人商店的五個問題

問題包含

1.UX並不如有實際的服務員，少了「溫度」。

2.結帳的RFID沒辦法應付大量的產品，商品標籤化成本極高。

3.少了實體服務，像是帳單服務、熱食供應、現泡飲品、商品諮詢、架上整理等⋯⋯

4.據全球統計，無人商店的商品失竊率約略1.5%，考驗人性和防盜設備。

5.辨識技術尚有許多技術盲點。

當然也有六個優點

當然也有優點

1.無人化管理，大幅減少輪班的人事成本。

2.便利商店能夠普及到更偏遠的地區，也可以一定程度減少倉儲和動線的地皮成本。

3.完全導入「被動收入」的概念。

4.使用電子結帳，消費者不再需要帶現金，店內也不會有現金。

5.為技術標竿，帶動IT產業、傳統電子產業、傳統建設產業的發展和商機。

6.部分消費者有「人際距離恐懼」，也算是文明病，但是可以滿足這塊市場，並匹敵網購的風險問題，有實體的商品。

仁：第六點不同意，如果只是超商的人際距離都無法接受，他絕對不會出門。

活動主題、討論議題

竹子日誌（竹子） — Tue, 30 Jan 2018 17:36:08 GMT

餐飲店管理

電子商務

投資工具

健康虛擬貨幣

RFID技術

外國的IT人才培養

穿戴式裝置的展望

基本電學

何謂量子電腦

活著，追什麼？

書單整理

定價的秘密

領導技巧

自動駕駛

智慧音箱

數據是未來重要的能源

VR導覽服務

個人化UX精準行銷

空調系統

番茄工作法

魚骨圖分析法

Jommy頻道

地域的市場不同

太陽能

人才是資產

正面表述

何謂機會？

自己建構的系統才是真的

太陽花運動

社團板規：

竹子日誌（竹子） — Tue, 30 Jan 2018 17:23:24 GMT

1.嚴禁丟「長輩圖」、「長輩文」。

2.分享網路文章和影片請附帶說明、推薦原因，或是詳細論述文，切勿Po了就不管，這樣只是在散佈謠言。

3.請勿分享跟本社團核心意義無關的文章。

（商學、成功學、技術知識、工作機會）

4.以上為基本條文，後續追加。違反勸告不聽踢出本社團。

補充：

本社團管理員「たけ竹子」

不定期提出討論項目供大家思考

不定期舉辦各類諮詢或網路活動

已經有個人專長、商品、產業的人，歡迎貼出自我介紹，我都會整理進筆記本，如果有業務上的交流也都是儘量協助大家能滿足需求。

在這裡平常不用發文，看到有興趣的題材可以再提出疑問或是想法有想要討論的東西歡迎提出來。

如果對過去的歷史文章有興趣

可以去筆記本查看

再私訊我傳給你看

對任何議題有興趣歡迎私訊提供給我

不要在群組亂丟不相干連結喔～

因應新加入的人越來越多，如果有任何歷史貼文有興趣，可以私訊竹子喔！這些貼文依然會在群組再次發文，讓沒看到的可以重溫一次～

入團前言

竹子日誌（竹子） — Tue, 30 Jan 2018 17:18:52 GMT

請朋友進入前可以給朋友看的：

最近我在一個很厲害的群組

裡面都是很有想法的人

在各行業都有相關的人

主要是要分享對商業理論相關

或是討論未來趨勢、想法

也不定期會有案子或需求可以承接

若有相關產業問題可以諮詢他們

剛進入的麻煩去筆記本閱讀版規

也可以看看每個人的自我介紹了解大家

順便整理自己的自我介紹傳給我

如果對於前面沒有看到的議題有興趣可以私訊我

我都有備份整理

我不適合當商人

竹子日誌（竹子） — Mon, 25 Dec 2017 17:24:06 GMT

當一個億萬富翁是許多人的夢想，然而事實上並沒有那麼容易，更甚有些人直接答覆⋯⋯

我不適合，我不會做生意⋯⋯

但事情真的是如此嗎？真的是不適合嗎？

在現代社會，人們總認為富者恆富，貧者越貧，資本主義資本創造財富。這可以說合理正確，也說錯了一半。

富人就是「掌握財富流動規則」的一群人，貧者就是被財富洪流衝擊的人。

有些人責怪，我沒有資本。有些人責怪，我不不適合做生意。有些人責怪，我不適合創業。

然而，有沒有問過自己，讀了那麼多年的書，自己真的都沒讀懂還是沒認真讀？那你是搞不懂規則，還是不適合當生意人呢？

這問題答案很殘酷，但說明了很多。大部分的人是沒有掌握規則，並不是不適合。

但是人們會告訴你，別碰⋯⋯別嘗試⋯⋯

假設，每個人都叫你不要去讀書⋯⋯不要認真讀書⋯⋯不要去上學⋯⋯你認為你能夠順利考上理想的大學學嗎？

這就是為什麼創業的成功率這麼渺茫的原因⋯⋯因為不但沒有人教你，大家還會拼死阻撓你，勸說你放棄⋯⋯

你掌握財富流動的規則了嗎？

你嘗試去了解它了嗎？

你盡力去掌握它了嗎？

如果你的行動不夠，那必須付出更多行動。

如果你還在害怕，那就必須跨步向前。

如果你還不懂規則，我會告訴你！

不花錢就能創業

竹子日誌（竹子） — Wed, 20 Dec 2017 21:53:58 GMT

許多人總是糾結我沒有資本，認為沒有資本就沒辦法創業。那這個資本定義多少呢？數百萬？數十萬？其實有時候幾萬就可以，有時候可能一毛錢都不需要。

真正創業要的資本是「時間的成本」，還有資源運用的代價與風險的承擔，貨幣這種東西並不是最重要的。

在自媒體當道的現在，創業已經不需要打把的資金，真正需要的是什麼？

是屬於你的「市場」！

跳脫原本的思維框架，先了解「創業不需要龐大的貨幣成本」，那你還擁有什麼？你的熱情，你的智慧，你的時間，這都是別人拿不走獨一無二的資源。

那麼要賣什麼？去包裝你的興趣，包裝你的知識，包裝你個人品牌，你就是一個獨一無二的公司。

曾經有人問我，我愛跑步，但是這沒辦法當飯吃。跑步是種運動，所有只能當運動員？並不是這樣，光是跑步也可以包裝。你可以去結合旅遊攝影、技術指導、同好整合，然後找到你的市場，並建構出商業模式。

但這其中有很多細節是必須被克服的，每個人的成功模式是獨一無二的，去尋找成功的自己是什麼模樣，朝那個方向前進！

讓錢替你工作

竹子日誌（竹子） — Tue, 12 Dec 2017 09:54:56 GMT

字面上，讓錢替你工作，並不是要表達去投資股票房地產什麼，那是高槓桿高風險的行為。我所要表達的是，要量化時間，把你每一個小時的價值衡量出價格。浪費時間的事千萬不要做，要有效益、效率做每一件事。

那讓錢為你工作是什麼意思呢？就是利用手上的錢去做節省時間的事，再用省下來的時間賺更多的錢。好比你的能力產值每小時是200元時，做家事料理雜物可能要浪費自己4小時的時間，如果能夠委外花600元，每小時反而是賺50元。或許這個例子不是這麼貼切，但是核心理念是這樣子的概念。

因為人類唯一公平的地方是每個人都有24小時的時間，妥善運用這24小時很重要。很多原本自己要花很多時間完成的一份工作，佔據自己有限的時間，不如讓其他擅長該工作領域的人有效率高品質的替自己完成任務。這時候自己再去做自己擅長並且有效獲利的工作，以提高個人基礎產值。

當有資本有儲蓄後，有規劃的理財投資，做好風險分配和獲利停損，真正讓錢替你工作。

到底需不需要證照和學歷

竹子日誌（竹子） — Tue, 12 Dec 2017 08:36:16 GMT

很多人很拼命去花錢補習考證照，又有人花大錢去上大學甚至攻研究所，對於這些理所當然的事長輩們都覺得是非常上進的行為。然而許多人還是會對證照和學歷保持懷疑，到底花金錢和時間去爭取那張紙有沒有用？

我必須明白說，因人而異。首先你必須非常清楚，證照和學歷當初存在的本意。在一間公司不知道你這個人的能力之前，學歷代表這個人會不會讀書，有沒有上好學校畢業代表聰明才智和認真度。但是你會說這不是絕對的啊？很多企業的老闆和主管根本沒有高學歷，王永慶也只有國小畢業，但是這是一個「便利性的相對值」，雖然不是絕對，還是有可能遇到媽寶或是書呆子，但還是能夠有效篩選出容易有問題的員工。證照也是如此，它只是去做一個專業付出的驗證，了解基本的態度能力。證照另一個功能就是執行條件，特別是業務證照和危險工作技術員證照，含帶的更是一個基礎要求。所以學歷和證照是什麼？是一個基礎的「門檻」，沒有門檻就不能於社會立足，到哪都是拒於門外，更甚是違法。

但是，更是要注意，證照只是「門檻」。或許有的人會認為學歷越高越好，證照越多越好，這就是迷思。學歷要端看產業和職務來決定，目標只是到達「門檻」，更高就是多餘。證照也相同，不需要花無謂的時間去考取各種七雜八雜類型和等級的證照。目標就是考到執行專業技術行為政府在法律上要求的「門檻」，以及在產業上企業認同的特定執照，更多就是浪費。有的產業甚至根本不在乎證照和學歷，有的看的是作品，有的看的是面試實力。但是有兩種東西是一定有用，就是「人脈轉介紹」和「工作年資經歷」，職場上很好用。然而，不是每個人志在就業，有些人就是想創業，那麼最重要的就是公司管理營銷的相關技能了，其它「門檻」就不是自己應該去煩惱的問題了。

竹子的人生日誌01

竹子日誌（竹子） — Tue, 12 Dec 2017 08:13:06 GMT

高中時代，我不怎麼懂人際關係的應對進退，搞壞了各種同班同學應該要的相處。個性孤僻也好，難相處也好，不合群也好，當時的我就是這副德性。後來和班上一個挺糟糕的人成為朋友，成績一落千丈，完全無心在課業上。然而，在過去的好朋友不斷鼓勵之下，我燃起讀書的火焰，想說在高三再拼一次。但沒有相稱的人一起比拼一起讀書很孤單，終究人類鬥不過自己的意志力，模擬考的成績也像海浪上上下下。最後便面臨高三聯考了⋯⋯

這段時間比較有趣的部分，我非常沈迷一款名為「魔獸爭霸-寒冰霸權」的一個遊戲，但我不是迷玩遊戲，而是我非常著迷它的地圖編輯器，極高的自由度和彈性。使用內建的程式語言Jass，還有容易上手的GUICode，我設計出一款屬於我的地圖遊戲。這個經驗非常可貴，我很扎根建構基礎的程式語言邏輯，為未來某個階段進行接軌。

高中因為跟班上的同學關係不好，但人類畢竟是群居動物，總是需要尋找一個歸屬，因此我的小圈圈建構在其他班級的邊緣人物。其實這個階段的我非常沒用，書沒讀比較好，能力也沒有比較超群，人際關係處理更是一塌糊塗，真的是未來一片茫然。就在這個時候很重要的關鍵是我決定去從軍考軍校，這是一個很重要的改變，很多未來的發展都是這個階段這個決定產生的蝴蝶效應。

接著我順利考進海軍官校，開始我人生另一段開始⋯⋯⋯

景氣不好就沒有機會？

竹子日誌（竹子） — Mon, 11 Dec 2017 20:33:04 GMT

常常有人怪罪，社會景氣很差，沒有機會，努力不會收穫。然而，真的是如此嗎？

1960年代開始，台灣重工業興起。1980年代，台灣電子科技業發展。

隨著十大建設的推行，創造國際享譽盛名的「台灣奇蹟」，連續三十年GPD成長率達8%，外匯存底世界第4，竄升成為亞洲四小龍之一。

然而那是歷史了，活在那年代，創業也好、做工也好、投資也好，做什麼都賺錢的奇蹟時代已經結束。

現在是商界的戰國時期，機會不再憑空產生，端看你做了什麼改變。

現在的生存法則不是「努力」，而是看到「市場」，並且精準把握它。

太多太多人活在台灣奇蹟的神話裡面，覺得自己年輕時無所不能，然而這只是因為你剛好站上風口，風停了，你也落下了。

不要去期待機會將從天上落下，不要期待老闆會幫你加薪，不要期待去投資會翻賺。

現實一點來說，真正的機會在於了解市場的變遷和結構，找到供需支點，獲取支點上的利潤。

去好好培養自身的本領，當你什麼能力都沒有，你終將錯失機會。

需要什麼本領？其實只要一樣本領你就無所不能，那就是「銷售」。

不要再拷問你的新認識的朋友

竹子日誌（竹子） — Fri, 08 Dec 2017 20:30:48 GMT

有的時候聊天就是一個交心，分享相互的思維，或是擷取自己想要得到的資訊，這是一個很開心的過程。然而，有些人在聊天像是審問調查，調查對方的家世背景。每個人的地雷不同，有的人不喜歡被問職業，有的人不喜歡被問父母，有的人不喜歡被問年紀，但是這些又代表什麼？一個人的實力是建構在談吐的內涵，建構在拿出來的硬實力，而不是像履歷表一樣被填寫。多去聆聽對方擁有什麼，掌握什麼，可以從對方身上學些什麼，那才更重要。

現階段的職業代表什麼？父母在做什麼事什麼樣的人又代表什麼？年齡又代表什麼？如果挖掘出這些消息是為尋找對方弱點而加以傷害，那不如不要問，因為這是非常過分的行為。

我在和業務員打交道時，類型可以說是形形色色，世界上真是什麼奇怪人都有。

職業不過是個頭銜

一個人的職業不代表一切，斜槓青年是一個新時代的名詞，一個人的職業不再單一，他能夠擁有許多身分。職業不過是個頭銜，它沒有意義，最重要的是他平常在做什麼。

家不一定是每個人的避風港

有些人原生家庭不怎麼光彩，或許是存在他內心的黑暗面，冒昧的問是種傷害。家人很多時候都是避風港，是溫暖的地方。但不代表世界上每個人都這麼認為，有些人的家庭是痛苦的，有些人的家庭是黑暗的，還需要更了解嗎？

「小孩子懂什麼」這種態度

仗勢自己的實力和高度氣勢凌人，真不曉得是在想什麼。甚至有的長輩更是覺得「我的社會經驗豐富，小孩子懂什麼？」那種態度更令人厭惡。未來的時代，是90年代孩子的時代，他們更加令我畏懼，他們更是無邊無際的時代，他們的思維就是未來的思維。我尊重他們，也願意引領他們。這些80、70、60、50年代的人們，你用什麼樣的高度看他們呢？受不起壓力的草莓嗎？那你們太輕視90人了⋯⋯

交心不是拷問

有人說做朋友就是要交心，交換彼此的資訊。這個社會太險惡，對方抱持什麼居心並不清楚，適當表達不要全盤托出，這是保護自己。然而你在認識新朋友時會問什麼呢？像教條式問對方職業、父母、年齡、星座、住在哪裡、畢業學校？這跟拷問犯人有什麼兩樣？適度尊重對方很重要，了解對方的興趣、專長、學習過的技能、喜歡的事物等等，這才是真正的交心，你平常還在拷問人嗎？

有誰不需要學推銷？

竹子日誌（竹子） — Thu, 07 Dec 2017 21:35:52 GMT

推銷商品一定要是一個業務員才要學嗎？推銷應該是任何人都必須要掌握的技能。也許有人不擅長，但是不擅長有不擅長的表現方式。所謂的推銷是要以某種方式提高某個產品本身價值，進而讓被推銷對象內心感受到產品的價值上升。然而這個產品一定要是某種東西嗎？不需要，世界上最獨一無二的產品就是自己。賣自己，這是最重要的事情，拉抬自己的價值，讓個人價值提高到對方內心衡量的那條水平線，那你就是一個優秀的業務員。或許，有人會認為，我不是業務員，為什麼要會推銷？因為你在交朋友要推銷自己、追女友要推銷自己、拜師學藝要推銷自己，那你真的不需要學推銷嗎？這是何等重要！

推銷也有兩種方式，一個叫「銷售」，一個叫「行銷」。銷售是一種我當下就要把產品賣出的行為，目標是讓對方在感覺上立即接受，產生出「想要」的一個快感。行銷是透過價值的堆疊，以多次多段的方式累積價值層次，直到對方內心的衡量超越那條水平線。兩者方式有好有壞，沒有一種最好的選擇，但兩者的重要度都是存在的。

為什麼我的薪水不會增加？

竹子日誌（竹子） — Thu, 07 Dec 2017 21:22:44 GMT

你認為時間不夠用？

你每天最在乎的是什麼？

你每天積累下來把時間花在哪裡？

把時間花在哪，成就就落在哪

「異類」一書提到的10000小時定律，人類從平凡到超凡必先經歷的捶鍊，把時間花在哪，成就則落在哪。

在乎樂透簽什麼號碼才會中？在乎喜歡的人什麼時候會喜歡自己？在乎身邊的人林林總總的八卦？在乎同事為什麼處處找自己麻煩？在乎下屬開竅為自己多付出一點？在乎公司老闆什麼時候幫我加薪？在乎政府什麼時候調高薪資？在乎社會什麼時候才會景氣一點出去創業？

在乎別人的時候，你花多少時間在自己身上？

現實上，這些事情都不會發生。當你忙著在乎別人的同時，想想你花了一堆時節在「別人」身上，那你花了多少時間在自己身上？

當自己提升的時候，就會更有能力去改變原本改變不了的現實。世上最有影響力的人，他們會花一堆時間在乎誰去影響他嗎？並不會，他們花更多更多時間去改變自己的影響力進而影響更多人。所有的問題一直執著在「發生的問題」上面，你只會擁有發現問題的能力，大部分的人都是如此。什麼人最有價值？不但具備發現問題的能力，更要具備「解決問題」的能力，多去在乎怎麼解決你面臨的問題。遇到問題就去做，硬的不行就繞道，不斷去嘗試、去解決、去失敗，你會更加卓越成長。

薪水的問題，其實是選擇權的問題

這時，就必須提到殘酷的「薪水」問題。薪水，再努力都不會增加，再努力成長老闆也不會加薪。那麼，你的思維似乎還在「老闆選擇你」上面，那你不具備「選擇老闆的能力」。說的簡單～確實，因為這就是不同之處。你增加收入和選擇的權利只有存在等老闆幫你加薪這點，你自然沒有選擇權。那麼如何加薪呢？去銷售你有價值的「資源」吧！沒有資源就去花時間收集，盡其所能去蒐集有市場價值的資源，並且去包裝去銷售它！

你的資源比你以為的多

或許你會認為自己沒有資源，更沒有可以獲取的管道⋯⋯興趣是一種資源、過去工作經驗是一種資源、擅長的領域和技能是一種資源、性格和習慣是一種資源、朋友的資源也可以是自己的資源，你怎麼去發掘去整合你擁有的資源？這些資源經過整合包裝就是產品，去包裝設計，去尋找市場，去銷售它！

我認識有高中生知道去尋找便宜的公仔和飾品然後差價賣給朋友。

我認識有中年大叔幫朋友完成工作上不擅長的文件資料，並收取代勞的薪資費用。

我自己是立即學習有市場的技能幫朋友服務，進而收取技術和勞力的費用。

不要覺得跟朋友收費很不好意思，不要覺得朋友跟你收費很利益很現實。如果你不懂得尊重朋友的專業知識、技術服務、勞力時間支出，那麼你才是最自私自利的人。

AI的浪潮

竹子日誌（竹子） — Wed, 06 Dec 2017 17:53:25 GMT

我們都知道人工智慧的技術發展是一種趨勢，在未來我們人類許許多多都害怕著人工智慧的來臨，他們會取代我們的許多產業。這種浪潮是想必是無法阻擋，但是也會帶來相對的產業衝擊，伴隨而來的就是大量的失業。你在做的工作會被人工智慧取代嗎？如果你的答案是不確定，那你意識你的危險了嗎？未來帶來的衝擊與改變你做好準備了嗎？

有人遇到趨勢的浪潮選擇逃避，他們拒絕、抗議、打壓，然而科技始終來自人性，市場的接受產生需求，這種浪潮無論你怎麼去抗拒都沒辦法終止。

1896年時，火車運輸業進入中國，當時火車強大的載客量和運輸速度無以倫比，當時中國主要的運輸業時仰賴馬伕載送，因為火車的引進，造成運輸市場的衝擊。當時馬伕的工會和成千上萬的失業者矛頭指向火車，他們都說那是怪物，造成他們的生存問題。經過許多的抗爭、破壞、打壓，市場對於火車的性能和便利性皆提出肯定，海量的馬伕面臨失業。你知道失業的馬伕去哪了嗎？

我想表達的是，當科技衝擊產業，浪費的人力需求終將被淪為歷史，讓人工智慧替人類完成複雜的工作，這是進步。遏制人工智慧的成長，指說它會帶來巨大的社會問題，可以試想上面那則歷史故事。現在，是馬伕街上跑還是動力運輸當道呢？這件事足以說明趨勢的力道，你不該正視這件事嗎？

在未來，

司機可以被人工智慧取代，

醫師可以被人工智慧取代，

法官可以被人工智慧取代，

士兵可以被人工智慧取代，

作業員可以被人工智慧取代，

會計師可以被人工智慧取代，

結帳員可以被人工智慧取代，

上面等等有的可能我沒有提到，或是你已經被點名，你準備好面對工業4.0了嗎？

每一次的工業大革命都會產生轉型，唯一解套的方法就是產業轉型。改變你的思維，跟上時代的腳步，你才足夠承受衝擊！

話題怎麼源源不絕？

竹子日誌（竹子） — Wed, 06 Dec 2017 04:58:18 GMT

常常苦於和朋友沒有話題聊，或許朋友們對於各種話題有的保有興趣，有的沒興趣，但是如果你不管什麼時候都可以豎立滿滿的話題，你就是一個有趣的人。然而話題怎麼準備？凡是生活上跟別人會有不同的事、時下流行議題、各種領域的經驗、與別人交流的故事、旅行的見聞，甚至連吃飯吃了什麼、社群看到什麼趣事等等都可以當話題。但是許多話題時機點過去就忘記了，如果隨身準備一個話題筆記本，看到、聽到、想到的時候紀錄下來，日積月累就是一個豐富的話題筆記。也或許你會認為多帶一個筆記本很麻煩，但是科技永遠是替我們解決問題的，盡可能去利用手機替我們做很多原本認為麻煩的事。

也有人說，一個話題一下子就聊完了，但是如何懂得去深挖話題也很重要。

比方說：

A:喜歡吃什麼？

B:日本料理。

A:喜歡那些日本料理？生魚片還是壽司？

B:生魚片吧⋯⋯！

A:我也是欸～特別愛吃哪一種魚嗎？

B:其實都喜歡～

A:我就特別愛吃鮭魚啊～

B:是喔？

A:對啊！因為鮭魚的油脂特別香，肉質特別軟嫩，所以我最愛鮭魚。

B.鮭魚是真的很好吃！

A:對啊！你也這麼認為對吧！

B：恩恩～

A:聽說市中心的XX日本料理店的鮭魚特好吃欸～

B.是喔⋯？

A:改天我想吃看看～你要跟我一起去吃嗎？

B:好啊～

這其中就含帶很多技巧。

工業化的演進

竹子日誌（竹子） — Sat, 02 Dec 2017 21:07:00 GMT

工業 1.0：蒸汽機與工廠機械化

工業 2.0：電力與大量生產

工業 3.0：電腦、網路與自動化

工業 4.0：虛實整合與智慧工廠

在這樣的世代你選擇怎麼前進呢？

何謂行銷？品牌的誕生

竹子日誌（竹子） — Sat, 02 Dec 2017 20:45:24 GMT

常常說的行銷行銷，行銷和業務銷售是截然不同的。行銷通過的是和消費者建立密切的關係後，去發展維持的一個行為，目的是達到一個品牌、口碑的產生，進而影響消費者願意去消費。這個過程是漫長而紮實的，透過任何形式的媒體傳播有價值的資訊給予有興趣的受眾，直到達成足夠的價值堆疊。

發生消費需要的其實是三個條件，需求、能力、信任。當消費者本身對產品能解決的問題產生需求後並不一定會發生行動，這時候需要對該問題在乎，並且「想要」去解決或是行動。結論而言不只是需要，「想要」尤其重要。而消費者想要就會檢視自己是否有能力去進行消費，就好像大家都想買房子，但卻不一定有「能力」買下房子，類似這樣的道理。然而市場上不可能只有一種商品，一定有相對多多商品，要贏得市場在競爭的就是要靠行銷做出差異化策略，而這個差異化就是「品牌」的建立。

「品牌」的建立並不是自己說了算，「品牌」的定位也不是自己說了算，應該是透過行銷讓消費者內心感覺到對你的認識、信任、形象化。想要創造怎麼樣的品牌根據你行銷的手段和傳達的資訊不同而有莫大的差異。

所以我們知道要做品牌差異化，卻也容易陷入迷思，究竟品牌差異化是怎麼回事呢？並不是「不一樣」就是品牌差異化，必須要消費者有感的差異。一般來說就是能夠對消費者產生價值感的東西，如此一來就有效提高「信任」。其中包含價格、專業度、服務、便利、名聲等等都是牽涉因素，所以行銷手段百百種，有效堆疊顧客內心價值的就是好的行銷。

何謂市場？供需理論

竹子日誌（竹子） — Thu, 30 Nov 2017 21:16:46 GMT

市場不是說你跑去買菜的那個地點叫市場，那你就大大的誤會了。我所指的市場就是由「供應」和「需求」所構成的交易存在體。市場沒有地點的限制，任何地方只要發生交易就是市場，前篇已經解釋什麼是交易了。

要講市場就必須從供需開始說。

什麼是供應？就是提供了某種產品或服務。

什麼是需求？就是某種產品或服務被需要。

有人可能會說，所以先有需求才有供給囉？那麼世界上第一台電腦被發明以前有人會說需要電腦嗎？當然沒有。所以這個先有需求還是先有供給是不一定的，但是市場的產生就是供需兩者某一種先誕生。

人和人之間的來往本身就存在利益

竹子日誌（竹子） — Thu, 30 Nov 2017 20:19:25 GMT

這句話我講過不下百遍，但總是有人直覺回答我，人和人相處談到利益就傷感情了，會這麼想的人你不是在消費你的人脈就是在浪費你的人脈。

我實在想強烈表達，有人說利益一定是「金錢」的形式嗎？中國人有句成語「禮尚往來」就是指這個行為。感情的依靠是種利益、玩樂陪伴是種利益、被尊重的感覺也是種利益，你確定你的好朋友和你沒有利益嗎？

但你再想想，為何會物以類聚，就因為你的朋友們跟你可以依靠，或是你本身有某種他可以取得的價值。你自己若是沒有價值，憑什麼別人在乎你？憑什麼機會降臨在你的身上？憑什麼擁有人脈？你究竟剩下什麼價值？這講起來就殘酷了，你的價值決定在於你擁有的資源。越是資源豐富你越有價值，人們自然會靠近你，若是你沒有對等的資源，那麼你自然只會吸引跟你一樣缺乏資源的人。那為什麼還是有人會找上你？因為你擁有某種被利用價值，最差一點是錢和時間，稍微好一點是你身邊親近的人擁有的關係，如果是技能、技術、知識呢？

所有人和人之間的來往本身就存在利益，在於你被利用的價值有多少來取決你能夠吸引到什麼程度的人。

何謂交易？

竹子日誌（竹子） — Thu, 30 Nov 2017 19:33:54 GMT

交易這種行為其實就是兩方在價值認可中所進行的交換，交易從來都不是等價的，只有在價值被兩邊認同的前提下進行交換就是交易。

過去我們都是以物易物，舉例來說，我是種蔬菜的，但是我想要買肉，我會和屠夫進行肉品交易，在雙方議價後訂出價值定義後將手上的蔬菜和對方的肉品進行交換。然而隨著貨幣的出現，我們人類開始使用貨幣，也讓交易在議價的過程提高了很多效率。然而，自從「賒銷」這樣的模式出現後，有種看不見的價值叫「信用」誕生，我們人類在金融的歷史上步入一段輝煌歷史。直至現今，我們的交易模式變得非常多而複雜，而不再是單純的貨幣交易。

在商場，交易是最基本的觀念，如果你不懂交易的本質，那你永遠不會了解商人的把戲。更不會去用正確的方式銷售產品，更別說銷售自己這個品牌。

我講的許許多多的名詞其實都可以講一大篇文章，但這不是這篇文章的重點，今後我會一一闡述這些東西，讓你不再覺得成為一個商人很困難，更別說收入，它會直接的反應你的高度。

總而言之，交易就是兩方在價值認可中所進行的價值體交換。這個價值體可以是有型的商品、一種服務、一種訊息、一種系統⋯⋯等等沒有框架，只要對另一方有價值就可以進行交易。

財富到底怎麼來？

竹子日誌（竹子） — Wed, 29 Nov 2017 20:14:16 GMT

常常有人問，怎麼賺錢？

勞務資源，自己付出的勞動力，過多的疲累導致就算下班後你也不再有力氣去付出，選擇休息，選擇什麼也不做，這個代價阻礙了你精進成長的空間。

資本資源指的就是握有的貨幣，這就是資本主義社會的一個牽動因素，如果不能握有這樣資源，那就成為社會的底層。

健康資源，這是最容易被濫用卻渾然不知，包含熬夜加班、高風險工作、高職業傷害工作等等損失，揮霍消費卻渾然不自覺。

竹子日誌

AI 不會痛，所以沒有人重構：Vibe Coding 真正的天花板

三個月、四百多個 commit，刪除行數幾乎是 0

沒有人痛，就沒有人重構

極限不是行數，是你驗不驗得出來

它不會壞掉，它會變貴

那要怎麼做才撐得住？

一、系統的核心，要放在檔案裡

二、測試是把看不見的錯誤變成看得見

三、模組要切到你敢整包重寫

但我還是要講一段比較難聽的

不就一個下拉選單，是能有多難？

起點不是想造輪子，是一個搬不動的案子

我造這顆輪子，是為了什麼

那叫 AI 生一顆 Select 不就好了？

v1 到 v4：我把原生 select 免費送的東西全丟了

v5 到 v8：先拆開，後面三版才走得動

八版之間唯一沒變的，是那一行 import

「能用」跟「能給別人用」，中間隔著出口設計

所以路還有多長？我排完自己嚇一跳

v9 到 v12：把「能用」補成「好用」

v13、v14：我預設的那個使用者，根本不存在

v15 到 v17：同一份程式碼，在不同的機器上長得不一樣

v18、v19：SSR、測試，然後真的發佈出去

走完這一趟，我才看懂別人為什麼那樣寫

那八版的前提，你上班的時候一個都沒有

重構的成本，從來不在程式碼

聽起來超對、但一定會失敗的四句話

換一種形狀：假設你隨時會被打斷

Vibe Coding 做得出 95 分的產品，缺的 5 分全是最貴的

它不是 demo，是真的在賣東西

UI/UX 的細節意識，高到不像一個人做的

三個自製引擎，一個 byte 都沒解碼

抽離音訊：手刻 MP4 Parser，只讀那幾段 byte

分鏡偵測：把 32 格畫成一張拼圖，只讀一次

音訊切割：把工作丟到音訊執行緒

但這個站沒有架構，這是暴力

body { min-width: 1024px }，手機直接放棄

全押新潮 API，但你的終端不一定買單

桌子擺好、椅子排好，然後沒有菜

前面省 80 MB，後面全部吐回記憶體

沒有架構規劃，未來只能繼續靠 AI

Vibe Coding 缺的那 5 分，剛好全是不好玩的東西

i18n 難的從來不是翻譯，是沒有人擁有那份語系檔

多語系的痛，是一層一層往下挖的

第一層：key 怎麼取，其實是誰來取

第二層：多語系的共用，比程式碼的共用更危險

第三層：工程的節奏跟翻譯的節奏對不上

第四層：在地化不等於翻譯

第五層：說白了，是政治

都用 Tailwind 就好了，寫什麼 CSS？十年演進都在解同一題

十幾年的演進，其實只有三件事

全域 CSS：簡單到不行，也髒到不行

預處理器：讓你寫得舒服，但沒讓你變安全

命名方法論：沒有工具強制的規範，都會被時間打敗

CSS Modules：我覺得性價比最高的一步

CSS-in-JS：樣式跟元件同生共死，代價是 runtime

Atomic CSS：你的 Tailwind 跟我的 Tailwind 不是同一個東西

Zero Runtime：不是新發明，是把老方案縫在一起

原生 CSS：現在瀏覽器自己都有了

那到底該用哪個？

Vue Taiwan 小聚：用一個下拉選單的輪子，講不好當標題的事

Refresh Token 到底有什麼難的？三個上線才會炸的地方

難的從來不是流程，是流程跑起來之後

RefreshToken 到底該放哪？httpOnly cookie 也有前提

併發不是一個點，是一整排堵不完的洞

一把鎖鎖不住五個分頁

長連線不走攔截器，它就默默掛在那

登出的順序反了，你就會養出殭屍

用了 SSR，前面那些要全部重來一次

第一個限制：render 階段不能改 cookie

第二個限制：你根本不一定拿得到判斷的依據

第三個限制：你會被迫維護兩套

所以 Refresh Token 到底難在哪

不要再創造沒意義的名詞，別再拿 AI 名詞製造焦慮

我反感的不是新名詞，是拿它當焦慮的原料

把包裝拆開，講的還是同一件事

玩具和產品之間，隔著使用者與責任

名詞會過期，焦慮會退燒

解決方案比畫圖寫 Code 還重要：AI 時代工程師的價值在哪

`body { min-width: 1024px }`，手機直接放棄