建立成功的Python項目

建立成功的Python項目

• 前端開發工具技巧介紹—Sublime篇
• SEO在網頁製做中的應用
• 觀察者模式
• 使用D3製做圖表

英文原文：Create successful Python projects，編譯：Elaine.Ye

建立一個成功的開源Python項目所涉及的並不只僅是編寫有用的代碼，與其相關的還有社區的參與、愈來愈多的合做機會、技藝以及支持等。探索最佳的作法有助於你建立出本身的成功項目。

開源Python項目的生態系統豐富多樣，這使得您可以站在巨人的肩膀上來開發下一個開源項目。此外，這意味着存在一系列的社區規範和最佳作法，經過遵照這些約定並把這些作法應用到項目中，你能夠爲本身的軟件贏得更廣範圍的採用。

本文涵蓋了一些在構建大型和小型的項目時都運做得很好的實踐作法，這些項目都已經贏得了普遍的用戶羣體。這裏給出的這些建議的都是合理的、有其意義的，不過，由於結果可能會有所不一樣，因此沒必要把它們當成嚴格的教條來遵照。

首先咱們來討論一下，解耦的過程如何可以帶來一個更強健的社區，在編寫、維護和支持開源軟件等各方面都帶來更大的生產能力。

合做（collaboration）和互助（cooperation）的對比

在DjangoCon 2011大會期間，David Eaves做了基調發言，雄辯地表達了這樣的想法，即儘管合做（collaboration）和互助（cooperation）有着相似的定義，但仍是有着細微的差異：

「我認爲，和做（collaboration）不一樣於互助（cooperation），其須要項目涉及到的各方通力來解決問題。」

Eaves接着又給出了一整篇文章，專門說明GitHub如何成爲革新開源的運做方式——特別是在社區管理方面的運做方式的推進力。在「How GitHub Saved OpenSource」這篇文章（參見參考資料）中，Eaves說到：

「我相信，當捐獻者可以以低交易成本的互助方式來參與，而且高交易成本的合做儘量的少時， 開源項目的運做能達到最好。開源的高明之處就在於其不須要一個工做組來共同討論每一個問題以及解決問題，而是偏偏相反。」

他接着談到了分支（forking）的價值所在，以及其如何經過在參與者之間啓用低成本的互助來下降合做的高成本，這些參與者可以在無需批准的狀況下推動項目。這種分支把須要的合做擱置起來，直到解決方案已經作好了合併的準備爲止，如此來支持更快速的動態的實驗。

你能夠以相似的方式來打造本身的項目，目標是相同的：在編寫、管理和支持項目的整個期間，增長低成本的互助，同時儘量減小代價高昂的合做。

編寫

從一張白紙開始，建立一些新鮮的東西，製造一些有創意的東西——或僅僅是一些與現有的略不一樣的東西，沒有什麼事情比得上啓動一個新的項目並和全世界分享你的努力成果讓人感受更好的了。

與維護不一樣，在編寫代碼時，你是在創造新的東西而不是在修改或是修正已有的東西。編寫和構思一個項目除了是一門科學以外仍是一種藝術形式，其餘人會看到實現的狀況並會對代碼的質量做出判斷，而你的名字將會永遠和它連在一塊兒。

所以。瞭解工匠的心態以及據此來編寫軟件的方法是很重要的。編寫新的項目不只僅是意味着生成代碼：項目的建立和構思包括了編寫有着精美風格的讓人樂於閱讀的代碼、在適當的時候爲驗證項目中的功能建立測試代碼，以及製做詳盡的有幫助的文檔。

技藝

工藝（craft）通常是指藝術行業或是職業須要特殊的技能來手工製做一些東西，一般是小規模生產的物理器件。就軟件工匠關注的更多的是質量而非數量這一意義而言，你能夠延伸這必定義，把它應用在軟件上。

對於工匠來講，產品具備吸引力而非只是功用是很重要的。具體來講，在軟件中，工匠要努力確保代碼的乾淨和美觀、應用編程接口（API）的悅目，以及文檔和測試用例可以給用戶帶來是在使用堅實的產品進行工做的這種感覺。

