來聊聊那些非常欠人教訓的提問 & 發問

前言

身為一名工程師在開發上遇到問題並發問是一件非常常見的事情，但是許多人都會忽略所謂的「提問的智慧」，但是「該如何提問」卻又是一門學問甚至可以說是技能，當然更不用說有些人的提問方式真的真的非常欠人教訓以及翻白眼，所以今天就來分享一篇該如何提問會比較合適。

搜尋技巧

在你發問之前請務必先做一個動作，也就是 Google，只要你有先做這個動作，基本上你是不會被人家幹譙問候。

絕大部分你想問的問題有七到八成可以在 Google 中找到，所以也有人戲稱當今世代的工程師是 Google 工程師 (完全不反對)。

其實這並不是沒有原因的，畢竟現在是一個資訊大爆炸的時代，許多問題真的可以在 Google 找到，只是你可能不知道該如何搜尋而已。

當你問題找不到的時候，可以嘗試以下我所提供的關鍵字搜尋技巧來調整你的 問題關鍵字，或許你就可以找到你想要的答案：

• 調整關鍵字的順序，有時候將關鍵字交換放就可以得到不同的結果。
  • ex: RE：從零開始的學習生活 JS 變成 RE：從零開始的學習 JS 生活 (置入性行銷)。
• 刪減關鍵字數量。
  • ex：ThinkPHP 基礎學習 變成 ThinkPHP 基礎。
• 改用英文搜尋，許多工程師的知識在英文領域是比較多的，如果你英文跟我一樣不好，那麼我會建議你善用工具，也就是 Google 翻譯小姐，多善用身邊所擁有的工具將中文翻譯成英文。
• 善用 site:特定網站網址 + 關鍵字，透過 site: 可以將問題聚焦在特定網站(我最常聚焦在 Stack Overflow)。
• 關鍵字前後加上「"」，這樣查詢到的內容就會比較聚焦於你要的關鍵字，否則關鍵字有可能會被拆開搜尋。
  • ex: 「"JavaScript"」。
• 關鍵字加上「-」，可以排除特定的內容。
  • ex:「PHP -基礎教學」。
• 善用萬用符號的關鍵字「*」，使用可以取代你不確定的關鍵字。
  • ex:「PHP *路徑」。
• 使用年份範圍來查詢「關鍵字 年.. 年」。
  • ex:「it 邦幫忙 2016.. 2018」。
• 關鍵字搭配特定網域搜尋的技巧。
  • ex:「JS 傳參考 site:https://israynotarray.com/」

以上只是我列出來的其中一些搜尋技巧，相信你若善用以上搜尋技巧，許多問題應該是可以不用發問詢問他人的，你也不用擔心自己發問的方式正不正確，甚至沒人回覆你搞得自己像邊緣人一樣(唉?)。

良好的發問開頭

許多新手工程師在提問的時候都會忽略的這個最基本的根本重點，首先先來講講何謂 好的開頭，在你的問題開頭適當的帶入自己的經歷介紹是一個好的開始：

各位好~
小弟我是一名剛入門約 XX 月的初學者，目前對於 CSS&HTML 有一點疑問想請教...

首先先聊聊為什麼這樣子稱之為好的開始，你可能會覺得上面的開頭並沒有描述你學了哪些、理解了哪些，但是通常一個正常人的發問上，是很難完整描述你理解了哪些，因此我會建議 以你已經學了多久的經歷 來去讓人家了解你的程度大約在哪裡，舉例來講如果你學 JavaScript 已經有三年了，那麼解題者自然就會知道你的程度至少是在哪裡，畢竟你都可以學 JavaScript 三年對吧？

所以說在提問之前的開頭適當地提出自己的學習經歷，是有助於幫助他人知道你是 什麼樣程度的人，這個開頭介紹將會大大影響你 得到什麼樣的解答，假使今天你發問時，你並沒有特別告知你的學習經歷，單純只是說明你有疑問 ↓

各位好~
目前對於 CSS&HTML 有一點疑問想請教...

通常你會得到許多人給予的建議，但是你可能會發現一件事情，有些人給的建議太難，甚至沒有範本，只給你方向跟概念。 (出張嘴寫 Code 概念。)

原因是為什麼？因為你並沒有告知他們你目前的程度到哪裡，所以這些善心人士就會認為你的程度與他們的程度 是相同的，那麼為了避免這個狀況發生，我會建議你 請務必要告知他人你的程度範圍在哪裡，這樣可以確保你的問題 更快速更聚焦的 得到你可以吸收的解答絕對不會是出一張嘴寫 Code 的概念。

