他說：「如果面試 Senior 以上的職位，我更看重他過去是否有處理正式環境 Critical issue 的經驗；因為技術可以靠後天學習，但有能力處理正式環境 issue 的人並不多。」

停頓了一下，又補充一句：「技術能力只能用來衡量平時的工作效率，但遇到緊急狀況時，在壓力下是否有足夠的膽量與決策能力就很看人格特質了。」

接著向我分享一個系統升級遇到意外的案例。

為什麼正式環境發生意外時很難處理？

如果公司有一定的制度與規模，系統在升級前往往有完善的單元測試，並通過 QA 團隊在不同情境的模擬測試。

因為事前已經考慮得相當周全，所以當問題發生時，就代表大家根本沒想過這個情境。

加上系統升級會對外公告維護時間，如果沒在期限內解決問題就出包了。

這邊我簡單描述一下問題是怎麼發生的：

A 系統升級時，會需要跑一個一次性的腳本向 B 系統取得資料；但 B 系統的資料不完整，所以 B 系統還要向 C 系統取得部分細節資料。

在測試環境跑腳本時，一切順利，但上到正式環境後，跳出了「timeout（超時）」的錯誤訊息。

如何定位問題？

出現「timeout（超時）」的問題後，大家並沒有很緊張，覺得只要放寬 A 系統呼叫 API 的時間就好。

但時間放寬後，timeout 的問題依舊存在，所以接著把目光轉移到 B 系統與 C 系統上，並將程式與 Nginx 的 timeout 時間拉長。

原本想說這樣問題總能解決了吧？

但結果不如人意，timeout 的錯誤依舊頑強地顯示。

為了更精準定位問題，大家把 A 系統、B 系統、C 系統的 API 分開測試，最終發現根本的問題在 C 系統。

不要讓自己陷入只有一個解決方案的思維

儘管成功定位了問題，但不知道為什麼 C 系統怎麼放寬 timeout 的設定都沒有生效。

而此時系統維護的時間剩不到半小時，想透過優化演算法來加快效率已經來不及了。

經過討論後，大家決定不解決 timeout 的問題，而是想辦法不要讓 API timeout。

最終的方案也非常簡單，只是將 B 系統取得的資料多拆成多份，以 C 系統絕對不會 timeout 的資料量傳送就解決了問題。

這個案例有什麼值得學習與警惕的地方

從結論來看，加 3 行程式碼就解決了問題。

但要做出這個決策並不容易，因為 A、B、C 系統是由不同的團隊進行開發，如果沒有良好的溝通能力，可能連一開始的問題定位都做不到。

找到問題點後，如果沒有人同時對 A、B、C 系統有一定的掌握度，我想大部分的人會把目標放在解決 timeout 問題，而非調整程式邏輯。

以這個案例來說，解決問題的人不一定要程式能力很強，但要具備良好的溝通能力，並對多個系統有一定的掌握度，且擁有靈活的思維，不會只想用一種方法解決問題。

我想，擁有如上特質的人，是市場上真正的稀缺人才。

最後提醒一下大家，雖然解決問題很帥，但以這個案例來說，只要在測試時考量到正式環境與測試環境的資料量差異，並加上對應的限制與分頁設計，就有機會避免問題發生。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

大綱

▋ 回答未必是正確的
▋ 回答的資料有限
▋ 拒絕回答敏感問題（ex：股票、虛擬貨幣漲跌、暴力、犯罪...）
▋ 回答到一半斷掉
▋ 提問次數限制
▋ 穩定性問題
▋ 流量大時狀況多

回答未必是正確的

May occasionally generate incorrect information（可能偶爾會產生不正確的信息）

ChatGPT 知道很多知識，但有時會給出一些看似正確，但實際上是錯誤的回應。

以下是筆者碰過的錯誤回答：

