當您使用的圖書館不再維護時，您會做什麼？

Question

我總是發現一件令人沮喪的事情是，當我使用的圖書館不再維護時。即使事先查看更新歷史記錄和社區，我也遇到了稍後檢查發現我使用的版本是最新版本的情況。

一般而言，直到幾個月過去了，或者發現了一些錯誤/限制之後，這種情況才被忽視。在Python編碼時，我經常遇到這種情況，因爲我希望升級到新版本的解釋器，可以很容易地引入之前工作正常的庫中的問題。我的問題是：對這種情況最好的迴應是什麼？

• 你成爲舊圖書館的維護者嗎？即使你只是在修復你關心的錯誤，這仍然是一個很大的工作。特別是如果庫很大，很複雜，並且沒有足夠的文檔記錄（這種情況通常比較少）。

• 您是否切換到不同的庫（如果有）？這也是一項重要的任務，可能會引入新的錯誤，特別是如果唯一的替代方案從另一個角度解決問題。即使您有先見之明地爲舊庫的功能編寫抽象層，情況也是如此。

• 你自己玩嗎？它可能會比舊庫更少的代碼，因爲你只寫了你關心的部分。因此在未來更容易維護。但是現在你已經浪費了幾天/幾周/幾個月的時間來生產可能功能較差的東西，並且保證會引入大量的新bug。

我知道，答案取決於具體情況：該庫的大小，來源是否可用，它是如何維護的，你的代碼量有多大用途，你的代碼是如何深深依賴於它，等我正在尋找各種案件的答案。你對這個問題有什麼經驗？

Answer 1

嗯，你已經找到了一個說法，以減少外部依賴的數...

我遇到這幾種Java項目我已經審計;似乎人們傾向於放棄在Web上某處找到的Jar，以便從中獲得儘可能少的重複使用。結果是一堆混亂的依賴，最終破壞了代碼庫。我更喜歡少用外部元件。

這可能是最有用的問你可以做什麼之前。在開始使用它之前着重評估外部組件的未來生命週期。對開發者社區和用戶社區的規模做一些研究。此外，更喜歡使用一個有一個或兩個「較少」替代品的組件，您也可以使用它。

如果有些東西是你想要使用的，但它只有一兩個人在工作，並且在自己的項目之外使用得並不多，那麼你應該推出你自己的 - 或者與維護者聯合起來的組件。

Answer 2

當我的僱主選擇的Java EE框架陷入困境時，我們走出去找到了一個更新，更好的框架。幸運的是，Spring可用。

Answer 3

如果源代碼可用，許可證已打開並且庫很好地執行了這項工作，則可以選擇分叉庫。通過這樣做，您也可以爲其添加新功能。如果圖書館有很多事情需要解決，而且代碼亂七八糟，那麼最好還是找一些其他方法來處理。

Answer 4

我認爲你的真正答案是你如何選擇第三方庫包含在你的代碼中。

如果你碰巧喜歡不斷的代碼升級到語言的最新版本，那麼在默認情況下，你只能使用有其背後活躍的社區圖書館

其實我會去遠的話說，只有您希望使用第三方開源庫的時間是當它背後的社區很大（比如說至少有40多個用戶）並且它已經經歷了幾次發佈時。

對於商業圖書館來說，同樣的事情適用於公司需要多長時間以及有多少其他客戶使用它。

如果你在這個位置找不到圖書館，那麼確保你將第三方圖書館從你的代碼中抽象出來，這樣在未來更換並不困難。

Answer 5

我們寧願因爲這個原因推出自己的產品。我們最終完全控制它，完全知道它是如何工作的，我們可以以任何我們想要的方式改變它。當我們的屁股上場時，我們更喜歡降低風險，並自己動手。

我們曾經有一種情況曾使用過外部庫，並被作者改寫和重新利用，而不再做我們所期望的。我們翻了一遍，寫了我們自己的版本，然後安全地繼續。

底線是安全，風險最小化。