你再往下看之前，我們這邊先暫停小聊一下吧。

請你試著思考一下，我跟你是一個素未謀面的陌生人，或許你認識我，但我並不認識此時此刻在閱讀這一篇文章的你，假使你沒有在提問的開頭告知我你的暱稱、經歷以及學習程度，那…當你問我問題的時候，我又該如何用什麼樣的角度去給你解答以及當下我又是否該寫一個 Example 給你參考呢？除非你真的很希望我出一張嘴寫 Code 這樣也是可以的(煙)。

最後如果你真的是一名新手工程師甚至是剛轉職的人，在問題串中適當地附上你 Google 了哪些資料以及告知你的程度，通常來講願意回覆你問題的人就會比較友善許多，畢竟你已經嘗試自己去尋找過解答，但真的還是不懂才會提起勇氣發問，基本上你是不會遇到所謂的ㄐㄅ人(消音失敗)。

謹慎選擇的發問地點

假使你跟我一樣是一名前端工程師(如果你是其他領域的專業也可以參考，因為我只是拿我自己做範本舉例。)，而你今天有一些前端的問題想詢問，但你卻在 PHP、Python 或是 C++ 等社群以及論壇發問，那麼你的問題就有 90% 的機率被忽略甚至是被 Bad 掉，其中 10% 呢?大概就是得到以下這些回覆

「連自己該在哪裡發問都不清楚是 87 嗎?」

「請自己乖乖到前端社群發問好嗎?」

如果你是屬於有被虐傾向的 M 屬性，那我還真的不知道該說什麼。

所以發問之前請務必把握兩個重點原則

• 請不要在與你主題不符合的地方發表問題
  • ex：Python 問題跑去 Ruby 社群。
• 請注意你準備發表問題的社群人們是屬於哪一種等級的人
  • ex：新手問題跑去黑客社群。

通常我比較常看到有人在新手社群問進階的問題，你可以想想看，你在一個充滿新手的地方詢問中高階問題，你怎麼能保證你的問題不會被忽略呢？是不是問題被忽略的機率估計是 87% 高呢？剩下的解答機率可能就是本身深潛在此的大神們好心替你解答，所以基本上你是幾乎不可能得到解答的，請不要挑戰不可能的任務好嗎？你又不是阿湯哥

除此之外有一次我在逛論壇時就有看到有人在 React 論壇詢問 Vue 的問題(這不是欠教訓嗎?)。

基本上你可以透過一些狀況來觀察這個人在這個地方發問的方式恰不恰當，以 Facebook 社群來講，這個人若在錯誤的地方發表問題通常會有以下幾個狀況：

• 表情數量少。
  • 額外提一下，有些人按讚的意思是已讀。
• 無人給答案。
• 問題很快就沉落谷底。
• 一大推幹譙文

所以謹慎的選擇發問的地點是有助加快你的問題可以被快速地被解答以及減少被幹樵機會。

發問前的一些調整

在發問之前你必須先調整自己的心態，你必須清楚明白一件事情 你不能要求所有人都一定要回覆你的問題 甚至是 問題能夠被立刻、即時並迅速地解決，就像我前面講的「我跟你是一個素未謀面的陌生人」，那麼我有什麼義務要浪費自己的時間回覆你呢？畢竟幫你解答的這段時間我可以去打一下刺客教條(咦?)。

就跟尤雨溪 (Vue.js 創辦者) 曾說過：

為什麼我要犧牲陪老婆孩子的時間來替你省下學習英文的時間呢？

(以上出處在此)

這邊也列出一些發問時也要注意幾個重點。

問題不要有錯字

拜託！問題內容中有錯字是一件蠢到不能再蠢的事情，假使你今天希望別人能夠幫你解答你的問題，但你的問題內容卻滿滿的錯字、火星文以及注音文等等，這不就代表著「我邊看你問題時還要幫你糾正國字嗎？」，此時我可能還會替你的國文老師感到難過。

這個問提我...

這ㄍ問提偶...

如果你真的犯了這個蠢到爆炸的錯誤，相信你的討論串底下應該大部分都是這種戰況

「建議你先回去讀國文」

「你國文老師替你感到難過」

「等你修正錯字我再來回你」

「我懷疑我的國文是不是沒學好」

以上林林總總…

通常你只要不是太誇張的錯字，基本上不會有人這樣回你的，畢竟我們的輸入法有時會將「再」與「在」傻傻分不清楚。

明確的問題以及開頭

許多人在發問的開頭都很喜歡加上「#求解」、「#救命」、「#我不會」、「#我不懂」還是「#在線等」，基本上如果讓我看到這幾個字眼，我大概就會直接下意識忽略你的問題，因為這幾個字都是 禁忌，非必要的開頭是無法讓人家想幫助你，只會讓人家覺得很智障。

明確的開頭可以讓人家快速地進入你的問題狀況中，若是使用以上這些禁忌字眼，許多前輩真的都會果斷 忽略 你的問題唷！

以我自己來講，我也非常討厭看到這幾個字眼，原因很簡單，我再幫你解答時就是要直接知道你的「程度在哪」、「問題在哪」，絕對不是看你在那邊亂哀嚎一通，而且不明確的開頭無法有助於你的問題被搜尋。

清楚描述你的邏輯以及過程

除了上面提到的「#求解」、「#救命」、「#我不會」、「#我不懂」以及「#在線等」等字眼，不可以出現在問題內容中之外，你也必須清楚 詳細的描述你的程式碼邏輯，如果你不清楚的話，我會這樣建議您條列你的問題：

• 提供原始碼
• 覺得有問題的檔案以及行數
• 你預期結果會出現什麼
• 但實際結果是什麼
• 你已經嘗試過哪些以及搜尋過哪些資料
• 你理解之後又是如何

除了這些之外的內容「通通不要有」，我是認真的。

(當你提供了上述描述之後，發現對方還是無法釐清你的需求時，你可以試著補充情境給予對方思考，你要知道 情境 也是非常重要的。)

在 提問的智慧 中就有提到多餘且無意義的提問句是會讓其他人認為你是在藐視他。

以下擷取提問的智慧精華片段：

避免用無意義的話結束提問，例如有人能幫我嗎？或者這有答案嗎？。
首先：如果你對問題的描述不是很好，這樣問更是畫蛇添足。
其次：由於這樣問是畫蛇添足，黑客們會很厭煩你──而且通常會用邏輯上正確，但毫無意義的回答來表示他們的蔑視， 例如：沒錯，有人能幫你或者不，沒答案。
一般來說，避免用 是或否、對或錯、有或沒有類型的問句，除非你想得到是或否類型的回答。

這邊你也要注意到一件事情，你的第一次提問可能會有許多人不懂意思，除非你已經是一個經驗豐富的提問者，可以非常明確的描述出你的需求與問題，否則你必須抱持著要額外補充說明的行為。

盡可能不要使用截圖提供程式碼

截圖提供錯誤訊息是一個相當正常的行為，畢竟當你提供了原始碼之後，我們還原你的專案之後卻沒有發現任何錯誤時，那麼你的截圖就會是一個關鍵點，畢竟每一個人的開發環境都不同。

但是這邊請注意，請不要將覺得有問題的地方用截圖的方式當作你的提問方式，這是一個 非常蠢 的行為。

因為往往我們許多的問題並不是在你 認知 的範圍內，可能就這麼湊巧你的關鍵點錯誤點就在截圖之外，所以再一次說明 「請不要使用截圖的方式提供你的程式碼」，如果是提供你的錯誤訊息與錯誤畫面，那麼這是可以的，這兩件事情完全是可以區分開來講的。

所以這邊的重點是 「請不要使用截圖的方式提供你的程式碼」，可以看到我在一次的強調這件事情，最主要原因就是太多人犯這種錯了！所以我相信此時閱讀這一篇的人，一定希望可以培養良好的發問，那麼這一點真的不要犯。

除此之外不建議使用截圖方式提供原始碼的原因還有另一個原因，假使你今天身為一個幫忙解決問題的人，你會期望對方提供的程式碼是可以給你複製貼上運作的呢？還是你要依照他圖片再複製打一次還原一次呢？相信你應該會希望對方給你的程式碼你可以立刻馬上或者複製貼上到自己的開發環境運作一次，而不是看著對方圖片照打，畢竟過程可能我們會漏打字，那這樣子問題可能沒辦法解決，反而會出現其他問題。

所以最後再強調一次 「請不要使用截圖的方式提供你的程式碼」，如果是提供錯誤訊息與錯誤畫面是可以的。