• 詢問他某個地方的旅遊景點 ➝ 景點不存在，或是根本不在哪個地方。
• 詢問他當地知名餐廳 ➝ 名字跟簡介煞有其事，結果一查根本不存在。
• 請他幫忙寫程式 Side Project ➝ 選用過時套件，使用套件方法錯誤。
• 請他協助重構程式 ➝ 重構後的程式可以運作，但部分解釋不完全正確。

有興趣的讀者可以去以下文章回顧：

• 如何寫出有效的 Prompt，獲得更好的 ChatGPT 回覆
• 靠問 ChatGPT 寫程式，能完成 OpenAI & Linebot 的 Side Project 嗎？
• ChatGPT Code Review、Refactoring、Comments 的能力如何？

雖然前幾篇文章已經提過了，但我還是再次提醒讀者：「無論未來人工智慧發展的多完善，我們都要保持獨立思考的能力，以及對答案的懷疑態度，請勿將 AI 的回答作為唯一的決策依據。」

回答的資料有限

Limited knowledge of world and events after 2021.（對 2021 年後的世界和事件了解有限）

因為他的資料截止於 2021 年，所以較新的資訊都無法提供，這也進階導致了部分回答的準確率；不過未來如果與搜尋引擎結合，那能力肯定大幅提升。

拒絕回答敏感問題（ex：股票、虛擬貨幣漲跌、暴力、犯罪…）

Trained to decline inappropriate requests.（受過拒絕不當請求的訓練）

如果詢問他股票漲跌、虛擬貨幣未來走勢，或是些暴力犯罪的問題，他會拒絕回答。

筆者在網路上看過有人用「寫劇本」的方式來繞過這個限制，但個人並不推薦這種操作。

回答到一半斷掉

相信讀者使用 ChatGPT 時，一定都遇過回答到一半就斷掉的問題（如下圖）。

此時用「繼續」這類關鍵字就能讓他繼續完成回答。

提問次數限制

如果在短時間詢問太多問題，你可能會看到如下圖示：

目前暫時無解，需要等半小時或是更多時間才能使用；未來 ChatGPT 會推出付費版本，相信到時會提高使用者的詢問次數、增加回覆速度。

穩定性問題

有時回答到一半就無法回答了：

又或是把一些很正常的內容判定成違反內容政策：

通常這類狀況只要刷新頁面（Reload）或開新的對話（New chat）就可以解決（也可以透過連結表單回覆你的建議，讓 AI 未來變得更完善）。

流量大時狀況多

如果你還沒登入，會被直接卡在外面：

如果你已經登入了，那網頁會三不五時就卡住，刷新頁面後會有如下彈窗：

以上是筆者目前遇過的狀況，不知道讀者還有碰到其他錯誤的情境嗎？歡迎留言分享。

目前 ChatGPT 還在測試階段，相信日後推出的版本（ex：付費版）會提供更穩定的品質＆準確的答案，就讓我們拭目以待吧！

想將 AI 導入自己的職場與生活嗎？歡迎購買筆者出版的新書，幫助您在 AI 的浪潮中站穩腳步，並在未來的職場競爭中佔據優勢！

大綱
➤ 保留太多無用的 console.log
➤ 沒有註明輸出的 console.log 要做什麼事
➤ 忽視 Console 吐出的警告、錯誤
➤ 不同函式共用「命名相同的全域變數」
➤ 大量存取不必要的 API
➤ 將很多用不到程式碼註解而非刪除
➤ 沒寫註解，或是寫沒有意義的註解
➤ Copy & Paste 後，Function、Variable 命名沒有改
➤ 沒有寫 try catch
➤ 在他人協助下完成功能後，沒有真正了解原理
➤ 沒有做 Refactoring
➤ 詢問別人前沒有自己嘗試
➤ 詢問的問題不夠精確
➤ 管理者權限與使用者權限混在一起

保留太多無用的 console.log

為了追蹤資料流向，我們會用 console.log 來確認程式是否依照我們的想法在執行；但有不少人只會一直增加新的 console.log，而不把已經不需要的 console.log 給移除。

沒有註明輸出的 console.log 要做什麼事

