給開源項目貢獻代碼時:先討論,再編碼
![](https://linuxstory.org/wp-content/uploads/2024/06/160043oqnpi69m23b93zz3-800x400.jpg)
我所參與的開源項目遵循的是一種這樣的理念,我把它描述為 「先討論,再編碼」。我認為一般來說這是開發軟體的好方法,我想花一點時間來談談這種方法的好處。
避免傷害感情
先討論你想做的改變最重要的原因是避免傷害感情。我經常看到一個貢獻者閉門造車地提交了一個 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
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive