你如何修改你的代碼？

我發現自己重新審視了我的項目區域，並再次對其進行了細化。當我從頭開始時，通常會發生這種情況，並且根據我的理解，我的代碼和技術會變得更好，因此我會回顧一下我所做的並使其更加強大。這是正常的還是我沒有經驗？你多久訪問一次你的代碼？做優秀的程序員寫一次而不需要改變什麼？你如何修改你的代碼？

來源

2010-11-01 Roman

「這是正常的還是我沒有經驗？」。恰恰相反：你擁有的經驗越多，你會越經常想到：「天哪，我真的需要重組這個......」。 – sleske 2010-11-01 11:45:06

...而且，當我寫這些時，我到底在想什麼。 :) – 2010-11-01 15:57:56

我同意別人的答案，但它也取決於你爲什麼寫代碼。如果這是一個截止日期的特定項目，你可能沒有太多機會。如果可能被其他人重複使用，請確保重構不會破壞他們正在使用的任何內容。如果這是一個長期項目，尤其是社區項目，那麼幾乎可以肯定它需要大量的重構。

我已經寫了一個公共圖書館約13年，經歷過5個半修訂（一個我經歷）。在很多情況下，這是因爲技術已經改進，我爲自己做的事情我現在可以用標準庫來完成。多年來我學到了許多更好的策略。

一般來說，好的重構通常意味着丟棄舊代碼。

UPDATE 現代工具，可以很容易地自動完成很多操作（如更改名稱，包）。專家建議，方法很簡短，所以當你發現你的方法延伸到兩頁時，可以將它重構爲較短的方法。但有時候工具無法幫助，而且你必須創建暫時中斷的代碼。在這種情況下，確保你（a）在工作版本上運行單元測試（b）提交它。進入一個複雜的重構操作很容易，並意識到你已經損壞了很多，你需要回溯。如果您有依賴您的代碼的用戶，請確保您繼續提供他們知道的API。例如，假設你有一個名爲

Date date = getLastUpdate();

常規，你決定（因爲我和許多人都做），其java.util.Date拼命打破。您決定更改爲喬達DateTime但它在這個過程中會很艱難。您可能需要預留一段時間以一次完成。不要將API改爲

DateTime date = getLastUpdate();

創建一個新的接口，如

DateTime date = getLastDateTimeUpdate();

然後標記原來爲@Deprecated

，直到你決定做一個你不應該刪除早期版本新版本（在動態基礎上更改API失去朋友）

來源

2010-11-01 11:24:31

我正在爲一個項目編寫代碼，這將成爲我們業務的資產。我關心的是可擴展性和靈活的架構。我的大多數修改是成爲我想有較少的運動部件。 – Roman 2010-11-01 11:49:04

@Am同意了！如果你可以重新使用像Apache庫那樣的東西，這些東西通常會切割出相當大的塊，並且使其更加強大 – 2010-11-01 12:05:57

好的技術。我會記住的 – Roman 2010-11-02 07:43:08

我會說你沒有什麼可擔心的，檢查你的代碼是正常的，有助於提高你的理解。唯一一次你要擔心的是，如果你正在翻閱相同的代碼並且一次又一次地改變實現。

即使你沒有經驗讓你的手變髒，編寫和測試代碼也會變得更好。

來源

2010-11-01 11:13:06 Robert

通過代碼是好的...只要確保你測試它，如果你改變它（設置自動迴歸測試將是一個好主意）。

此外，如果你正在使用的代碼相同的位在許多地方，把它放在一個類庫，所以你只能把它在一個地方，（因此任何改善只需要進行一次）。

這是正常的嗎？ - 是的（只要它不帶走從其他項目太多時間）

你經常重溫你的代碼？ - 每當我與該代碼再次工作，必須花看它

的時間做優秀的程序員編寫一次，並不需要改變的東西呢？ - 有一種方法可以讓貓變皮，所以這是主觀的。

來源

2010-11-01 11:17:25

我通常會重新審視需要變得更加強大和靈活的代碼。這通常與我試圖做的事有關，這使我意識到我可以使一些更通用和更好的東西。 – Roman 2010-11-01 11:53:11

...好程序員的標誌... – 2010-11-01 15:55:40

我會說這是健康的，並會認爲它是一種良好的做法。重構對於一個好的代碼庫是至關重要的，只要你的測試是好的。

在TDD的週期是：

紅
綠色
重構

來源

2010-11-01 11:19:10 Datoon

你如何修改你的代碼？

回答

相關問題