重複使用與可維護性和易於測試

Question

每個人都喜歡談論可重用性。在我工作的地方，每當有新的想法被拋出或測試出來時，總是會出現可重用性的問題。 「我們希望最大限度地利用我們的投資，讓它可以重複使用。」 「可重複使用會帶來更高的質量和更少的工作。」等等等等。

我發現，當一個可重用的組件或想法被引入時，每個人都立即害怕它，並把它寫成一個壞主意。一旦應用程序依賴它，他們說，它將不可維護，任何更改都將導致需要對使用它的所有內容進行迴歸測試。這裏的人們特別指出了一個已經存在很長時間並且有很多家屬和松雞的組成部分，因爲我們不知道這些變化會發生什麼，所以變得不可能改變。

我對這種抱怨的反應是：

1. 這是很好的變化，有許多家屬組件 是緩慢的， 因爲它迫使設計人員 真的認爲通過改變。
2. 時間應該是首先得到 組件。 Corrollary：如果你總是需要改變它，那麼從一開始就不可重複使用，是嗎？
3. 軟件開發很難，需要工作。測試也是如此。你必須這樣做。

不幸的是，人們在這些回答中聽到的是「慢」，「時間」和「努力」。

，如果有一個神奇的「使這種可重複使用的」開關，我可以翻轉的事情我建立，從而從管理贏得印象分我很樂意，但事情並沒有這樣的。讓一些可重用的東西需要時間和精力，你仍然不能保證正確。

你如何處理與「重用」的請求時兌現它似乎只會帶來的投訴？

Answer 1

1. 只有某些東西實際上會被重用時，可重用性纔是有價值的。在你寫一些可重用的東西之前，確保你有一些實際的重用案例。

2. 即使可重複使用的庫比自己的臨時版本維護起來要困難10倍，如果在10個不同的位置使用可重用的庫代替專用版本，仍然可以節省整體維護時間。

Answer 2

有一件事情，我們經常做的是使用的版本，避免不斷重新測試。僅僅因爲有一個新版本的通用代碼並不意味着所有事情都必須馬上使用新版本。當出於其他原因更新某些內容時，請更新到新版本的通用代碼。

Answer 3

可重用性是使代碼在類似行爲或「IS_A」關係方面可重用。如果你只是想通過一次又一次用看到他們重用代碼塊，但它們沒有類似的特徵，你最好讓他們獨立是鬆耦合的。由此，我們可以有更多的靈活性來稍後修改。