您使用哪些技術來最大化代碼重用？

Question

幾年前，我被告知有關代碼重用的研究。顯然，它發現，平均而言，程序員在搜索要重用的代碼時有7分鐘的窗口。如果他們沒有在該窗口中找到適合他們需求的代碼，他們將自行編寫代碼。

這是在需要仔細管理您的代碼以供重用以確保您可以在窗口內找到所需內容的情況下提出的。

您（個人和組織）如何管理您的源以便重用？ 您是否專門維護重用庫？如果是這樣，你如何索引它來最大化你的命中率？

Answer 1

一個複雜的問題：

• 的代碼的某些部分可以被概括爲庫或API。我們有一個共同的圖書館，能夠及時解決常見問題。通常：驗證，緩存，數據訪問類，日誌記錄等等。

• 某些部分是特定於應用程序的。它們不能一概而論。我們將它們轉換成HowTos並提供內部演示。代碼也可以通過使用易於瀏覽的SCM（在我們的例子中是SVN）進行回收。

• 我們也有一些工具可以生成單手無法回收的代碼，另一方面它們總是相似的（想想調用存儲過程）。

• 配對編程也是傳播現有解決方案知識的有用方法。我們在可能或適當的情況下使用。

• 最後一個技巧是學費。每個編碼器都有一個輔導員來參考。由於導師很少，他們之間有很多共享，這些知識可以自上而下地分散開來。

Answer 2

無情地重構並希望最好。

更新（4年後，希望更聰明）

• 像美國洛特的評論說：注意命名。將這個詞傳播給團隊中的所有'提交者'。良好的名字可以讓事物進行搜索，從而減少重複。
• 有辦法做一些事情，並保持它的可訪問性和可搜索性。
• 爲平均（L.C.D.）程序員編寫代碼..不要聰明，只要簡單就足夠了。 （包括設計模式鞋蹄強迫症和相關障礙）
• 早期採用一套常規，風格，指南，標準等。確保團隊內的買入和合規。 （這意味着每個人都使用標籤（或空格）！）。選擇什麼並不重要 - 目標是代碼看起來應該一致
• 有一個看門人（由團隊尊重），他們會對所有紅旗標誌進行檢查。
• 寫代碼test-first/outside-in。這通常可以確保您的代碼可供多個客戶端使用。（關於上下文無關，請參閱GOOS的子彈）

Answer 3

嘗試使用TDD如果您還不是我的初始repsonse。

我認爲TDD的使用是一個很好的方式來保持代碼耦合低，除其他好處。雖然這固然不會阻止相同的行爲被執行兩次，但當您確定可以刪除重複的區域時，它會更容易。

另一個好處是，TDD作爲循環的一部分有一個消除重複（重構）的步驟。

此外，測試形成了您的代碼文檔的一部分，從而更容易識別重複的行爲。

Answer 4

• 有一個積極支持的框架。

• 瞭解現有的代碼庫/使其他開發人員知道代碼庫。如果你的團隊/公司足夠大，有人知道代碼庫，可以要求指導。

• 文檔，文檔，文檔。未記錄的代碼無用於重用，因爲它理解其內部運作需要太長的時間。

• 有良好的接口。簡單的類型，簡單的結構或類。更復雜的是，它將在另一個項目中使用得越少。

• 優化和調試可重用代碼。在第n次遇到其他人代碼錯誤的開發人員將開始重新編寫已有的代碼。

Answer 5

組織是關鍵。如果名稱空間和智能感知可用，則可以縮小正確的功能並最終找到。如果他們沒有找到他們想要的東西，他們可能會發現一些相近或相關的東西。在一個龐大羣體中混合使用的代碼很容易找到，但人們永遠不會快速找到他們想要的方法。

一致性對命名和位置都很重要。如果您決定在項目中的某個時候改變自己的風格，請返回並更改所有內容以適應該風格。它可能很容易是一個漫長而無聊的過程，但它比嘗試使用不一致的庫更好。

Answer 6

剖析整個應用程序，並從較重的代碼部分開始重構。

使用分析工具具有能力來識別內存泄漏，千呼萬喚， 冗長的電話，unfreed內存，未予處置資源等（80％的時間上的最常用的代碼20％花在）,.

通過規則，新代碼總是使用最佳實踐。

Answer 7

你（個人和組織）如何管理你的源代碼使得 更容易重用？你是否專門維護重用庫？如果是這樣，你如何索引它來最大化你的命中率？