在這種心態下工做，對於心靈來講是一種獎賞，也是在製做開源軟件時能感覺到諸多享受的緣由：你再也不受困於迴應最後期限、客戶以及其餘的外部需求，而是按照本身的時間來，享受制做一些美好事物的樂趣。

代碼風格和規範檢查

Python的加強建議（Python Enhancement Proposal，PEP）8（參見參考資料）是一個詳細的Python風格指南，你應該基於該指南來創建本身的Python項目（或至少是基於你的項目 的風格指南）。不是非要教條地採用PEP 8，不過你的工做成果越接近PEP 8規範，其餘的Python開發者就越容易提交以標準的Python社區風格實現的整潔的補丁包。

除了風格的一致性以外，在捕捉諸如缺失導入和未定義變量一類的錯誤方面，代碼規範（linting）的概念也是頗有做用的。除了風格檢查器會幫助你 進行檢查，找出違背了默認規則或是自定義規則的代碼以外，現還有一些規範器（linter）或是一些工具，最經常使用到的一些實用程序是：

1. pyflakes
2. pylint
3. pep8

請參閱參考資料得到到這些工具的連接。

不管你選擇聽從的是哪種約定，若是這些約定偏離了PEP 8的話，我建議文檔化它們，以便讓那些想要爲你的項目作貢獻的人瞭解你所採用的編碼風格，顯式的說明要好於隱含不語。

pyflakes是一個特別有用的規範器，它很好地平衡了有用的功能、捕捉和標出錯誤這兩方面，不會過分地揪住微小的古怪作法不放。下面是一個在某個Python項目上使用pyflakes的示例會話：

1 2 3 4

$ pyflakes kaleo kaleo / forms.py: 1 : 'form' imported but unused kaleo / forms.py: 4 : undefined name 'forms' kaleo / forms.py: 6 : undefined name 'forms'

馬上，該工具告訴了我有一個import的輸入錯誤，查看文件kaleo/forms.py，我發現：

1 2 3 4

1 : from django import form 2 : 3 : class InviteForm(forms.Form): 4 : email_address = forms.EmailField()

從內容中可看出來，要把第1行改成from django import forms。

測試

在項目中提供驗證代碼有效性的測試始終是一件好事，以此來防止迴歸被忽視，以及在某些狀況下做爲一種文檔形式，經過閱讀其中的測試代碼可讓其餘人知道你的庫API是如何工做的。

話雖如此，但我不會根據項目是否包括測試用例或是完成這些測試的方式 來判斷項目的完整性或可行性。測試用例的存在並不能保證代碼的質量，這多是一個有爭議的觀點，但我相信，徹底沒有測試比去測一些錯誤的東西要來得好一 些。在編寫測試代碼時，考慮爲每一個測試單元給出各類輸入是一件很重要的事情。

文檔

不過，與測試不一樣的是，你能夠根據項目文檔的質量和廣博性來判斷項目的質量和技藝水平。用與創做和維護代碼相同的方式來創做和維護穩定，編寫良好的而且是有深度的文檔會鼓勵捐獻者效仿你的作法，使你的項目變得更易於爲用戶接受。

使用諸如Sphinx和Read the Docs一類的工具（參見參考資料），你能夠發佈及時更新的、外觀極爲不錯的文檔。使用這些工具是一件簡單的事情，也就是寫一些文字內容並並推送提交。習慣於儘量地使用commit來提交文檔的變動是很適當的一種作法。

維護

在Python Package Index（PyPI）上發佈了第一個版本，並經過各類Tweet消息和博客文章公佈該版本的消息，開始有了一些使用者以後，你就須要在任何後續的創做活 動中加入維護方面的考慮了。用戶會報告錯誤、要求添加功能、提一些文檔中沒有明顯涉及到問題，諸如此類等等。

有些事情你會選擇不去處理，給出一些權變措施；但其餘的一些問題，你會打算或是修正文檔或是修正代碼。使用諸如git一類的分佈式版本控制系統 （distributed version control system，DVCS）並經常發佈開發者包，這種作法能夠大大簡化維護工做，使之變成一件再也不是煩人的事情。

源控制

有許多可用的DVCS，其中就包括了git和mercurial（參見參考資料），不管你選擇的是哪個控制系統，請確保它提供了源控制功能，這種功能賦予你這樣的能力，可讓用戶分支你的項目，而後本身來解決其中的錯誤。