筆者曾在按下 F12 開啟開發人員工具幫人 debug 時，看到 Console 這個分頁下印出一堆 API 回傳的 response data，但命名完全一樣都叫「result」，這樣我完全無法知道這些 result 是由哪個 API 回傳的ＱＱ

不然就是很多意義不明只有自己才知道是什麼意思的 console.log（這類型的往往一個月後連本人都不知道在做什麼…）

忽視 Console 吐出的警告、錯誤

有些網頁看似運行的很正常，但在按下 F12 開啟開發人員工具後，你會看到一排讓人血壓上升的紅色 Error Message，如果沒有及時處理遲早有一天會業力引爆的。

不同函式共用「命名相同的全域變數」

像是 Vue 框架下用來儲存變數資訊的 「Vuex」，裡面 State 的資訊是可以在多個頁面共同使用，下面舉例幾個不夠謹慎會造成的問題：

• 如果在 loading 資料前沒有清空先前的 state 資訊，會導致進入頁面時會閃現上一次進入的資料。
• 如果把第幾頁(page)、分頁筆數(per-page)這些參數在多個頁面共用，那你就會看到有些頁面明明是第一次進入，卻跳轉到其他頁數。

大量存取不必要的 API

這裡舉出兩個常見的例子：

• 登入後就「一次呼叫所有的 API」，但許多 API 回傳的資料可能使用者根本還用不到。

這邊提醒一下，適當的「預載」可以增加使用者體驗，但如果在系統首頁就全部載入，除了會消耗使用者的資源外，一旦大量使用者同時上線，對伺服器端會造成很大的壓力。

• 有些搜尋功能會隨著使用者填入的文字去呼叫 API 來即時顯示搜尋結果或是建議關鍵字（ex：Google），但如果沒有把呼叫 API 的時間間隔設定好（debounceTime），使用者又不停更改搜尋列文字，那就會呼叫非常多不必要的 API。

將用不到程式碼註解而非刪除

在開發階段有時會想到很多的解決方案，因為不確定哪個效能較高，所以就把每個演算法實現出來。

但有些人在決定使用某個解決方案後，依舊沒把其他的方案刪除，這樣的做法容易造成未來維護的困難度。

沒寫註解，或是寫沒有意義的註解

雖然有神人說過：最好的註解就是程式碼本身

但我想：「絕大多數的人都難以到達這個境界，所以要乖乖地寫註解ＸＤ」

let mode = 0;

// do somethings ...

if (mode === 0) {
  // excute logic 1
} else if (mode === 1) {
  // excute logic 2
} else if (mode === 2) {
  // excute logic 3
}

原始碼：bad_remark_example.js（GitHub Gist）

像是上面這段 Code，我們可以知道 mode 這個變數應該是應用在某個狀態的判斷上；但具體在哪個地方使用、總共有哪些狀態、各自代表什麼意義，在沒有註解的狀態下只能一行一行的閱讀，沒辦法第一時間理解程式。

👍 註解的好處

1. 交代前因後果：為什麼這樣寫?遇到了什麼困難?解決了什麼問題?
2. 作為文件說明：有些技術是需要被學習後才能夠看得懂的(ex:引入的模組、套件)，你的註解能讓他快速理解這些工具怎麼使用

🙅 請不要有註解如下

1. 毫無意義的牢騷(ex:我好崩潰啊，這段程式我寫了一個禮拜…)
2. 把註解當成版本控制(ex:2020/08/23 完成此函式)
3. 說明這段程式是誰寫的(簽名檔)
4. 把舊的程式碼註解起來怕以後會用到(但通常再也不會用到，而且這個問題用版控就能解決)

Copy & Paste 後，Function、Variable 命名沒有改

如果寫專案時發現之前做過類似的功能，我們會複製過來再做微調，以此加快開發的速度。

但請修改 Function、Variable 命名！這不會花你太多時間，但在未來當你需要維護專案時，你會感謝現在的自己。

