如何通過提問成為更好的開發人員

這是新的一年的開始，所以我想以一篇我已經計劃寫了一段時間但從未真正開始創作的帖子開始。我最近開始了一份新工作，加入Elastic^[1]，負責開發他們的 .NET 語言客戶端。因此，最終將這個主題編寫并發表是合適的。結果證明這是我較長的帖子之一，因為我有很多話想說。我建議拿起一杯茶或咖啡，坐下來閱讀這篇文章！

提出問題是一種積極的行動

在我作為軟件工程師的這些年里，我問了很多問題。開發人員也向我提出了他們自己的問題。有時，這些對話的開頭是“抱歉，在這么簡單的事情上浪費了你的時間……”。在這篇文章中，我想闡明為什么沒有開發人員，無論是新的還是有經驗的，都應該道歉或回避提問。它們是構建您自己的體驗并成為更好的開發人員的關鍵部分。

有幾乎無限量的知識需要學習。沒有一個人可以知道一切。在軟件開發方面，我們的行業發展非常迅速。最新的新技術很快就會被其他東西所取代。曾經首選的架構風格已經過時或被高級模式所取代。在這方面，所有軟件開發人員都面臨著試圖跟上步伐的相同挑戰。老實說，要真正跟上一切是不可能的。

當然，一種解決方案是找到單一的技術和編碼模式，然后堅持使用。這在變革步伐通常較慢的大型企業中并不少見。盡管如此，相信企業中的每個人都可以了解有關其現有開發環境的一切是不切實際的。它也不能避免相關技術和工具的變化。也許您使用了源代碼控制產品或規劃工具，它們會隨著時間的推移而發展，從而迫使您進行一定程度的學習和適應。出于安全考慮，曾經首選的 API 可能會被棄用，迫使開發人員理解和使用更安全的替代方案。

軟件開發是一門手藝，就像任何手藝一樣，在此過程中需要做出個人風格和選擇。懷疑您編寫的代碼是否是解決問題的“最佳”方式以及您想征求他人意見的想法是完全合理的。

也許您是在即將開始您的第一份軟件開發工作時閱讀本文的。如果是這樣，恭喜！或者也許你在去年開始了一份新工作。我的主要建議是不要害怕提問，不要覺得這會讓你成為一個更糟糕的開發人員。我很樂意爭辯說，我認為有疑問的人在某些方面是更好的開發人員。它表明您對自己的工作感興趣，愿意學習并熱衷于改進。沒有什么不妥！

對于更有經驗的開發人員；從那些有幾年在職經驗的人到那些已經編碼了幾十年的人，你應該仍然有問題。我觀察到長期開發人員害怕提問的情況，甚至可能比初級開發人員更害怕。可能有很多因素在起作用，但在某種程度上，我懷疑這是某種程度的冒名頂替綜合癥。更高級的開發人員可能不希望在軟件開發的某些方面顯得天真。也許他們認為他們應該知道一些事情，并且害怕透露他們不知道。這可能非常危險，因為那些開發人員可能更愿意猜測，而不是真正了解選擇是好是壞。對于閱讀這篇文章的高級開發人員，我現在問你，你還記得你上次在工作中問技術問題是什么時候嗎？你上周提出了多少問題？如果您很難回答這些問題，那么您可能下意識地避免提問。

高級開發人員也會換工作，雖然您可能擔任高級職位，但可以合理地假設您在為新雇主工作的最初幾周和幾個月內會遇到很多問題。您可能不確定為什么要使用特定方法、首選特定模式或特定代碼段的作用。在這種情況下，詢問應該沒有什么問題。如果雇主和經理對這些問題不以為然，那么他們可能不是最好的雇主。假設所有新的高級員工都會在第一天就知道一切，這是不合理和不切實際的。

作為開發人員，您的問題不必局限于純粹與代碼相關的主題。您可能想知道為什么要使用特定的計劃流程，如何平衡您的時間或如何提交費用報銷。這些也是提出問題的完全合理的話題。

如果你已經讀到這里，你現在應該已經學會了，我想鼓勵大家提出問題。因為正是提出問題的行為推動了我們的知識進步。

準備提問

必須首先說明并非所有問題都必須親自提出。對于大多數問題，我建議您首先嘗試自己回答問題。我的意思是，在線、在公司 wiki 或參考材料和文檔中研究問題。您很少會是第一個提出特定問題的人，因此獲得答案的最快方法通常是先向 Google 或 Bing 尋求答案。谷歌搜索還在問一個問題！

如果您的問題是關于您試圖理解的某些代碼，請給自己時間正確閱讀（并重新閱讀）代碼。此外，請確保您查看所有測試。某些代碼可能非常復雜，尤其是在大型遺留代碼庫中。雖然代碼本身可能難以解釋，但測試（如果存在）可以幫助您了解它的意圖。閱讀和解釋代碼是軟件開發人員掌握的一項基本技能，我之前曾在博客中介紹過^[2]。任何實踐這一點的機會都應該被擁抱。如果您在嘗試自己收集代碼的作用后仍然需要尋求他人的幫助，那也沒關系，但請先從那里開始。

如果您的問題是關于為什么您編寫的某些代碼失敗或導致異常，請在與其他人接觸之前花一點時間嘗試隔離和理解問題。檢查您的代碼是否有可能是原因的錯誤。您是否編寫了任何測試，這是否有助于證明代碼的哪一部分是罪魁禍首？您是否已調試應用程序以追蹤出現問題的地方？您是否嘗試在較小的樣本中重現錯誤？這些技術是一個很好的練習。同樣，這里的想法不是避免提出問題，只是為了確保您的問題無法在您自己的腦海中得到解答。隨著你職業生涯的進步，你可能會解決越來越多的自己的障礙，但他們需要尋求幫助永遠不會完全消失。

在 GITHUB 和 STACK OVERFLOW 上提問

另外，請考慮一些問題也可能更適合在線論壇和資源，例如Stack Overflow^[3]或GitHub^[4]。有些問題是針對一段失敗的代碼，詢問關于可接受的模式使用或使用開源庫的方法的意見。對于這些，您可能會發現更廣泛的在線開發人員社區可以更好地為您提供幫助。

在線提問可能非常令人生畏，甚至比與您認識的人聯系更令人生畏。它的優勢之一是您可以接受更廣泛、更多樣化的意見和想法。您需要進行更多過濾和個人判斷，以驗證答案是否合理。如果在收到一些答案后，您仍然不確定它們，您可以隨時詢問您信任的人進行最終驗證。

在線論壇支持培養良好的提問行為。例如，假設您正在打開 GitHub 問題或開始討論開源項目的正確用法。在這種情況下，您應該嘗試查找之前是否已被詢問和回答。當一個簡單的搜索就可以產生您需要的答案時，維護人員可能會感到沮喪。不檢查會讓維護者覺得你比他們自己的時間更有價值。

你還應該確保你遵循我上面的建議。如果您認為自己發現了錯誤或正在為庫的使用而苦苦掙扎，請演示并分享合理的最小復制，而不是期望其他人閱讀額外的代碼或嘗試自己復制它。確保您已嘗試先調試代碼并閱讀文檔。如果您在自己做出合理的努力來回答問題后遇到困難，請不要害怕發布它。Jon Skeet 有一些很棒的內容，可以更深入地介紹這些實踐，也可以引導您在此過程中解決自己的問題。特別是，他的提問清單^[5]和他對Stack Overflow 文化的^[6]看法都值得一讀。

我個人在 Stack Overflow 上有過復雜的經歷。那里的文化可能非常好管閑事，有些成員太快批評問題的措辭方式或是否可能重復。只要您已經做出合理的努力來搜索以前的答案，并花時間用代碼示例形成一個精心設計的問題，盡量不要擔心偶爾出現的糟糕響應。

通過這個博客，我通過評論或聯系表收到了大量問題。我承認，我并不總是很擅長跟上。有時我發現這個問題太寬泛，需要太多時間才能完整回答。其他時候，由于措辭混亂或提出的要點太多，我什至不確定這個人真正需要什么幫助。

準備問題時，將自己置于接受者的位置。假設沒有關于您的問題領域的先驗知識，并確定您希望能夠理解問題的核心信息是什么。專注于形成一個具體而簡潔的問題，不會花費大量時間來解釋和回答。我收到過電子郵件，其中的人只是想一口氣問太多，我不知道他們需要了解什么才能解除封鎖。我也收到過電子郵件，其中的人希望我采用單行要求并從本質上解釋如何構建整個應用程序。這太寬泛了，我無法在個人時間回答。

我不是要讓你在我上一段中提出問題。我想提醒你，另一端的人是人，有自己的工作和承諾。考慮到這一點，并確保您不會用含糊不清的問題不公平地壟斷某人的時間。

詢問同事

有些問題自然會更具體地針對您的工作地點及其產品。您可能想知道為什么優先使用特定的代碼段而不是另一段代碼。您可能不確定軟件產品中的功能實際上是如何工作的。這些可能已經在公司 wiki 中被詢問和回答。盡管如此，在許多情況下，答案可能永遠不會被記錄下來。在這些情況下，您需要親自或通過聊天找到某人進行詢問。您可能還會驚訝地發現，更多資深同事也不確定答案。這并不罕見，因為知識會隨著時間流逝。您正在處理的代碼可能是很久以前編寫的，當時做出的決定可能不再明顯。

我堅信沒有愚蠢的問題。每個人的思維方式各不相同，對于一個人來說似乎很明顯的事情，對于另一個人來說可能不太清楚。當有人提出一個精心設計的問題并表現出一些試圖自己回答的跡象時，我更喜歡它。盡量簡潔明了地提出你的問題，這樣你問的人就可以快速弄清楚你想了解什么。此外，請務必在提問之前包含您已經知道或找到的任何相關信息。

與其說“這段代碼做了什么？”，不如說“我試圖理解這段代碼的作用”。我在谷歌上搜索過，我可以看到它可能是 XYZ 模式，但我仍然不清楚它到底在做什么。沒有針對代碼的測試，所以我無法確認預期的行為。你能幫我嗎？”