進行變動的速率取決於許多因素，一個關鍵的因素是目標受衆（例如，其餘開發者、非技術型的最終用戶）。若是你的項目是針對開發者來編寫的，那麼鼓勵 經過拉請求（pull request）來報告錯誤或是請求功能之類的作法能夠真正地作到下降維護者的負擔。這種作法還提高了社區的歸屬感，由於你們都把他們的捐獻合併到了未來 的版本中。

開發構建

你會但願儘早地以及常常性地發佈開發版本，在每次有一組附加的補丁包出來以後都會發布版本，如此屢次。這會讓其餘在工做中使用你的項目的開發者可以 更容易地針對項目中的最新更改來運行。越多的人在不一樣的狀況下使用這些代碼，那麼一旦到發佈一個新的穩定版本的時候，該版本就會有越高的質量。

支持

支持是和維護相隨的，參與並構建一個由用戶和捐獻者組成的社區相當重要。賦予其餘人經過支持來幫助你的權利，你就是在加強項目的全面合做因素，在項目的規模方面提供更好的伸縮性，以及天然而然地增長了解決用戶問題的作法。

爲了達到該目的，請確保提供多種渠道來增長接觸的機會，讓用戶更加容易地與你接洽以及參與到項目中。可選的溝通渠道包括IRC、郵件列表以及諸如Twitter一類的社交媒體匯聚點。

IRC

在諸如freenode一類的IRC平臺上設置一個溝通頻道是一個好主意，我就爲本身的項目設置了一個：nashvegas；除了我以外只有一個用 戶，雖然這種狀況不多有，但個人IRC客戶端仍是悄無聲息地運行在後臺。當偶爾有用戶提問時，我可以只花不多的交易成本就以一種比經過郵件要動態得多的方 式來作出響應。

郵件列表

對於大多數的開源項目來講，有一個用於支持的郵件列表並在捐獻者之間討論開發進程是一種標準的作法。個人建議是，把支持放在一個郵件列表中，只有在內容已經變得太多，彼此影響到了各小組的討論的時候，才把它分紅「用戶」列表和「開發」列表。

Twitter

爲項目開設一個Twitter賬戶，你們能夠在這裏與你快速地討論工做。Twitter賬戶仍是一個能夠做爲發佈項目消息的好地方。

結束語

給Python社區中的開源軟件編寫並捐獻代碼是一種有趣且有益的體驗。在增長低成本互助機會的同時側重於減小高成本的合做，這種作法有助於項目與 活躍的捐獻者一塊兒成長。在開源領域，就你的項目來講，你有大把的自由來成爲一個能工巧匠，充分利用這一點並享受它。把關注的重點放在一致的代碼風格、堅實 的測試和編寫良好的文檔上，以此來提升項目被用戶和其餘開發者採用的概率。此外，要利用DVCS，關注拉請求，常常性地發佈開發版本。最後還有一點就是， 你能夠提供多種支持渠道，以及容許社區協助你提供這種支持，經過這些作法來進一步提高項目的採用率並促進項目的成長。

 

參考資料

1. 閱讀Mark Pilgrim的Dive into Python，獲取關於該語言的一個介紹。

2. 欲瞭解更多關於打包Python項目方面的信息，能夠讀一下 A guide to Python packaging（Patrick Altman，developerWorks，2011年10月）這篇文章。

3. 閱讀更多David Eaves的博客文章： Wikis and Open Source: Collaborative or Cooperative? 和How GitHub Saved OpenSource.

4. 在潛心進行下一個Python項目以前，請確保已瞭解PEP 8，Python代碼的這一「官方」風格指南。

5. 瀏覽一下個人項目nashvegas的GitHub頁面，以此來作爲一個使用DVCS的Python項目的例子。

6. 看一看PyPI。

7. 瞭解更多關於分佈式Python模塊方面的內容。

8. developerWorks開源專區提供了豐富的關於開源工具和使用開源技術方面的信息。

9.在Twitter上關注developerWorks。

10. 在Easy and beautiful documentation with Sphinx (Alfredo Deza，developerWorks，2011年11月)一文中瞭解更多關於Sphinx的內容。