六個開源軟體開發的「潛規則」

正如體育界不成文的規定一樣，這些規則基本上不會出現在官方文檔和正式記錄上。比如說，在棒球運動中，從比分領先時不要盜壘，到跑壘員跑了第一時也不要放棄四壞球保送。對於圈外人來講，這些東西很難懂，甚至覺得沒什麼意義。但是對於那些想成為 MVP 的隊員來說，這些都是理所當然的。

軟體開發，特別是開源軟體開發中，也有一套不成文的規定。和其它的團隊運動一樣，這些規定很大程度上決定了開源社區如何看待一名開發者，特別是新加入社區的開發者。

按部就班，循序漸進

在參與社區之前，比如開放源代碼或者其它什麼的，你需要做一些基本工作。對於有眼界的開源貢獻者，這意味這你需要理解社區的目標，並學習應該從哪裡起步。人人都想貢獻源代碼，但是只有少量的人做過準備，並且樂意、同時也有能力完成這項艱苦卓絕的工作：測試補丁、複審代碼、撰寫文檔、修正錯誤。所有的這些不受待見的任務在一個健康的社區中都是必要的。

為什麼要在優雅地寫代碼前做這些呢？這是一種信任，更重要的是，不要只關注自己開發的功能，而是要關注整個社區的動向。

博聞強識，敦善不怠

當你在某個社區中建立起自己的聲望，那麼很有必要全面了解該項目和代碼。不要停留於任務狀態上，而是要去鑽研項目本身，理解那些超出你擅長範圍之外的知識。不要只把自己的理解局限於開發者，這樣會讓你著眼於讓你的代碼有更大的影響，而不只是你那一畝三分地。

打個比方，你已經完成了一個網路模塊的測試版本。你測試了一下，覺得不錯。然後你把它開放到社區，想要更多的人測試。結果發現，當它以特定的方式部署時，有可能會破壞安全設置，還可能導致主存儲泄露。如果你將代碼視為一個整體時問題就可以迎刃而解，而不是孤立地看待問題。這表明，你要對項目各個部分如何與其他人協作交互有比較深入的理解。讓你的補丁填坑而不是挖坑。這樣你朝成為社區精英的目標上又前進了一大步。

粗枝大葉，自尋煩惱

代碼提交完畢後你的工作還沒結束。如果代碼被接受，還會有一些關於這些更改的討論和常見的問答，還要做測試。你要確保你可以準時提交，努力去理解如何在不影響社區其他成員的情況下，改進代碼和補丁。

和諧相處，助人助己

開源社區不是自相殘殺的叢林世界，我們更看重項目的價值而非個體的貢獻和成功。如果你想給自己加分，讓自己成為更重要的社區成員、讓社區接納你的代碼，那就努力幫助別人。如果你熟悉網路部分，那就去複審網路部分，用你的專業技能讓整個代碼更加優雅。道理很簡單，頂級的審查者經常和頂級的貢獻者打交道。你幫助的人越多，你就越有價值。

八面玲瓏，面面俱到

作為一個開發者，你很可能希望為開源項目解決一個特定的痛點。或許你想要運行在一個目前還不支持的系統上，抑或你很希望改革社區目前使用的安全技術。想要引進新技術，特別是比較有爭議的技術，最好的辦法就是讓人無法拒絕它。你需要透徹地了解底層代碼，考慮每個極端情況。在不影響已實現功能的前提下增加新功能。不僅僅是完成就行，還要在特性的完善上下功夫。

糜不有初，鮮克有終

開源社區也有許多玩玩就算的人，但是承諾了就不要輕易失信。不要就因為提交被拒就離開社區。找出原因，修正錯誤，然後再試一試。當你開發時候，要和整個代碼庫保持一致，確保即使項目發生變化而你的補丁仍然可用。不要把你的代碼留給別人修復，要自己修復。這樣可以在社區形成良好的風氣，每個人都自己改。

這些「潛規則」看上去很簡單，但是還是有許多開源項目的貢獻者並沒有遵守。這樣做的開發者不僅可以為成功地推動他們自己的項目，而且也有助於開源社區。

作者簡介：

Matt Hicks 是 Red Hat 軟體工程的副主席，也是 Red Hat 開源合作團隊的奠基成員之一。他歷時十五年，在軟體工程中擔任多種職務：開發，運行，架構，管理。

via: http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html

作者：Matt Hicks 譯者：Taylor1024 校對：wxy，martin2011qi

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

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