避免使用手機拍照提供錯誤訊息

注意！這一個注意事項是提供錯誤訊息而不是範例程式碼！！

不要把「盡可能不要使用截圖提供程式碼」這一個小節與「避免使用手機拍照提供錯誤訊息」這一個小節混淆了，這是在講兩碼子事情！！

你應該要避免使用手機拍照提供錯誤訊息，因為通常手機拍出來的結果會隨著你的手機畫素、角度以及清晰度有所影響，下方就是一個非常不良的示範

好吧，這時候你應該會想說…

這個圖片怎麼了？很清楚啊！

拜託，我這一張照片已經算是刻意拍好看一點了，如果你今天手機畫素低、角度又差不然就是數位防手震壞掉，那畫面的程式碼簡直差到極致更不用說你可能沒拍到重點呢！

你可以看一下下方這一張使用電腦截圖的方式跟手機拍照的差異在哪裡

如果你這樣子還看不出差異，我真的只會貼給你這一張圖

如果你堅持不使用電腦截圖的話，或許我會請你先去學攝影課或者購入更好的手機或相機，不然就好好學習使用截圖提供錯誤訊息。

而這邊我也提供一篇「不會電腦截圖？我教你！Windows 與 Mac 一次學會」文章讓你學著如何使用自己電腦內建的截圖。

除了貼程式碼，你還有另一個選擇線上編輯器

除了前面提到的 避免使用手機拍照提供錯誤訊息 之外，也請你盡可能使用線上編輯器。

為什麼會建議你盡可能使用線上編輯器呢？你試想一個問題，你想提問的程式碼都是超級無敵的長，然後你將有問題的程式碼貼在社群、通訊軟體上，難道你不覺得有夠難讀的嗎？

