始終保持高質量的代碼庫
對於軟件開發人員來說，維護良好的代碼庫是他們自己的回報，例如個人的Monalisa或禪宗花園。 工作很愉快，很容易上手並易於理解，擁有這種獨角獸的團隊通常可能會更有生產力。
使每個人都熟悉代碼
軟件永遠不會"完成"，因此重要的是要保持最新的"最新"形式以有效地使用它。 如果團隊中的每個人都在代碼庫中四處尋找改進的機會，那麼很可能有一個以上的人看到了它的晦澀之處，並且可以在該部分發生問題時提供幫助。 這對於已經建立了很長時間並且看到多個團隊成員來去去去的大型代碼庫尤其重要。 重構和隨時待命是我可以想到的兩個最強大的工具，可以在所有團隊成員中傳播有關代碼各個方面的廣泛知識。
建立下一代架構
每個人都希望微服務對嗎？ 如果您揹負著泥濘不堪的巨石，那麼您很可能迫不及待想要將其分解。 但是如何安全地做到這一點？ 大型，毛茸茸的野獸帶有觸角，您甚至可能都不知道。 誰知道分解模塊會做什麼？ 實際的劃分很簡單，這是我們必須要警惕的無法預測的結果，我們不希望最終出現分散的泥濘球！
有一種確定的方法可以設置它-開始重構此舊代碼庫。 您將學到一些您不知道的代碼，以前會出現混亂的邊界，各個部分之間的依存關係將變得更加清晰，錯誤將被發現和消除，性能將得到改善。 您將比往前更深入地瞭解去往何處。 誰知道呢，也許到此為止，您將不希望使用微服務，因為您將擁有一個很棒的超高效整體。
最重要的是，企業將繼續保持這一切！
即使我們正在使用新代碼，連續重構也顯示出代碼中正在出現的邊界和行為，而這種洞察力使更大的體系結構更改成功的可能性更大，因為我們並不需要" this-sucks-lets- 重寫一切"的心態，但源於解決實際業務問題的代碼庫中出現的實際跡象。 經驗豐富的開發人員通常可以確定這些模式，並組建團隊進行有力的更改（例如，將該模塊拆分為單獨的服務，讓斷路器放入中央客戶端庫中）。 當團隊中的每個人都在進行重構時，越來越多的人開始獲得感知即將到來的變化的第六種感覺。
如何持續重構
有許多方法可以做到這一點，並在互聯網上提供大量建議。 我想集中在兩個方面，一是技術方面，一是組織方面。
編寫測試
經常重複的建議經常被忽略的輔助手段是-編寫測試。 重構並不存在某種技術真空中，而是一種實現組織目標的手段。 我對此有不同的看法，但對我來說，目標是提高運輸速度。 我們今天所做的應該使未來的更改更快/更容易/更安全。 現在，如果我們同意今天的重構可以促進未來的變化，那麼擁有可測試的代碼就可以促進重構。 我們不必只考慮更改代碼，也可以考慮添加測試。 我們可能不進行重構，但是由於進行了額外的測試，因此其他任何人明天都可以安全地進行重構。
寫作測試就是重構
如何抽出時間
"我們永遠不會有時間"。 我同意，這是可悲但真實的。 獲得排他的重構時間需要很多信任，尤其是在那些實際上沒有破壞（但可以改進）的代碼部分。
我更喜歡廣泛使用的"緩衝您的估計"方法。 要求額外的一天來完成任務。 無論如何，重構您要修改的內容都比較容易，利益相關者抱怨一兩天的估算值的可能性較小，而且我們將能夠不斷地減少成本。 這比分別為"僅技術"更改分配時間要容易得多。
這樣做還限制了我們將花費多少時間進行重構-它將使情況變得更好，但僅在資金來源的給定業務功能範圍內。 在這種情況下，我們沸騰海洋的可能性要小得多，因為有一個更大的目標要實現-您僅重構當前正在使用的內容。
如果您喜歡這篇文章，可以訂閱我的郵件列表以獲取最新消息。
通過連續重構節省一天的時間
您之前是否遇到過這種情況？
· 開發團隊不斷縮短功能交付的截止日期
· 它通過發送負債累累的代碼來回應
· 這種技術債務永遠都無法償還，因為永遠沒有時間清理
· 轉到1幾次
· 直到真正開始阻止新的變化或破壞生產中的技術債務，情況才會惡化
· 開發人員團隊需要進行重大的重新設計，因為當前系統已無法節省成本
· 這將花費很多時間，但是業務團隊將最終獲得與魔術無異的技術保證
· 通過擱置其他所有內容來執行重新架構
· 它花費的時間比想象的要長得多，而產生的效果卻差得多
· 轉到1幾次
· 業務團隊對開發團隊失去了全部信心，並返回使用excel / Company關閉
不幸的是，上述事件序列太普遍了。 儘管有很多原因和許多相應的措施可以防止這種情況，但我想看看開發團隊可以做什麼。 對我來說最大的問題是反覆進行大的重新架構。 像初創公司一樣，大型重新設計大多會失敗。 他們無法控制範圍，無法兌現承諾，無法提升組織的能力，甚至往往根本無法完善。 一個真正敏捷的組織如果發現自己需要如此大的一次性更改，應該感到驚訝-無論是逐步發現和實施解決方案時發生了什麼！
但是，開發團隊可以採取一些措施來防止這種情況的發生，那就是採用一種持續重構的文化。 除了衝刺，混亂或日常站立之外，連續重構還可以通過改善開發人員的工作方式（即代碼庫）使開發團隊變得敏捷。
馬丁·福勒（Martin Fowler）寫了一本很棒的書，寫了許多有關重構的文章（包括關於詞源的有趣的註釋），所以我想我們都知道它是什麼。 讓我們跳入為何我建議"連續"重構的原因。
結論
在我看來，期望團隊"顯然"會進行連續重構是不公平的。 這並不明顯，面對交付功能的壓力，它很少成為優先事項。 它是一種文化，與所有文化一樣，應該明確地談論，討論和鼓勵。 如果我們能以使事情每天都變得更好的方式來解釋我們的工作，那麼收益的累積就會非常快。
(本文翻譯自Kislay Verma的文章《Saving the day with continuous refactoring》，參考：
https://medium.com/swlh/saving-the-day-with-continuous-refactoring-a59314f6f753)
