1.3 如何尋求編程幫助

當在線搜索和linter都不能解決問題時，可以嘗試在網上尋求編程幫助。不過，你需要了解有效尋求建議的禮儀。當經驗豐富的軟件開發人員愿意無償回答你的問題時，最好能有效地利用他們的時間。

向陌生人尋求編程幫助應當總是最后一個選擇，因為你發布的問題可能幾小時甚至幾天后才會得到回復。更快的方式是搜索是否有其他人已經在網上問過你遇到的問題，了解他們得到的答案。在線文檔和搜索引擎的目的就是減少人工回答的工作量。

當你用盡渾身解數，只能尋求人工幫助解答你的編程問題時，請避免以下常見錯誤。

·先詢問是否可以提問，而非直接提出問題。

·拐彎抹角而非直截了當地提問。

·在不適合的論壇或網站上提出問題。

·帖子名稱或者郵件主題不夠具體，比如“我有一個問題”或“求助”這樣的主題。

·只說程序不能正常工作，但不解釋預期的正確行為是什么。

·不提供完整的錯誤信息。

·不分享代碼。

·分享的代碼格式不好。

·不說明你已經嘗試過的方案。

·不提供操作系統或者版本信息。

·讓人幫你寫程序。

這份“避坑”清單中不能做的事情并非僅是出于禮儀考慮，更重要的是，這些習慣會阻礙幫忙者助你一臂之力。幫助你的人首先要運行代碼并嘗試重現問題，因此需要許多關于代碼、計算機和程序意圖的信息。但現實中，提供過少的信息往往比提供過多的信息更常見。接下來的幾小節將探討如何避免這些常見的錯誤。我將假設你把問題發布在一個在線論壇上。此外，對于給個人發送郵件或把問題群發到郵件列表的情況，下面列出的建議同樣適用。

1.3.1　預先提供信息以避免反復補充

如果你在線下找人求助，問他“我可以問你一個問題嗎”不失為一個快速確認他是否有空的方式。但在互聯網論壇上，幫助你的人可能要等到有空時才會回復。既然可能要在幾小時后才能得到回復，你最好第一次發帖時就寫上所有可能需要的信息。如果沒能得到回復，那么可以把問題復制到別的論壇再發一次。

1.3.2　以實際問題的形式陳述問題

在闡述問題時，你會下意識地認為別人聽得懂你在說什么，但編程是一個非常寬泛的領域，別人有可能在你所遇到的問題的具體領域中缺乏經驗，所以用實際問題的形式陳述問題是很有必要的。雖然以“我想要……”或者“這個代碼不行啊”開頭的句子也可以含糊地說明你的問題，但請務必包含明確的問題，也就是以問號結尾的問句，否則可能無法清楚地表達自己的意圖。

1.3.3　在合適的網站上提出你的問題

在JavaScript論壇上問Python問題，或者在網絡安全郵件組問算法問題很可能讓你白忙一場。通常情況下，郵件組和互聯網論壇有常見問題列表（FAQ）文檔或者描述頁面，來說明哪些主題適合在該站點進行討論。例如，python-dev郵件組是關于Python語言設計特性的，而不是尋求常規Python幫助的郵件組。如果不確定你的問題該到哪里提問，可以參考Python官網的Help頁面。

1.3.4　在標題中概述你的問題

在互聯網論壇發求助帖的好處在于可供其他遇到相同問題的程序員搜索。確保問題的標題具備概述性，這樣可以讓搜索引擎更容易收錄。像“幫幫忙”或者“怎么不行啊”這種普通的標題就太模糊了。通過郵件提問時，一個有意義的主題也會讓幫忙者掃一眼就知道問題是什么。

1.3.5　說明代碼的預期目的

“為什么我的程序不能工作”，這個問句忽略了關鍵細節——你希望程序做什么。對幫助你的人而言，這并不總是顯而易見的，因為他們不清楚你的目的。哪怕你的問題是“我為什么會得到這個錯誤”，都更能讓人明白你的最終目的。在某些情況下，幫忙者可能會告訴你是否需要另辟蹊徑，或者應該放棄這個問題，而不是在這個問題上浪費時間。

1.3.6　包含完整的錯誤信息

務必復制并粘貼包括回溯信息在內的所有錯誤信息。如果只是描述你的錯誤，比如“我遇到了一個越界錯誤”，并不能提供足夠的細節讓幫忙者找到錯誤原因。同時，你需要說明這個錯誤是經常出現的，還是偶然出現的。如果確定了錯誤發生的具體情境，也要一并告之。

1.3.7　分享全部代碼

除了完整的錯誤信息和回溯信息，也要提供程序的完整源代碼，以便幫忙者在自己的計算機上運行你的程序，并通過調試工具檢查到底出了什么問題。務必提供一個最小、完整、可復現（簡寫為MCR，是minimum、complete、reproducible三個單詞的首字母）的樣例，保證它能復現你遇到的錯誤。MCR這個術語來自于技術問答社區Stack Overflow，你可以在那里找到關于MCR的詳細說明。“最小”意味著樣例在能復現錯誤的前提下盡可能簡短；“完整”意味著樣例包含復現問題需要的一切元素；“可復現”意味著樣例能夠可靠地復現你描述的問題。

