[[112635]]

【51CTO精選譯文】Difio是一款基于Django的應用程序，旨在追蹤軟件包狀態并在其發生變化時通知用戶。它提供多種變更分析選項，因此大家可以根據當前掌握的情況決定何時或者如何實施軟件包升級。Difio本身是一款標準的封閉軟件，我決定把它轉化為開源項目以實現家庭開發并為其吸引到更多技術社區參與者。

簡化

任何一款已經面世數年的應用程序當中都必然積累下一些不會再被用到的代碼以及功能。將這些無關緊要的部分加以清除能夠保證需要共享的代碼內容更純粹也更簡潔。Difio開源化工作的第一步正在于此--將現有代碼庫的規模降低約20%。

具體工作內容包括：

• 未使用或者已經過時的設置
• Django應用
• 靜態文件與模板
• 模型類
• 遺留URL
• 不建議使用的功能
• 其它Python公用工具

舉例來說，在處理額外的依賴關系以及一次性代碼時，我過去一直習慣于將其記錄在某些模板以及純HTML當中。我也設置過一些只使用過一、兩次的自定義模板標簽。這一切都屬于被刪除的對象，最終保留下來的模板彼此之間都保持著較高的一致性。

對路徑、值以及URL等要素進行硬編碼無疑是快速原型設計工作中無法回避的組成部分。在某些情況下，閉源應用程序會繼承其開發環境所遺留下來的某些特征，而這些也需要加以調整。我曾經在必要時使用過一部分自定義模板標簽與設置。

創建自包含模塊

換句話來說，對文件結構的重新構建也在實現簡化的同時讓應用本身顯得更加自然。創建自包含與獨立模塊使我們今后能夠更輕松地將它們彼此拆分開來。

Difio的web后端被部署在OpenShift之上，其中針對模板與狀態文件使用了不同的目錄層。我需要移動這些文件并更新Django設置，從而讓它們能夠更為恰當地進行載入。這也迫使我重新思考該如何將原始靜態文件發送至CDN后端。

將內部與外部代碼劃分開來

在應用程序當中使用一部分內部代碼以提供更多信息可謂理所當然。舉例來說，我們在實現使用情況及其它指標追蹤、計費乃至其它功能時，內部代碼可謂不可或缺。在web服務方面，這些代碼往往會被整合到核心功能當中，因此作為開源轉化工作的重要部分、我們需要將其劃分出來。

著手轉化的過程也讓我們得以判斷哪些內容需要被劃分出去、哪些最好繼續保留其中。舉例來說，Difio不會將測試實例劃分出去，這是為了減少將其從CI環境中明確劃分以及完全以web服務或者獨立應用方式運行所帶來的額外工作量。

Difio當中包含五大獨立模塊：

1. difio/ (核心用戶體驗所在)

2. 配置文件子系統

3. 計費模塊

4. 擴展管理員界面

5. 相關模塊部署（大部分設置來源于此）

以上模塊彼此之間被明確區分開來且保持相互隔離，所有輸入與內部依賴關系都被移除。目前difio/依賴于多個配置文件API以提供正確的缺省值。

這一步驟還能幫助大家將操作組件（例如定制化電子郵件模板）從核心用戶體驗當中拆分出來。

代碼重構

無需贅言，代碼重構與測試也應當作為一項需要持續關注的工作內容。不過到現在為止，大家可能已經對全套現有源代碼（或者其中的大部分）進行了快速審查，而且初步明確了其中哪些部分需要加以改進。開源轉移也是提升軟件水準的好機會，我們應當好好把握。

此外，我們也可以借此機會構建起一套短期路線圖，其中包含需要修復的漏洞等之前收集到的公共問題信息。這套路線圖能幫助大家的新生項目在誕生之初表現出更為旺盛的活力與改進態勢，這些特性是吸引更多貢獻者加入進來的關鍵所在。

在Difio當中，我對一部分方法以及大部分內部代碼進行了重構，旨在使其更好地與新應用程序結構相吻合。外部方法則姑且放在一邊、等待今后修復，畢竟這部分改進屬于"錦上添花"而非"雪中送炭"。

