開始

我實際上是那種總是會問出愚蠢問題或“不好”問題的大信徒。我一直在問人們一些愚蠢並且完全可以通過谷歌搜尋或搜尋程式碼庫解決的問題。大多數時候我都不願意自己去搜索解決，但有的時候我又會無論如何都自己去搞定，而且也不會認為這如同世界末日一樣可怕。

所以本文中列舉的各個策略不是關於“在提問之前你必須要做的所有事情”，而是“一些可以幫助提出更好的問題並得到我想要的答案的要點！”。

何為好問題？

我們的目標是提出易於回答的關於技術概念方面的問題。我時常碰到知識淵博並且這些知識也是我想知道的人，但他們並不總是知道如何確切地用最佳的方式解釋。

如果有一系列好的問題，那麼就可以幫助解答的人將他們所知道的內容有效地解釋給我聽，並指導他們告訴我我感興趣的東西。那麼我們該如何做到這一點呢？

說明你所知道的

這是我最喜歡的提問技巧之一！提問形式基本上是這樣的：

• 說明到目前為止你對這個話題的理解
• 問“對嗎？”

例如，我最近在和人（一個優秀的問題提問者）談論網路！他們說“所以，我在這裡的理解是有某個遞迴式dns伺服器鏈……”。那是不正確的！實際上沒有遞迴式DNS伺服器鏈。（當你談到遞迴式DNS伺服器時，只涉及一個遞迴式伺服器）因此他們說出他們當前的理解，可以方便我們澄清它實際上的工作原理。

我對rkt很感興趣，但我不明白為什麼rkt在執行容器時會比Docker佔用更多的磁碟空間。

雖然“為什麼rkt比Docker要使用更多的磁碟空間”不怎麼像是正確的問題——我差不多知道程式碼是如何工作的，但我不明白為什麼他們那樣寫程式碼。所以我把這個問題寫到 rkt-dev

我：

• 寫下了我對rkt和Docker如何在磁碟上儲存容器的理解
• 想出了幾個我認為他們可能會按照他們的方式設計的原因
• 問“我的理解對嗎？”

我得到的答案超級超級有幫助，正是我所尋找的。我花了很長時間以一種我滿意的方式制定了這個問題，我很高興我花了時間，因為它使我更好地明白了箇中奧妙。

闡明你的理解並不容易（需要時間思考你所知道的並澄清你的想法），但效果會很好，更方便你要求幫助的人針對性地提出解答。

問答案是事實的問題

我有很多問題一開始有點模糊，如“SQL中的連線查詢JOIN如何工作？”。這個問題不是很棒，因為連線查詢如何工作有很多不同的部分！那麼對方怎麼知道我有興趣學習的是什麼？

我喜歡問那種答案是一個直截了當的事實的問題。例如，在SQL連線查詢示例中，一些事實問題的答案可以是：

• 連線兩個大小為N和M的表的時間複雜度是多少？是O(NM)嗎？還是 O(NlogN)+ O(MlogM)？
• MySQL在進行連線查詢之前是否始終將聯結列排序作為第一步？
• 我知道Hadoop有時會“hash連線”——這是其他資料庫引擎也使用的一個連線策略嗎？
• 當我在一個索引列和一個未索引列之間進行連線時，我需要對非索引列進行排序嗎？

當我問像這樣超級具體的問題時，被問的人並不總是知道答案，但至少他們理解了我感興趣的問題是怎麼樣的——很明顯，我並不想知道如何使用連線查詢，我就是想了解一些實現細節和演算法。

真誠地說出你不明白的地方

很多時候當有人向我解釋某事時，他們會說一些我不明白的東西。例如，可能有人正在向我解釋一些關於資料庫的東西，並說“好的，我們使用MySQL的樂觀鎖，因此……”。等等，我不知道什麼是“樂觀鎖”啊。所以這需要提問了！ : )

阻止某人接著說下去並提問“嘿，那是什麼意思？”是一個超級重要的技能。我認為它是自信的工程師的屬性之一，並且培養起來會大有裨益。我看到很多高階工程師經常要求澄清說明他或她不明白的地方——我覺得當你對自己的技能更有信心時，這更容易。

越是這麼去做，在我要求別人澄清的時候就越是感覺自然。事實上，如果有人在我解釋的時候不要求我澄清，我反而會擔心他們不是真的有在聽！

這也為問題回答者創造了在觸及他們知識領域範圍之外時可以承認的餘地！很多時候，當我問某人問題時，如果問到他們不知道的東西。我問的人通常真的非常善於說“不，我不知道！”

識別你不明白的術語

當我開始當前這份工作時，我首先去了資料團隊。當我看我的新工作需要什麼的時候，有這些要求！Hadoop，Scalding，Hive，Impala，HDFS，zoolander，以及等等。我可能之前聽說過Hadoop，但這些單詞是什麼意思我基本上是兩眼一抹黑。其中一些是內部專案，其中一些是開源專案。所以我從要求幫助我理解每個術語的含義和它們之間的關係開始。我可能會問的一些問題是：

• HDFS是資料庫嗎？（不，它是一個分散式檔案系統）
• Scalding使用Hadoop嗎？（是）
• Hive使用Scalding嗎？（不）

