初次見面。我是在 PRUM 株式會社擔任工程師的 すもも🍑。
我會每天整理並分享在程式學習與實務中，容易卡關的重點，以及思考方式。
如果你對 PRUM 有興趣，也歡迎看看我們的企業網站。
▶企業網站
有在想錯誤處理原因嗎？你是直接複製貼上問 AI 吧！
每次出現錯誤時，是不是都沒有好好讀訊息，就直接問 AI「這個錯誤的原因是什麼？」然後把 AI 的答案原封不動地複製貼上呢。
「反正問 AI 比較快，這樣也沒差吧？」新人時期，我也一樣。因為看了還是沒什麼頭緒，所以總是依賴 AI 或搜尋引擎，然後直接拿看起來差不多的答案去試。
如果公司允許，為了調查錯誤原因而活用 AI，本身並不是壞事。
不過，如果每次都只靠這樣處理，效率其實不高，而且 AI 也可能判斷錯原因。至少，我認為應該先具備能自己讀懂錯誤訊息的基本理解能力。
其實，IT 業界所需要的「理解能力」很特殊
說到底，錯誤訊息之所以難讀，不是因為你沒有理解力。
因為它是英文，裡面還混著程式語言特有的表達方式，加上半形和全形、單引號和雙引號這種平常生活中幾乎不會注意到的細節也必須看出來。這和一般所說的「理解能力」不是同一種技能。
就算平常很常讀書的人，也沒有人一開始就能習慣這種特殊的閱讀方式。
具體來說，該看什麼
閱讀錯誤訊息時，首先想抓住的線索有以下 3 點：
- 錯誤的種類（是 SyntaxError 還是 TypeError）
- 發生在哪個檔案的第幾行
- 預期的是什麼，實際傳入的是什麼
例如，如果訊息是「cannot read property 'x' of undefined」，即使沒有專業知識，也至少可以抓到「正在對 undefined 讀取 x」這條線索。
像半形和全形、引號種類這類細節，一開始你可能會覺得「連這個都要看嗎？」但習慣之後，眼睛自然就會停在這些地方。
所以想鍛鍊的，是「在問 AI 之前先抓線索」的習慣
「先自己思考並建立假設」這種說法，其實門檻很高。因為在還沒有任何規格知識的情況下，不可能光靠閱讀就自動浮現假設。
比較實際的做法是，先從錯誤訊息中抓出具體線索，再去問 AI 或搜尋。
先抓線索再去問，問題或搜尋的精準度本身也會提升。你不會再問「幫我修這個錯誤」，而是能像「出現 TypeError，顯示 cannot read property of undefined，原因是什麼？」這樣，帶著抓到的線索來提問。
而且，當你反覆做這個「抓線索」的動作時，規格知識本身也會在之後自然累積起來。不是因為有理解力才懂規格，而是因為養成抓線索的習慣，結果才會連帶理解規格，順序是這樣的。
這不只限於 IT 業界。
- 做料理時，透過每次觀察「為什麼會焦掉」「為什麼沒膨起來」這些結果，火候與份量的感覺會自然養成
- 學語言時，針對每次聽不懂的說法去查、去記，久而久之即使不刻意思考文法也能自然使用
- 做運動時，持續吸收對姿勢哪裡歪掉的指正，正確動作的感覺就會慢慢刻進身體裡
錯誤訊息也是一樣。持續抓住「為什麼會出現這個線索」，最後就會連到理解規格的「感覺」。
總結
錯誤訊息之所以難讀，不是理解能力有問題，而是本來就需要一種特殊的閱讀方式。
問 AI 本身沒有不好。不過，在問之前，先試著從錯誤訊息裡抓出線索。這個小小的動作，之後會慢慢連結成理解規格的能力。
也就是說，錯誤訊息不是因為看不懂就可怕，而是只要抓住線索，就會一點一點變得能讀懂的東西。
PRUM 的工程師多數都是從沒有經驗開始錄用的。
如果可以，也歡迎來企業網站逛逛。
▶ PRUM 招募頁面
我們也經營著整理給工程師看的實用文章網站。如果有興趣，也歡迎看看。
▶ 對工程師有幫助的文章網站
原文出處：https://qiita.com/prum_sumomo/items/535a697aeaea41515de9
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