我自己就覺得有夠難讀，平常當工程師就已經有夠傷眼了，還要看一個沒有 highlight (程式碼上色、程式碼高亮）結構又長又亂的程式碼，光這一點我就完全不會想認真看，反而會叫你考慮用一下線上編譯器。

通常如果你犯這個錯的話，基本上你會很常看到很多人這樣回你

你可以用線上編譯器嗎？

我閱讀的很辛苦

這時候你就應該要意識到你現在提問的方式真的很欠扁！

如果你不知道有哪些線上編輯器的話，我誠心推薦給你我的兩篇文章

• 十分鐘快速入門上手 CodePen（有中文翻譯）
• 十分鐘快速入門上手 CodeSandbox (有中文翻譯)

使用線上編譯器也是在還原你本身發生的錯誤，這樣子也可以讓你的問題更快更聚焦的被解決。

即使很急也不應提到很急

這也是我非常常見的狀況：

關於這個問題我很急...

基本上我看到這些很急的，我就會選擇忽略，因為你必須明白一件事情「這是你自己的問題並不是我的問題，我沒有義務當下立刻幫你解決」，幫你解決問題我並不會因此賺更多。

另外你也真的不用講到什麼「#在線等」，如果我看到的話，我真的會讓你在線等到天荒地老。

作業不要當作問題問

千萬不要抱著把作業丟到社群也不會被發現的心態去提問，社群上非常多高手、黑客，他們一眼就可以知道你的這個問題是不是作業，你要知道一件事情 作業 是你必須自己搞定的，你一定可以透過作業得到什麼、學到什麼，當然並不是跟你說完全不能將作業的問題當作問題提問，只是你必須統整過一次哪邊觀念不清楚，這時候你所提出的問題應是在問觀念，而不是問 怎麼做，這兩者是有非常大的差異。

如果作業真得太難，我也會建議你應該是先去找出題的老師，而不是將問題丟到網路上任由大海漂賭一個誰會撿到瓶中信的概念。

禮多人不怪，禮多人答覆快

你越是有禮貌，基本上你就不會遇到什麼奇怪的人甚至一些謾罵。

但是許多人在問題得到解答後都不會去主動感謝他人，這是一件非常嚴重的事情，你必須清楚知道一件事情，大家都是免費花時間替你解答解惑，甚至為了找出一套你可以理解的話語以及撰寫 Example 來讓你可以吸收而花了不少時間，而你在得到解答後，你卻不願回一句「謝謝你/妳」、「謝謝你的幫助」、「謝謝解惑~」並附上你解答得過程，那麼下一次當你發問時，你會發現你的問題會完全沒有人願意回覆，甚至問題與第一次發問相比，你的問題的回覆會變得非常慢。

畢竟免費的最貴。

把握時間

發問時盡可能要去把握任何一點一滴的時間，你必須清楚一件事情，每一位陌生人他們都有自己的時間規劃，他們替你解答的過程中，原本的時間規劃可能是洗澡、吃飯或者是陪伴家人等等，但他們為了替你解答而犧牲這些時間，你要知道他們這樣子的犧牲或許會引來家庭革命(我認真的，不信可以看這一篇。)。

所以他們不可能是屬於你的專屬老師甚至隨時隨地教你寫程式，如果你讓問題來回兩三次之後才讓對方明白你的問題狀況，那麼你極有可能必須花上數十小時甚至數天才能夠得到答案，所以請盡可能的一次性將問題寫好並送出，問題越詳細越好。

通常來講我最常遇到這種狀況將問題發送給我：

Ray 我有點問題。

然後呢？沒有然後了。

接下來我發現這個問題的時候已經過了兩三天，此時我一定會回覆「你有什麼問題？」，接下來你又花了兩三天才注意到我的回覆，那麼等到我幫你解決問題的時候，大概已經快一個月了，所以當你請求他人給予解答甚至幫助時，請一次性且完整詳細的告知，除非你真的時間多到爆炸，甚至可以跟哆啦 x 夢一樣拿出時間暫停道具，那我就真的沒話說了(煙)。

雖然開頭先禮貌並打招呼並不是不好，畢竟有求於他人

助教你好

助教，不好意思打擾一下，我有問題請教你

如果你是害怕不禮貌的話，我會建議你修改成以下

助教，不好意思打擾一下，我有問題請教你
主要是關於 Vue3 部署到 GitHub 設置上出現一些問題，我已經有嘗試...

這樣子發送訊息會遠比你只發一段禮貌訊息會更好更快得到解答，而且也不會有失禮貌的問題。

還有一件事情很重要，就是不要一個問題分了好幾段話發送，這樣真的很過度干擾，例如…

助教，不好意思打擾一下...

我有問題請教你

主要是關於 Vue3 部署到 GitHub 設置上出現一些問題

我已經有嘗試...

我會建議你把要講的話一次打完，因為我自己也不是很喜歡一直收到通知，畢竟平常公司的通知就非常多了，不要再讓我的手機變成筋膜按摩機。

得到解答的回覆技巧

oh！這是一個非常重要的技巧，當你的問題得到解答時，難道你就這樣回嗎？

感謝我懂了！

謝謝 xxx 大大！

千萬不要做這種事情，拜託真的不要。

因為這樣子不但讓人覺得隨便之外，也會讓人感覺你是在當 伸手牌，比較正確的回覆方式是你要去吸收這些解答者給予的解答，然後重新歸納整理後自己再描述一次，而不是單純的只是說 謝謝大大，我知道感謝他人很重要，但是比起感謝他人，我會更期望你試著去描述一下你吸收之後得結果，這樣子我們才能夠確切的知道你的觀念到底是不是真的吸收且正確，你說是吧？

最後請記得，得到解答的那個討論串請務必註記「已解答」，這樣子其他人看到時，才不會誤以為你的問題還沒有被解決唷。

回顧問題

最後你都已經耐心看到結尾了，那麼我也會希望你可以試著思考一下自己以往的提問方式是不是有不好的地方，畢竟不論是你找到這一篇文章又或者是人家貼給你這一篇文章，你一定是希望你的提問可以更好更棒或者是期望你的問題可以得到更快的解決。

因此我會建議你可以在得到問題的解答之後，將那一個問題整理成一篇文章寫在自己的筆記或者是部落格中公開分享出去，未來若有一天有人問了相同或是類似的問題，他也可以透過 Google 搜尋到你的那一篇文章進而幫助到他，這樣子才是一個良性的循環。

因此正確的提問應是一來一往的，而不是單方面的給予，這樣並不是好的提問，如果未來看到有人問與你當初相同的問題，我也會希望你試著去回覆他，當你試著回覆他人時，也就代表著 你已經真的學會了。

延伸閱讀

最後這邊我想推薦幾個延伸閱讀，我非常推薦此時此刻閱讀的你去閱讀底下的文章，因為這些都是很常見且很容易被忽略的基本，最後我希望這一篇的經驗分享對你會有幫助。

• 提問的智慧
• 提問的智慧 - 六角學院線上問答
• 軟體工程師必學的文字對話藝術