實際上我編寫了一部關於所有術語的“字典”，因為術語實在太多，並且理解所有的術語意味著真正幫助我定位自己，以便於以後提出更好的問題。

做一些研究

在我鍵入上面的SQL問題時，我在Google搜尋框中輸入了“如何實現SQL連線”。我點選了一些連結，看到“哦，我知道了，有時有排序，有時有雜湊連線，以前我聽說過”這些話，然後寫一些我遇到的更具體的問題。首先稍微Google一下，這可以幫助我寫出更好的問題！

也就是說，我認為人們有時對“在沒有谷歌搜尋之前就不要提問題”這一原則太過苛刻——有時我在和某人一起吃午飯的時候，因為對他們的工作好奇，於是我就會問到相關的基本問題。這完全正常！

但是做研究非常有用，並且做足夠的研究以便於提出一系列超讚的問題真的很有意思。

決定去問誰

在這裡我主要談論向你的同事問問題，因為大多數時候我都是向他們求助的。

詢問同事時，我會思考到的一些問題是：

• 是提問的好時機嗎？（如果他們在忙著做一件緊迫的事情，那麼可能就不是好時機）
• 詢問他們解答問題所需要的時間是不是可以節約我儘可能多的時間？（如果我問了一個問題，將花費他們5分鐘回答，卻將節約我2個小時的時間，那就棒棒噠 ： D）
• 他們需要多少時間來回答我的問題？如果我有半小時的問題要問，那麼我可能會之後再安排一段時間，如果我只有一個快速的問題，那麼我很有可能現在就問了。
• 這個人對這個問題而言是否過於太高階了？我認為這是很容易陷入的陷阱，那就是每個問題都去問最有經驗/最有知識的人，而且每個問題的主題還各不相同。但實際上更好的辦法是找一個知識稍微沒那麼淵博的人——通常他們可以回答大部分的問題，擴散負荷，而且他們還可以展示他們的知識（哈哈）。

我不總能做好這些事情，但考慮這些確實於我有所幫助。

此外，我通常會更多地去問更靠近問題的人——幾乎每天我都會與之談論的人，一般說來我更很傾向於去問他們問題，因為他們更瞭解我的工作背景，從而給我一個有用的答案。

《How to ask questions the smart way by ESR》是一個流行和相當有敵意的文件（它的開頭陳述很爛，如‘我們稱呼這樣的人為“失敗者”’）。內容關於如何在網際網路上向陌生人提問。向網際網路上的陌生人問問題是一個超級有用的技能，可以讓你獲取真正有用的資訊，但這也是一類“硬模式”的問題。因為與你對話的人對你的情況知之甚微，所以更仔細地陳述你確切想要知道什麼更佳。我不喜歡ESR文件，但它確實說明了一些有用的東西。文章的“How To Answer Questions in a Helpful Way”部分還是挺不錯的。

提出問題以顯示不明顯的內容

更高階的問題提問形式是提出問題以揭示隱藏的假設或知識。這種問題實際上有兩個目的——第一，得到答案（可能這個人知道但其他人不知道的資訊），但也要指出，這裡有一些隱藏的資訊，並且共享這些資訊是有用的。

Etsy的“Debriefing Facilitation Guide”中的“The Art of Asking Questions”部分就是在討論已發生事件的背景下的一個非常好的入門介紹。以下是從該指南摘錄的幾個問題：

• “當你懷疑這種型別的失敗發生時，你想要尋找什麼？”
• “你怎麼判定這種情況是‘正常’的？”
• 你是怎麼知道資料庫崩潰的？
• 你怎麼知道那是你需要page的團隊？

這些類似的問題（看起來很基本，但實際上並不明顯）在某些權威人士提問的時候特別強大。我特別願意看到經理/高階工程師問及這類基本但重要的問題，如“你是怎麼知道資料庫崩潰的？”，因為它為水平較低的人創造了以後提問相同問題的空間。

回答問題

André Arko的“How to Contribute to Open Source”裡面有部分是我非常欣賞的

既然你已閱讀了所有要點並pull請求，那麼就開始檢視你可以回答的問題。如果問題你以前就回答過，或者你剛剛閱讀的文件就可以解答，那麼用不了多少時間你就能發現這一點。回答你知道怎麼回答的問題。

如果你正在攀登一個新專案，那麼回答那些正在學習你剛學完的那些內容的人的問題，可謂是鞏固知識的好方法。每當我第一次回答關於一個新主題的問題時，我總是會有一種“OMG，要是我答錯了該怎麼辦啊，OMG”的感覺。但通常我都可以正確回答他們的問題，然後我就會感覺自己棒棒噠，好像自己更好地理解了主題！

問題也是巨大的貢獻

好的問題可以為社群做出巨大的貢獻！我回答了一些關於CDN的問題，並在 CDNs aren’t just for caching寫出了答案。很多人告訴我，他們真的很喜歡這篇博文，我認為我問的這些問題幫助了很多人，不僅僅惠及自己。

很多人表示自己很喜歡回答問題！我認為將好的問題當作一件你可以做的超棒的事情，並放到對話中是很重要的，而不要只是認為“問好的問題，這樣人們才只會稍微惱火，而不會非常非常惱火”。