如果是單文件程序，在確保格式正確的前提下（這一點會在下一節討論），直接發給幫忙者即可。

Stack Overflow和歸檔答案

Stack Overflow是一個流行的編程問答網站，很多新人剛使用它時會感覺沮喪甚至恐懼。Stack Overflow的版主常常會無情地關閉不符合其嚴格規定的問題。但如此嚴格的管理也不無道理。

Stack Overflow的目的不是解答問題，而是將編程問題和對應答案歸檔。所以，Stack Overflow希望問題是具體、獨特的，而非基于個人觀點的。為了讓使用搜索引擎的用戶容易找到，問題需要有詳細的說明。知名的XKCD漫畫“Wisdom of the Ancients”（古人的智慧）的創作靈感就是來源于Stack Overflow出現之前的編程世界。幾十個同質化問題不僅會讓回答問題的專家志愿者重復勞動，也會讓搜索的人對多個結果感到困惑。問題應該有客觀、具體的答案，而“什么是最好的編程語言”則是見仁見智的，會引起不必要的爭執。（當然，眾所周知，Python才是最好的語言。）

當你尋求幫助時，問題卻被迅速關閉，這不免會令人覺得尷尬和難過。我的建議是，首先仔細閱讀本章和Stack Overflow的“How do I ask a good question?”指引；其次，如果害怕提出愚蠢的問題，隨便起個假名就好。Stack Overflow并不要求用戶使用真實姓名。如果你希望提問時不用那么嚴肅緊張，可以考慮把問題發布到Reddit的Python相關頁面上，那里對問題的容忍度要高一些。不過在提交問題之前，還是務必先閱讀那里的發帖指引。

1.3.8　通過適當的格式化增強代碼可讀性

分享代碼的目的是讓幫忙者可以運行代碼并重現錯誤。他們不是只要拿到代碼就行，而是希望代碼經過了良好的格式化。請確保讓幫忙者能夠容易地復制代碼并照此運行。如果要在郵件中粘貼源代碼，請注意很多郵件客戶端可能會刪除縮進符，導致代碼看起來像是這樣：

def knuts(self, value):
if not isinstance(value, int) or value < 0:
raise WizCoinException('knuts attr must be a positive int')
self._knuts = value

幫忙者不僅要浪費很多時間為每一行重新插入縮進符，而且也不清楚每行的縮進位置是否正確。為了確保你的代碼格式正確，請把代碼復制并粘貼到“剪切板”網站2，比如Pastebin和GitHub Gist。它們可以將你的代碼存儲為簡短的公共鏈接，分享這個鏈接比使用文件附件更容易。

2 這類網站的英文叫作pastebin，源于第一個此類網站的名字。——譯者注

如果你要把代碼發布到網站上，確保使用網站的文本框所提供的格式化功能。通常使用4個空格縮進可以確保這行使用更易閱讀的等寬代碼字體3。除此之外，使用反引號將文本包裹起來也有同樣的效果。這類網站通常會提供一個講解如何進行格式化的頁面。不利用這些技巧可能會破壞你的代碼格式，代碼會全部擠在一行，就像下面這樣：

3 字符寬度相同的字體。——譯者注

def knuts(self, value):if not isinstance(value, int) or value < 0:raise
WizCoinException('knuts attr must be a positive int') self._knuts = value

此外，不要通過發送截圖或者對著屏幕拍攝的照片來分享代碼。沒人能從圖片中復制代碼，而且圖片中的代碼也經常難以辨認。

1.3.9　告訴幫忙者已經嘗試過的方法

發布問題時，告訴幫忙者你已經嘗試了哪些方法以及結果，以免讓他浪費時間重試。同時，這樣做也能表明你不是“伸手黨”，而是已經做了努力。

此外，這些信息可以確保你是在尋求幫助，而不是直接要求別人幫你寫程序。遺憾的是，常常有計算機科學專業的學生要求網上的陌生人幫他們做作業，或是創業者要求別人為他們免費創建一個“簡單的App”。編程求助論壇可不是為了這種目的設立的。

1.3.10　描述你的設置信息

計算機的具體設置可能會對程序運行和錯誤的產生有影響。為了確保幫助你的人能夠在他們的計算機上重現問題，請提供你所用計算機的以下信息。

·操作系統和版本，如“Windows 10專業版”或者“macOS Catalina”。

·運行程序的Python版本，如“Python 3.7”或者“Python 3.6.6”。

·程序使用的所有第三方模塊及其版本，如“Django 2.1.1”。

可以通過運行pip list來查看已安裝的第三方模塊的版本。通常，也可以通過模塊的__version__屬性查看。以下是一個交互式shell示例：

>>> import django
>>> django.__version__
'2.1.1'

這些信息很可能并無必要，但為了減少反復溝通，務必在最初的帖子中就提供這些信息。