使用Obsolete屬性

Question

我最近被告知，在我們的代碼中使用[Obsolete]屬性標記了許多方法是不好的做法。 這些方法是我們代碼庫的內部方法，而不是API。 這些方法處理舊的加密功能。

我覺得向團隊的其他成員表示不應該使用這些方法是一種快速而安全的方式，並提供了建議替代方案的信息。

其他人認為我應該完全刪除這些方法，根據需要重寫或重構現有代碼。 此外，人們認為很容易忽視編譯器警告。

當第三方沒有使用代碼時，是否存在將代碼標記為過時的“最佳實踐”？ 或者這主要是主觀的？

Answer 1

步驟1.將成員或類別標記為[已廢棄]

步驟2.更新成員或類的所有內部使用，以使用替換過時方法的新方法，或將該成員或類本身標記為[已廢棄]

步驟3.如果您在步驟2中將新內容標記為[已廢棄]，請根據需要重復此步驟。

步驟4.刪除所有過時的成員和類，這些成員和類既不公開也不被過時的公共成員或類使用。

步驟5.更新文檔以更清楚地描述建議替換任何公共過時成員或類的方法。

最后，您將不會有內部代碼單獨使用的過時代碼。 沒有什么可說的，你必須一次完成所有這些; 在每個階段你都取得了進步。 從開始步驟1到結束步驟5之間的時間可以是5秒或5年，這取決於許多因素（大多數因素與復雜性有關）。

順便說一句，如果有人發現很容易忽略編譯器警告，問題不在於[已廢棄]。 但是，長期不在代碼中留下這樣的調用的一個原因（即，盡可能地完成第2步）是為了確保人們最終不會習慣於編譯器警告，因為他們是編譯代碼的習慣性反應。

Answer 2

我認為這是主觀的。 如果它是內部的並且是一個相當快速的過程，那么我會執行更改。

但是，我也遇到了相應的重構需要花費更長時間的情況（整個代碼庫中的許多調用），在這種情況下我使用了[Obsolete]屬性。 在這種情況下，新開發將使用新函數和任何有時間執行重構的人，直到所有調用都消失，這意味着可以刪除該方法。

Answer 3

這取決於。 是的，您可以重構代碼。 您可以...嗎？

問題是 - youCAN重構在一個程序中。 如果API在公共場所出局並且您根本無法使用API​​重構代碼則要困難得多。 這就是Obsolete的用途。

如果API是代碼的內部API，那么重構就是最佳選擇。 CLean up代碼，不要亂七八糟。

但是，如果公共API發生變化，它應該 - 如果可能的話 - 應該慢慢完成。

其余的仍然是主觀的。 我不喜歡內部API的“過時”。

Answer 4

我之前使用它作為一種臨時狀態，當我們得到的舊代碼最終需要重構而不是緊急時 。 最常見的情況是，編寫了一些新代碼可以比以前更好地完成工作，但是團隊中沒有人有時間回過頭來替換很多舊代碼。 顯然，這意味着一種簡單的直接替換不能立即實現的情況（有時新代碼幾乎完成了舊代碼所做的一切，但還有一小部分功能還沒有實現）。

然后讓所有那些編譯器警告圍繞在一起，不斷提醒有人在他有一點空閑時間后回去完成重構。

這是真的好還是壞都是非常主觀的。 這是一個工具，就像其他任何工具一樣。

Answer 5

這不是一個直截了當的案例。 如果從工作應用程序中刪除方法並重構代碼，則會創建可能性，從而引入新錯誤並破壞正在運行的應用程序。 如果該應用程序對於mision至關重要，那么影響可能會很大並且會給公司帶來很多成本，需要仔細規划和測試這樣的變化。 在這種情況下，標記方法過時可能是值得的，它應該有助於防止人們在進一步開發中使用它們，從而使最終重構變得更容易。 但是，如果應用程序不是mision嚴重或者引入錯誤的可能性很低，那么如果你有時間，重構可能會更好。 最終添加[Obsolete]屬性有點像todo，它的使用取決於許多因素。