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