當我們嚮應用程序中引入新功能時，我們可能會生成工件，例如有用的方法或類，這些工具或類可以在我們的應用程序的其他區域中重用。這些工件不一定記錄爲功能需求，因爲它們通常是我們實施選擇的副作用。由於我們經常在團隊中開發，因此共享這些代碼以防止返工和重複是非常重要的。你如何確保代碼被正確地重用？
例子：
你有什麼發現的最有效的方法分享這些文物？
如何傳達您在創建時所做的假設？
你如何確保它們被正確使用？
我對圍繞文檔，代碼圖，會議（？）的最佳實踐和成熟技術感興趣，以確保代碼被正確地重用。
這個問題非常類似於：Finding Reusable code但我對更主動的反應式方法感興趣。
我們的團隊在整個開發過程中都使用了許多有用的庫。這些庫以「開源」方法存放在公共存儲庫中。有一個人負責監督每個圖書館（或多個圖書館），開發者可以提交補丁。
這些庫隨後被髮布/構建到一個公共位置（我們部署到Web服務器），然後人們可以下載它們並將它們用於他們想要的任何項目。到目前爲止，它工作得很好。我們唯一需要注意的是，如果API發生變化，我們必須確保我們確保每個人都意識到這一點。我們通過版本號和我們的圖書館wiki上的信息來做到這一點。
編輯：此外，我們還爲我們的圖書館（Javadoc，Crystal Report等）發佈生成的文檔，以便開發人員可以利用這些文檔。
用斷言測試你的前置條件。
除此之外，請考慮一些單元測試，以檢查您的代碼是否足夠健壯以處理罕見或意外情況。
其餘的，確保每個人真正理解代碼的功能，至少在黑匣子級別。一旦人們必須開始使用對他們來說是新的代碼，就可以與白板短暫會面並進行一對小小的編程。
我們是一個團隊的.Net，所以這個工作對我們來說...
我們建立了自己的類庫，我們認爲將常用的功能。比如計算一個Luhn Mod 3校驗位，創建一個正則表達式來驗證一個地址，這個地址將適合數據庫字段，這個地址是n字符等等。訣竅是能夠識別可能被重用的代碼並獲得它在那裏。並保持有組織。
還記錄其預期用途以及不打算執行的操作。 – 2009-09-25 03:52:58
好點。我們有一個小團隊和一個可重用代碼的小型庫。我們工作的項目類型非常相似，所以很容易提出有意義和有趣的命名，這有助於自我記錄，但我們確實有額外的文檔，並且我們見面討論新項目時我們想要添加它們。 – David 2009-09-25 04:08:52
我們是一個Java開發團隊，同樣適用於我們。我們在各種標題下在我們的SVN中創建了實用項目，例如XML解析，矢量處理和可重用代碼被檢入這些實用程序庫並在其他項目中重用。
查看關於您的編程語言最佳實踐的書。應用它們，看看有什麼工作，並相應地適應。基本上，一個好的，簡潔的界面/ api會有很長的路要走。也寫很多單元測試來涵蓋不同類型的功能。另外，請查看以您的語言/平臺構建的庫，或者查找庫的良好示例，並查看它們的接口如何。
從完全缺乏此事的經驗說起，理想的情況可能是在團隊之間建立一個共享的版本控制系統。然後，在幾次初始組織/意識會議之後，將共享倉庫視爲人們可以參與的開源項目。所以，看幾個案例：
你寫一些代碼共享：這需要在庫中的代碼創建一個新的區域，增加了一些基本的文檔，測試，代碼清理，等等......但是如果它被認爲是「公開」的話，那麼就有動力做到這一點。
你想使用代碼，它的質量很好：聽起來像一個很好的庫，但有一些限制。您添加更多文檔，測試和額外功能等等。
你想使用代碼，但它的垃圾：您需要與原始開發人員聊天。然後對代碼進行重大修改，但比重新創建輪子稍微好一些。當你完成後，兩支球隊都會受益。
訣竅是使所有的公共知識。所以你需要每個團隊的支持者來推動人們重新使用和貢獻。這是你從第一輪會議中得到的結果。假設開源模式是一種行之有效的做法，如果你擁有冠軍，沒有理由不能工作。
使用SOLID並保持您的代碼清潔。檢查：http://www.lostechies.com/content/pablo_ebook.aspx
如果您看到可能實施的內容，請向團隊求助。永遠記住你對以前項目的瞭解，如果你知道項目x有這個功能，那麼從那裏開始;）
重複使用是重要的，避免重複，特別是當你在同一產品/甚至子系統。重要的是要始終尋找它，但不要讓這阻礙項目的進展。
好問題。 +1 – David 2009-09-25 03:45:23