一個表明您已經在基礎知識上花費時間，嘗試自己調查并準備好您的想法的問題始終是首選。有時，您會面臨時間壓力，或者您可能擔心自己破壞了一些重要的東西。最好根據自己的感覺盡早提出問題，而不是浪費寶貴的時間來嘗試自己回答問題。

有時您可能能夠根據研究完全回答問題，這太棒了。要求某人簡單地驗證您認為答案是什么也沒有錯。“我正在嘗試理解這段代碼，我相信它是 X，我認為它使用這種模式是因為 Y。我的理解是否正確？” 是一個完全有效的問題。

如何提問

一旦你嘗試自己回答問題，如果你仍然需要一些幫助，你可能需要直接問別人這個問題。您的第一選擇是誰最適合回答這個問題。嘗試將您的查詢定向到最合適的人。知道該問誰并不總是那么容易，因此聯系您認識或共事的人以征求與誰交談的建議是合理的。

一旦確定了要交談的人，請考慮是否需要面對面交談，或者其他方法是否更適合。您在此處的選擇將取決于幾個因素，例如您的問題有多復雜？有多緊急？這個人更喜歡如何參與？那個人有多忙？

作為一般規則，我建議通過您的內部聊天系統詢問大多數問題。大多數公司使用一些異步消息服務，例如 Slack 或 Microsoft Teams。這些技術的優點是您可以避免打斷與您交談的人的交流。他們可以專注于自己的工作，直到有時間查看和回復聊天消息。

有些問題可能很容易通過聊天提出，您可以通過相同的媒介得到答案。有些將難以解釋或可能需要一些來回討論。這些最終可能會成為面對面的對話。首先，請考慮是否因為它很復雜而難以在聊天消息中寫下您的問題。也許你需要先簡化它。

橡皮鴨

順便說一句，我之前曾在此博客^[7]上討論過 Rubber Duck 的開發。有時，在提出問題時解釋您的問題時，答案會突然出現在您身上。我們的大腦可以以神秘的方式工作，有時，我們需要換檔來疏通自己。與面對面聊天相比，聊天消息的優勢之一是您可以在撰寫消息時回答自己的問題。在這種情況下，您不僅會得到答案，而且您甚至可能永遠不會打斷對方。他們可能在不知不覺中幫助了你。在我看來，這是一個真正的雙贏。

當問題對于聊天來說太復雜時

聊天是一個很好的起點，但它并不適合我提到的每個問題。您詢問的人可能會意識到這一點，并要求您親自會面或通過視頻會議。有時，您可能會發現它首先需要面對面。如果是這樣，我建議避免開始參與，因為這樣的中斷真的會破壞某人的流程。在這種情況下，我建議您使用您的工作場所聊天工具向您的收件人發送消息，詢問他們下次有空的時間。這樣，他們就可以在做出響應之前專注于完成當前的任務。作為開發人員，我更喜歡有人以這種方式問我問題，因為如果在某些編碼活動的關鍵時刻發生編碼中斷可能是真正的生產力殺手。

這個建議總會有奇怪的例外。如果您認為自己剛剛降低了生產量，請立即與人聯系！

如果您有更一般的問題，請考慮您是否安排了一個可能是一個很好的論壇的會議。有時在會議上提出問題可以提供更多樣化的意見，并使每個人都能從討論中受益。不要害怕問什么感覺像是一個基本問題。如果您有問題，其他人也可能有問題。我離開了會議，大多數與會者實際上并不理解一些重要的事情，但所有人都不敢問，之后每個人都單獨出現。

概括

無論您是為了成為軟件開發人員而學習，還是大三的第一天，還是長期擔任高級開發人員的高級開發人員，都不要害怕提問。求知是好事。它將幫助您成長并成為更好的開發人員。你會更深入地理解你的工作，并從你周圍的人那里吸收想法和推理。

請記住，雖然沒有愚蠢的問題，但存在形式不佳的問題。確保你的問題盡可能清晰和簡潔。

分享相關信息和在詢問之前，先做研究并嘗試自己回答。如果您在此之后仍然需要幫助，請不要害怕提出您的問題。我們都時不時地需要幫助。

References

[1]?Elastic:?https://www.elastic.co/
[2]?曾在博客中介紹過:?https://www.stevejgordon.co.uk/become-a-better-developer-by-reading-source-code
[3]?Stack Overflow:?http://stackoverflow.com/
[4]?GitHub:?https://github.com/
[5]?提問清單:?https://codeblog.jonskeet.uk/2012/11/24/stack-overflow-question-checklist/
[6]?Stack Overflow 文化的:?https://codeblog.jonskeet.uk/2018/03/17/stack-overflow-culture/
[7]?在此博客:?https://www.stevejgordon.co.uk/do-we-have-an-obsession-with-ducks-in-software-development/an-obsession-with-ducks

總結

以上是生活随笔為你收集整理的如何通过提问成为更好的开发人员的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。