我不和我在這裏有一個公認有爭議的觀點，但我覺得最大化代碼重用適得其反（我解釋「最大化」作爲優先考慮它上面所有其他的事情，而不是將其視爲的想法有利弊平衡考慮）。我寧願讓團隊中的大量冗餘工作順利進行，以便更好地解耦和隔離每個開發人員的模塊。首先大家纔開始跟我不同意左右，我認爲我們可以在一些事情上意見不一致：

1. 重用bug的代碼，將有你花了幾個小時的調試別人的代碼是不可取的。
2. 重複使用代碼來平衡如此廣泛的不同需求，以至於它幾乎不能滿足您的需求，並要求您跳過很多環節以最終獲得尷尬和低效的解決方案，這是不可取的。
3. 重複使用不斷需要設計更改的代碼，並且需要每隔6個月重新編寫一次代碼才能重寫代碼，這是不受歡迎的，如果您可以在半小時內自行實施解決方案，由於它只能滿足您的確切需求，因此未來需要進行設計更改。
4. 一個用外表代碼填充的代碼庫是不可取的，它比使用更多的語言和標準庫的慣用和熟悉的方法，即使這需要更多的代碼。
5. 開發人員將彼此的腳趾踩在一起，因爲他們都希望在同一設計中做出不兼容的變化，同時爭吵和爭論，以及在彼此的實現中引起錯誤的變化是不可取的。
6. 將一大堆依賴項投入到尚未經過驗證的未成熟設計（沒有全面的測試覆蓋率，沒有時間真正隔音設計並確保其有效滿足用戶端需求而無需進一步設計更改）是不可取的。
7. 必須使用最複雜的構建腳本來包含/導入/鏈接一大堆庫和類/函數才能寫出簡單的內容，這是不可取的。
8. 最重要的是，重複使用代碼的方式在短期和長期運行中花費的時間遠遠多於不重複使用的情況，這是不可取的。

希望我們至少可以就這些觀點達成一致。我發現通過過度熱心的同事最大化代碼重用的問題是，它經常會導致上述一個或多個問題。代碼重用不是直接的熱情，而是重要的問題，但優先級偏向於代碼重用，而不是測試覆蓋率，隔音設計，確保事情足夠成熟，然後才能像瘋了一樣重用它們等等。

當然，如果我們重複使用的所有代碼都能夠很好地工作，並且具有全面的測試覆蓋率，它被證明可以滿足所有使用它的需求，這種方式的效率遠高於不重用它的效率，而且不需要經過任何多年的設計變更，我會對代碼重用感到欣喜若狂。但是我的經驗經常發現，在代碼重用被認爲成爲維護問題而不是解決方案的情況下，這種理想遠遠不能滿足這種理想。

你（個人和組織）如何管理你的源代碼使得 更容易重用？你是否專門維護重用庫？如果是這樣，你如何索引它來最大化你的命中率？

因此，我不打算在團隊內部編寫的專有代碼中「最大化」代碼重用。我試圖確保團隊不會花費大量的時間在冗餘的工作上，但是如果物理學家和渲染人員都實現他們自己的軸對齊的邊界框類，例如，我會讓事情滑動很多。這並不一定是多餘的，因爲物理學家可以使用對他的目的更有效的最小/最大表示，而渲染開發人員可以使用中心/半尺寸表示。我儘量確保儘可能多地重用標準庫，因爲這是代碼重用的一種，實際上可以保證實現穩定，超級測試，並且不需要進一步的設計更改（其他團隊正在花費一定的時間的時間來確保這一點）。

相反，我把重點放在測試上。一個模塊複製一些代碼在這裏和那裏是完全沒問題的，如果你問我是否能夠讓用戶真正開心，有完整的測試覆蓋範圍，並且不保證無盡的變化。當我們使用第三方庫時，我們總是接受這種重複，這些第三方庫可能會複製我們在內部代碼庫中也有的一些代碼。當冗餘不會導致冗餘維護時，這不是問題。

因此，我建議只放寬一點點最大化代碼重用的想法。但是，如果您想盡可能簡單地重用真正可靠，經過充分測試的非重要代碼，那麼我發現它更有助於組織非常單一用途的庫，如「數學」庫， 「圖像」處理庫等 - 而不是試圖將它們全部融合到「核心」或「普通」之類的東西中。後一種類型傾向於誘使開發者投入各種折衷的效用函數，這些函數幾乎不會讓團隊使用它們，而且大多數情況下它往往變得雜亂無章，以至於難以找到任何有趣的東西。