Sync to Traditional Chinese version

如果您熟悉繁体中文,请对此 Commit 提出建议或直接修改来完善它。

Original for Reference: Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for.
This commit is contained in:
Aynxul03 2022-08-04 21:49:55 +08:00 committed by GitHub
parent bc9c2af457
commit 765e2f98c0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -373,11 +373,11 @@ Stack Exchange 已經成長到[超過一百個網站](http://stackexchange.com/s
要理解專家們所處的世界,請把專業技能想像為充裕的資源,而回覆的時間則是稀缺的資源。你要求他們奉獻的時間越少,你越有可能從真正專業而且很忙的專家那裡得到解答。 要理解專家們所處的世界,請把專業技能想像為充裕的資源,而回覆的時間則是稀缺的資源。你要求他們奉獻的時間越少,你越有可能從真正專業而且很忙的專家那裡得到解答。
所以,界定一下你的問題,使專家花在辨識你的問題和回答所需要付出的時間減到最少,這技巧對你有用答案相當有幫助──但這技巧通常和簡化問題有所區別。因此,問```我想更好的理解X可否指點一下哪裡有好一點的說明```通常比問```你能解釋一下X嗎```更好。如果你的程式碼不能運作,通常請別人看看哪裡有問題,比要求別人替你改正要明智得多。 所以,界定一下你的問題,使專家花在辨識你的問題和回答所需要付出的時間減到最少,這技巧對你獲得有用答案相當有幫助──但這技巧通常和簡化問題有所區別。因此,問```我想更好的理解X可否指點一下哪裡有好一點的說明```通常比問```你能解釋一下X嗎```更好。如果你的程式碼不能運作,通常請別人看看哪裡有問題,比要求別人替你改正要明智得多。
### 詢問有關程式碼的問題時 ### 詢問有關程式碼的問題時
別要求他人幫你有問題的程式碼除錯而不提示一下應該從何入手。張貼幾百行的程式碼,然後說一聲:```它不會動```會讓你完全被忽略。只貼幾十行程式碼,然後說一句:```在第七行以後,我期待它顯示 <x>,但實際出現的是 <y>```比較有可能讓你得到回應。 如果沒有提示別人應該從何入手,別要求他人幫你調試有問題的程式碼。張貼幾百行的程式碼,然後說一聲:```它不會動```會讓你完全被忽略。只貼幾十行程式碼,然後說一句:```在第七行以後,我期待它顯示 <x>,但實際出現的是 <y>```比較有可能讓你得到回應。
最有效描述程式問題的方法是提供最精簡的臭蟲展示測試示例bug-demonstrating test case。什麼是最精簡的測試示例? 那是問題的縮影;一小個程式片段能**剛好**展示出程式的異常行為,而不包含其他令人分散注意力的內容。怎麼製作最精簡的測試示例?如果你知道哪一行或哪一段程式碼會造成異常的行為,複製下來並加入足夠重現這個狀況的程式碼(例如,足以讓這段程式碼能被編譯/直譯/被應用程式處理)。如果你無法將問題縮減到一個特定區塊,就複製一份程式碼並移除不影響產生問題行為的部分。總之,測試示例越小越好(查看[話不在多而在精](#話不在多而在精)一節)。 最有效描述程式問題的方法是提供最精簡的臭蟲展示測試示例bug-demonstrating test case。什麼是最精簡的測試示例? 那是問題的縮影;一小個程式片段能**剛好**展示出程式的異常行為,而不包含其他令人分散注意力的內容。怎麼製作最精簡的測試示例?如果你知道哪一行或哪一段程式碼會造成異常的行為,複製下來並加入足夠重現這個狀況的程式碼(例如,足以讓這段程式碼能被編譯/直譯/被應用程式處理)。如果你無法將問題縮減到一個特定區塊,就複製一份程式碼並移除不影響產生問題行為的部分。總之,測試示例越小越好(查看[話不在多而在精](#話不在多而在精)一節)。
@ -425,7 +425,7 @@ Stack Exchange 已經成長到[超過一百個網站](http://stackexchange.com/s
問題解決後,向所有幫助過你的人發個說明,讓他們知道問題是怎樣解決的,並再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注,應該在那裡貼一個說明比較恰當。 問題解決後,向所有幫助過你的人發個說明,讓他們知道問題是怎樣解決的,並再一次向他們表示感謝。如果問題在新聞組或者郵件列表中引起了廣泛關注,應該在那裡貼一個說明比較恰當。
最理想的方式是向最初提問的話題回覆此消息,並在標題中包含```已修正``````已解決```或其它同等含義的明顯標記。在人來人往的郵件列表裡,一個看見討論串```問題 X```和```問題的X - 已解決```的潛在回覆者就明白不用再浪費時間了(除非他個人覺得```問題 X```有趣),因此可以利用此時間去解決其它問題。 最理想的方式是向最初提問的話題回覆此消息,並在標題中包含```已修正``````已解決```或其它同等含義的明顯標記。在人來人往的郵件列表裡,一個看見討論串```問題 X```和```問題的X - 已解決```的潛在回覆者就明白不用再浪費時間了(除非他個人覺得```問題 X```有趣),因此可以利用此時間去解決其它問題。
補充說明不必很長或是很深入;簡單的一句```你好,原來是網路線出了問題!謝謝大家 Bill```比什麼也不說要來的好。事實上,除非結論真的很有技術含量,否則簡短可愛的小結比長篇大論更好。說明問題是怎樣解決的,但大可不必將解決問題的過程複述一遍。 補充說明不必很長或是很深入;簡單的一句```你好,原來是網路線出了問題!謝謝大家 Bill```比什麼也不說要來的好。事實上,除非結論真的很有技術含量,否則簡短可愛的小結比長篇大論更好。說明問題是怎樣解決的,但大可不必將解決問題的過程複述一遍。