實習的最後兩個月，我在從零建一套 API 壓力測試框架，用 k6。
建到一半卡住了。
有一個 endpoint 要求把送出去的一段資料先加密。而當時的 k6 沒有對應的函式庫可以做這件事。
我那時候很想把它解開。
查文件、翻 GitHub issue、看有沒有人用 pure JavaScript 手刻過、試著把加密那段塞進 k6 的執行環境裡。
我記得那種感覺：我如果解開了，這個框架就是我一個人完成的。
第二天下午，我停了。
我去找主管，跟他說這件事在 k6 裡面做不出來，我查到哪些、試過什麼、為什麼認為此路不通。
當下我覺得那是認輸。
不是因為結果好，是因為兩天是對的長度。
實習生最常見的失誤不是解不開問題，是解不開卻不講。想證明自己，於是燒掉一整個禮拜，最後還是解不開，只是時程被拖掉了，而且拖掉的那一週沒有任何人知道。
停損的判準我後來想清楚了，是這句話：我現在學到的東西，還在增加嗎？
第一天我每小時都在學到新的東西——原來 k6 的執行環境是這樣、原來這個模組載不進去。第二天下午，我開始重複試同一類的東西，換了語法、換了寫法，但學到的東西不再增加了。
那就是該停的點。不是因為累了，是因為繼續投入不會產生新的資訊。
這件事我後來才意識到它的份量。
我跟主管講的不是「我做不到」。
我講的是「這件事在 k6 裡做不到」。
這兩句話聽起來差不多，資訊量差很遠：
| 我說的話 | 對方能做什麼 |
|---|---|
| 「我做不到」 | 換人試試看、或者再給你一點時間 |
| 「這件事在 k6 裡做不到，因為 A、B、C」 | 往 k6 以外的方向找 |
第一句是關於我的。第二句是關於這個工具的邊界。
而只有第二句，才能讓下一個人往對的方向走。
這跟 Day 2 那三句話是同一件事：把自己的邊界講清楚，對方才拿得到可以用的東西。
另一位 RD 找到了做法，而且那個做法讓我愣了一下。
他沒有去造輪子，也沒有想辦法讓 k6 學會加密。
他換了工序：先用 Node.js 把加密過的測試資料生出來，再讓 k6 拿著那份現成的資料去打 API。
問題從「k6 能不能加密」變成「k6 需不需要自己加密」。
答案是不需要。加密那件事根本不必發生在壓測的當下。
我卡在那裡一天半，是因為我預設了「這件事必須在 k6 裡面完成」。那個預設從來沒有被我拿出來檢查過。
我到現在還是會說：那個問題不是我解決的。
而且用 Day 6 的三個計分條件去對，它完全不及格——沒有可歸屬的成果、沒有一個屬於我的結束點、也沒有第二個人會記得那兩天是我擋下來的。
但我現在知道那兩天值多少。
如果我沒有那一天半，沒有人知道 k6 這條路不通，那個框架會一直卡著。我交出去的不是一個解法，是一份排除掉的可能性，還有一份夠清楚的邊界說明。
排除法也是進度。只是它從來不會出現在任何一張表上。
卡住的時候，往上報之前先做一件事：把「我做不到」改寫成——
「這件事在 ＿＿＿ 的條件下做不出來，因為 ＿＿＿。我試過 ＿＿＿。」
同樣是求助，第二種讓對方接得住。
還有，先問自己：我這一小時學到的東西，還在增加嗎？沒有的話，時間到了。
明天是第二週回顧。
iThome鐵人賽
看影片追技術