什麼時候應該發佈我的代碼？

我一直在推遲發佈我寫的圖書館，因爲它是我將公開發布的第一個圖書館。這裏是我的顧慮：什麼時候應該發佈我的代碼？

庫不是完成這是一個非常實用的狀態，我會說這是0.3版本，但是它仍然缺少一些功能，我想在一些點實現，並控制它們如何實現（意味着不合並某些實現）。
我害怕批評，我知道應該重新組織/重構一些東西，但是我很快就寫了最初的類來適用於我正在開發的另一個項目。

那麼什麼時候發佈是最佳時機？我應該把它放在github上，並在發佈後解決問題？還是應該等到我重構並對我寫的內容感到完全滿意？

我看到的大多數類/庫總是非常優雅的編寫，但是在很早的版本階段我還沒有看到任何版本，初始版本中有很多類相當草率？

來源

2010-09-28 tplaner

很有可能沒人會有興趣去批評它。那裏有太多的免費庫。 – 2010-10-08 13:58:21

提前發佈，經常發佈。

只要其建設性，批評是一件好事。忽略仇敵，注意提交bug報告和評論的人們。

代碼的內部結構很重要，但它更重要的是它可以用於其預期目的。一般而言，重構將改變代碼在內部的工作方式，但不會影響其使用方式。相同的輸入和輸出。

來源

2010-09-28 14:32:04 Freiheit

你需要得到的東西中途有用的第一，然後別人就會說「嘿，這幾乎是爲我工作」，並他們將獲得參與該項目。

Linus Torvalds的
的Linux時代（2004-10-25）。

來源

2010-09-28 14:33:55

+1，很好找;） – Jimmy 2010-09-28 14:36:19

這取決於你爲什麼這樣做。如果它提供了一些有用的東西，它很有用，並且有其他圖書館沒有的好處，那就去做吧。只需列出狀態和接下來會發生什麼。

如果你這樣做是爲了指向一個簡歷，請將它做好（代碼，不一定是功能完整）。想象一下未來的僱主在代碼中查看它看起來像什麼，而不是下載和運行代碼。

來源

2010-09-28 14:34:20

無論您是否以不完整狀態發佈代碼，始終值得擁有足夠的文檔以允許用戶瞭解如何使用庫....即使它只是API文檔。確保將不完整的東西標記爲TO DO - 它有助於維護目標完成任務列表，並讓用戶知道該功能/方法/任何未被遺忘的內容。

提供一組代碼樣式/標準文檔（可能帶有關於類關係的架構註釋）允許其他開發人員更加輕鬆地貢獻，並以增強庫的方式而不是使其成爲熱門的意大利麪代碼。從不容易發佈一個庫，然後不得不重構，同時爲已經接受並在生產環境中使用該庫的用戶保持向後兼容性。

編輯

不要怕批評......它會與領土。一些批評意見可能是建設性的（注意這一點）。會有很多其他人批評你的代碼（無論他們的理由是什麼），而沒有建設性，或者只是取消你的工作。不同之處在於，您製作了這些商品，但他們可能從未貢獻過任何操作系統產品/庫。

用戶希望您立即解決他們的問題，或爲他們編寫代碼以使用您的庫，或者只是說「不工作」而不解釋其含義。你必須學會和24x7x365一起生活。

但有一段時間，有人會感謝你爲他們節省工作時間或提供有用的東西......突然之間所有的壓力和麻煩感覺是值得的。

來源

2010-09-28 14:41:14

這非常有見地，特別是在如何對待批評。是否應該預期在1.0版本之前保持向後兼容性？ – tplaner 2010-09-28 14:58:59

只要任何用戶事先意識到這些變化，就可以打破向後兼容性...總是下載最新版本的用戶傾向於期望成爲測試人員（儘管事先知道它們在實際情況下是禮貌的） ...否則遵循Freiheit提到的「早期發佈，經常發佈」的公理：然後，您可以棄用舊的方法，在測試版/產品發佈版中提前發佈更改。儘可能確保公共方法輸入和輸出保持不變，但在不能提供的情況下提供預警。 – 2010-09-28 15:10:27

我讀過一篇由Google的市政軟件工程師Joshua Bloch撰寫的文檔，他談論了很多關於最佳API設計的類型。基本上，一旦你釋放它，它或多或少被設置。他說，

公共API是永遠 - 一個機會得到它的權利

您可以檢查出的幻燈片here。這絕對值得一讀。我也有一個PDF格式的文件。讓我知道你是否需要它。

來源

2010-09-28 15:01:53 Steve

什麼時候應該發佈我的代碼？

回答

相關問題