筆者之前曾在幫忙 Debug 時，於Ａ系統裡面看到一堆Ｂ系統的命名，當下還以為自己開錯專案了…

沒有寫 try catch

程式在缺乏 try-catch 的機制下是非常脆弱的，只要發生例外事件就容易崩潰。

如果你直接假定 API 只會回傳正確的資訊，而沒有撰寫 try-catch 去捕捉可能的 400、500 系列錯誤，就很可能導致系統許多行為錯誤如：

1. 跳轉到無權限的頁面
2. 程式進入無限迴圈
3. 瘋狂 Call 某隻 API 直到變成 429 錯誤（Too Many Requests）

在他人協助下完成功能後，沒有真正了解原理

我相信大部分的人都是樂於幫助別人解決問題的，但同時也相信，沒有人希望再次被「相同的問題」打擾。

我這邊強烈建議請他人協助問題前，先 commit 一版，這樣無論對方成功還是失敗，你都有一個記錄在。

如果對方成功解決這個問題，一定找時間回到當時 commit 的那版，用自己的邏輯把功能完成；請記住，別人完成的任務不會自動成為你的知識。

沒有做 Refactoring

演算法相關的 Refactor 有一定的難度，但有一些很基礎的 Refactor 我認為是有必要的，像是變數命名這一塊。

我們先來看一個不好的範例：

let result = responseData;
if (result[result.length - 1]) {
  if ("check_in" in result[result.length - 1] && result[result.length - 1].check_in !== null) {
    state.check_in = result[0].check_in.toString();
  }
}
if (result[result.length - 1]) {
  if ("check_out" in result[result.length - 1] && result[result.length - 1].check_out !== null) {
    state.check_out = result[result.length - 1].check_out.toString();
  }
}

原始碼：need_refactor.js（GitHub Gist）

上面這個是要取得回傳的「最後一筆」資料做邏輯處理，但是全部都使用「result[result.length -1]」來表示，相信大家都會看得有點眼花。

下面我們做個簡單的 Refactor，看起來就會舒服很多：

let result = [];
let last_record = result[result.length - 1];
if (last_record) {
  if ("check_in" in last_record && last_record.check_in !== null) {
    state.check_in = last_record.check_in.toString();
  }
}
if (last_record) {
  if ("check_out" in last_record && last_record.check_out !== null) {
    state.check_out = last_record.check_out.toString();
  }
}

原始碼：after_refactor.js（GitHub Gist）

詢問別人前沒有自己嘗試

有些人在遇到問題時沒有先從網路找資料，而是遇到問題先問同事、前輩。

儘管這樣可以最快速得到解答，但卻少了很多自我思考的部分，長期來講對工程師職涯是非常不健康的。

詢問的問題不夠精確

有時會收到主旨模糊的問題，像是：「這個搜尋功能常常會 fail，可以幫我看看嗎？」

如果可以，收到問題的人會希望問題敘述微調一下：「在人資系統中，我如果在職員列表頁面的搜尋條件中加入部門篩選，會發現搜尋出的結果不合預期，有時會找出其他部門的人員，可以幫我看一下是不是資料庫語法錯誤呢？」

結構為：哪個系統->哪個頁面->你調整了哪些參數->錯誤結果為何->初步判定錯誤來源

管理者權限與使用者權限混在一起

很多系統都會分成前台（一般使用者）以及後台（管理者），有時後端為了增加程式共用率，而讓他們使用同一隻 API 存取資料，如果權限有設計好那沒問題，但如果沒設計好可能就出大包了。

以人資系統來說，假設有一隻 API 是用來存取個人資訊的，API 格式為：「users/{user}」

假使把這隻 API 共用，一般使用者透過修改中間的「user id」就有可能看到其他人的隱私資訊，這在資訊安全上是非常危險的。

因此建議將一般使用者與管理者的 API 切割清楚，避免讓使用者看到權限外的資料。

筆者曾經犯過文章中許多錯誤，沒有人一開始就是強者，但至少要走在變強的道路上。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤(本篇)
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！