法律工作

根據軟件規模與復雜程度的不同，大家在對其進行開源化整理與遷移時所需要付出的時間周期也會出現巨大差異。從選擇合適的開源許可、塑造品牌、在產品中注明作者、進行法律審查并尋找可能存在專利侵權可能性的風險代碼等等，這一切都是我們需要提前考慮的問題。

不過在Difio方面，這部分工作就簡單得多了。我選擇的是Apache 2.0許可，將許可標題添加到全部源文件當中，并妥善解決了自己能在互聯網上找到的全部與外部代碼相關的著作權與版權問題（在大部分情況下，應用本身不會就此提出任何特定條款）。

更新并羅列外部依賴關系

作為一名軟件開發人員，大家必須要采取額外的處理步驟來應對其它應用程序的最新版本升級，同時確保自己的軟件能夠與它們保持順暢協作（或者至少要保持合理的協作效果）。沒人愿意為了運行大家的代碼而被迫使用舊有依賴關系，而且在大多數情況下這也是根本不可能的。

另外，大家還需要制訂一份依賴關系列表（例如requirements.txt文件），用于幫助使用者了解如何在運行軟件之前安裝其它必要程序。幸運的是，Difio是一款基于Django的應用，因此升級問題很少、對外部方案的依賴關系也不是太強。

提供說明文檔與示例

對于任何一位剛剛接觸我們開源項目的新人來說，說明文檔的意義都可謂至關重要。畢竟我們的目的是建立起一套極具吸引力的社區，因此保持其開放性是實現目標的必要前提。而在這方面，撰寫說明文檔與示例就成了重中之重。

在Difio這邊，我編寫了一份README文件，其中詳細描述了與設置相關的各項內容--這是考慮到該應用擁有多套子系統（包括消息傳遞層以及計劃任務調度等），而這些子系統可以通過多種方式實現配置。我編寫的第二份文檔則是《內容管理指南》，很明顯并不是每項工作都能夠以自動化方式完成、手動機制偶而也需要參與進來。這兩份文檔涵蓋了Difio當中最為重要的全部設計與部署特性--不過除此之外，大家可能還需要為自己的項目準備更多說明文檔。

創建一套公共代碼庫

現在是時候創建一套公共代碼庫并著手進行軟件交付了。

在Difio開源項目中，我決定把整個difio/目錄從原有位置復制出來作為最初的提交內容。這樣做的弊端在于此前所有歷史提交內容都將不再可用，但我選擇這種作法是為了避免已經被以硬編碼方式添加到代碼片段中的密鑰與密碼遭到泄露。

在生產過程中，我利用git子模塊取代了difio/目錄;這一方面是為了加快發布/部署周期，另一方面則因為我的云環境選擇了git作為部署機制。

從現在開始，大家對源代碼進行的一切調試及修改都將以公開方式進行。

在全新環境下測試單機部署

截至目前，大家的注意力可能一直集中在對現有本地副本的調試以及對應用程序前續版本遺留下來的內容--例如依賴關系、環境配置等等--進行遍歷上。不過接下來我們需要轉換思路，從外部用戶的視角出發在全新環境下著手測試--這能夠幫助我們進一步完善說明文檔并清理遺留問題。

在對Difio進行測試時，我發現了幾項之前忽略掉的或者剛剛出現的運行要求、缺少或者未經恰當處理的設置方式外加一些存在錯誤或者內容不夠完整的說明文檔。

在這部分工作完成之后，別急著休息、從頭開始再進行一次，直到每個步驟都擁有正確的解釋并適用于作為運行基礎的全新設備。這至少能夠確保未來的項目貢獻者及用戶能夠順利地將軟件安裝在自己的計算機上。

發布

終于迎來了最后一項工作！寫下屬于自己的宣傳稿件，并向全世界介紹自己的這款新軟件。祝賀各位，從這一刻時你已經正式步入開源陣營！

原文鏈接：http://opensource.com/business/14/5/10-steps-migrate-closed-to-open-source