給開源項目貢獻代碼時：先討論，再編碼

我所參與的開源項目遵循的是一種這樣的理念，我把它描述為 「先討論，再編碼」。我認為一般來說這是開發軟體的好方法，我想花一點時間來談談這種方法的好處。

避免傷害感情

先討論你想做的改變最重要的原因是避免傷害感情。我經常看到一個貢獻者閉門造車地提交了一個 PR，卻發現他的努力工作被拒絕了。這可能有一堆原因：PR 太大了，PR 沒有遵循本地風格，PR 修復了一個對項目不重要的問題或者最近間接修復了的問題，等等。

這些問題的根本原因都是缺乏溝通。「先討論，再編碼」 理念的目標不是阻礙你或給你帶來挫折，而是確保一個功能第一次就能正確落地，而不至於產生大量的維護債務。無論是改動的作者，還是審查者，當一個改動突然出現時，並暗示說 「好吧，我已經做完了，你要做的就是合併它，對吧？」，先討論可以讓他們不必背負傷害感情的情緒負擔。

討論應該如何進行？

每一個新功能或錯誤修復都應該在工作開始前與項目的維護者討論。私下試驗是可以的，但不要在沒有討論之前就發送修改。

對於簡單的改動，「討論」 的定義可以只是 GitHub 議題中的一個設計草圖。如果你的 PR 修復了一個 bug，你應該鏈接到它修復的 bug。如果沒有，你應該先提出一個 bug，等待維護者確認後再發送 PR。這可能看起來有點落後 —— 誰不希望一個 bug 被修復呢 —— 但考慮到這個 bug 可能是對軟體工作方式的誤解，也可能是一個更大問題的癥狀，這需要進一步調查。

對於比較複雜的改動，尤其是功能請求，我建議在發送代碼之前，先分發一份設計文檔並達成一致。這不一定是一個完整的文檔，發一個議題，帶個草圖可能就足夠了，但關鍵是在用代碼搞定之前，先用文字達成一致。

在任何情況下，你都不應該繼續發送你的代碼，直到維護者同意你的方法是他們所滿意的。拉取請求是日常生活，而不僅僅是為了趕著過節。

代碼審查，而不是由委員會設計

代碼審查不是爭論設計的地方。這有兩個原因。首先，大多數代碼審查工具都不適合長長的評論會話，GitHub 的 PR 界面在這方面非常糟糕，Gerrit 比較好，但很少有管理員團隊會維護 Gerrit 實例。更重要的是，在代碼審查階段就出現了分歧，說明大家對如何實現這個變化並沒有達成一致。

討論你想寫的代碼，然後再寫你所討論的代碼。請不要反其道而行之。

via: https://dave.cheney.net/2019/02/18/talk-then-code

作者：Dave Cheney 選題：lujun9972 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive