保留舊代碼以供參考的約定是什麼？

我有一個新的團隊相當新的小團隊項目，我們嘗試了幾種不同的方法，並在設計中進行了一些重要的迭代。保留舊代碼以供參考的約定是什麼？

我們有一些不應該使用的類，並且有一些類具有ClassStuff和ClassStuffImproved這樣的混亂類。我們擁有SVN，但我認爲不會讓所有的垃圾變得有趣，並且讓人們在歷史中手動挖掘是有成效的。有些事情可能需要重新適當實施，而以前的不力實施將提供參考。不過，我想要打破任何依賴垃圾的東西。即使這些垃圾文件被破壞，我也希望項目能夠建立。

是否有文件夾約定？我是否應該把所有的nucked內容放在一個文本文件中，以便當有人想知道某個類去了哪裏時，至少可以輕鬆搜索到它？

這裏的典型約定是什麼？

來源

2014-01-14 Rick

沒有約定。使用你認爲合適的東西。例如，創建一個'attic'目錄，它具有源代碼根的正常結構。 –

也許創建一個分支，然後將主幹減少爲功能/使用的代碼。根據需要參考分支來重新實現類。 – turbo

如果不應該使用該類（或包含垃圾），我認爲儘快將它從主幹中刪除是您可以做的最好的事情。使用分支/標籤對我來說似乎也是合理的。 –

我使用TortoiseSVN的Repository Browser保存SVN歷史日誌。如果您有最近的SVN服務器，「移至」，「複製到」和「重命名」等操作將使歷史日誌保持原始狀態。請務必在完成這些更改後更新所有簽出（否則，本地更改將很難與新的服務器現實合併）。

您不再使用的文件可以移動到「博物館」或「閣樓」分支（並嘗試將原始目錄結構保留在那裏）。

Apache項目一直在更改軟件包名稱，以指示與以前版本或多或少中斷的新版本（例如，比較commons-lang 2.6與3.2）。在SVN中，您可以通過簡單地重命名trunk中的目錄來完成此操作。我發現它是一個很好的約定：所有依賴舊版本的代碼都會中斷，但可以通過嚮導入語句添加一個字符來輕鬆更新（並且您可以通過閱讀更新後的Apidoc來驗證新版本是否按預期工作）。

根據我的經驗，重新實施垃圾比看起來乍一看更難。我首先在類級別使用@Deprecated註釋來獲取需要替換的類。您的IDE將清楚地顯示廢棄代碼的使用位置，編譯器將顯示警告。在包「版本2」中創建重新實現。然後，您可以像更新從commons-lang版本2更新到commons-lang版本3一樣進行更新。一旦完成此操作，請刪除棄用的類（或包）。
雖然刪除棄用的類時要小心：上次嘗試刪除棄用的類時，我發現對已廢棄的類的依賴性在一個小的和舊的，但至關重要且經過嚴格測試的程序中，並且必須將已棄用的類保留到位保持向後兼容性。

來源

2014-01-14 23:39:38 vanOekel

謝謝。這似乎是一個明智的解決方案和一些有用的建議。 – Rick

我不知道有一個慣例，在我的項目，我只是把它複製到一個新的版本，喜歡的名稱：

MyClass2.java

這樣，我不會進入，當我麻煩導入和舊版本的源文件。我還對MyClass.java的全部內容與/* ... */進行了評論。經過一段合理的時間後，我放棄舊版MyClass版本，並在項目中保留MyClass2。我將它作爲MyClass2，以便它聲明它具有歷史記錄，並且是我的課程的更高級版本，因此可以爲此過程帶來一點樂趣。

我從來沒有見過任何人這樣做，但實踐似乎很直觀。

來源

2014-01-14 19:17:33

保留舊代碼以供參考的約定是什麼？

回答

相關問題