本文字數：1227，閱讀時長大約：2分鐘
導讀：我所參與的開源項目遵循的是一種這樣的理念，我把它描述爲 “先討論，再編碼”。我認爲一般來說這是開發軟件的好方法，我想花一點時間來談談這種方法的好處。
https://linux.cn/article-12319-1.html
作者：Dave Cheney
譯者：Xingyu.Wang
我所參與的開源項目遵循的是一種這樣的理念，我把它描述爲 “先討論，再編碼”。我認爲一般來說這是開發軟件的好方法，我想花一點時間來談談這種方法的好處。
避免傷害感情
先討論你想做的改變最重要的原因是避免傷害感情。我經常看到一個貢獻者閉門造車地提交了一個 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中國 榮譽推出
