?譯者 | 布加迪

審校 | 千山

我的一位同事在大型項目代碼重構方面有豐富的經驗，他真誠地與我分享了他如何處理這些繁雜的任務。雖然他做的大部分事情只是堅持不懈地努力，就像在健身房鍛煉那樣，但這對我來說很有意義。本文分享他的秘訣。

1、組織目錄

當你試圖為大型項目重構代碼時，很快就會碰壁，因為你不知道一開始該做什么，于是你轉而開始閱讀O'Reilly的技術類圖書，或者對軟件開發流程或方法（比如TDD和DDD等）產生興趣。如果是這樣，你的策略將以失敗告終。

無論如何，你應該實際做起來，而不是尋找所謂的銀彈。首先何不組織項目目錄？你可以從了解幾個風險入手，因為這么做幾乎不會導致錯誤（bug）。

由于大型項目目錄通常很凌亂，所以你一開始會發現很難掌握類的范圍、類在何處使用。因此，組織目錄可以幫助你在修改類之前了解類在項目中有哪種角色和作用域。

有時，你很難理解某些類的作用。在這種情況下，可以創建一些臨時目錄，比如“legacy”、“garbage”或之類的目錄，并將類文件放入其中。如果你逐漸了解了類的含義，可以將它們移到其他適當的目錄。

2、多寫注釋和文檔

即使你已經不得不做代碼重構，如果仍認為不需要任何注釋以獲得干凈的代碼，那么是時候意識到你的代碼不再干凈了；你要做的就是寫大量注釋，即使它們看起來冗長多余。

你應該在讀代碼時可能會產生疑問的代碼旁邊留下注釋。如果你找到了答案，就應該趁還沒有忘記，把它們作為注釋寫下來。

如果代碼與你執行的當前任務無關，你可能不想留下注釋。不過請仔細想想。如果你不擺脫一種自我強加的約束，你就無法花時間去注釋，也看不到未來開始注釋的任何跡象。請注意，它們只是注釋而已。

接下來，不妨寫你不喜歡寫的文檔。寫文檔對于代碼重構來說也必不可少，盡管這項工作總是讓人感到厭煩，有時甚至讓人筋疲力盡。

你可能過去或現在參與幾個基于“代碼即文檔”這一規則的項目。如果把一項特性換成新特性，你將需要閱讀所有代碼才能理解這項特性的功能。另一方面，如果你有無可挑剔的文檔，完全可以使用理想的編程來實現這些特性。

“好奇怪。既然代碼最終會被重構，我為什么還要寫注釋和文檔呢？”

這種想法是錯誤的。代碼重構是一項持久的工作。你不確定什么時候可以開始，也不確定是否可以憑一己之力開始。有許多注釋和文檔在將來供你和同事閱讀。

3、編寫更多的代碼

這聽起來似乎很簡單，但不是開玩笑。

為了評估工作效率，確認提交和修改了幾行代碼怎么樣？比如說，假設你無法在頭一個月完成100次提交和10000次添加或刪除，那么你可能需要重新審查計劃。

不管怎樣，不妨盡可能關注編程。你不必事先考慮架構、測試、編程規則或之類的事情，因為你可以邊編程邊考慮這些事情。如果你首先正視代碼編寫，就會找到與項目兼容的度量指標。

“你的意思是，我必須一開始就要重寫我寫的所有代碼，是嗎？”

是的，你說得對。如果你犯了錯誤，就重寫代碼。沒有人能夠在不遇到失敗的情況下完成代碼重構。

“話雖如此，還是很難擠出時間寫這么多的代碼?！?/p>

你可能會遇到一些問題，比如辦公室會議太多、項目前期時間太長，或者你自身的技能不足。然而，沒有什么是一蹴而就的。同樣，你沒必要尋找銀彈，只需不斷地努力。

有志者，事竟成。

原文鏈接：https://medium.com/@cafedeichi/massive-project-code-refactoring-tips-4a973c3bcc7f