談談程式碼重構
有時候，當一個重要的專案進展不順利時，就有了重新開始的願望。有時這來自管理層，但通常來自開發人員自己。他們說，如果他們只有第二次機會，並且可以重新開始，那麼他們可以建立正確的系統。
但這幾乎從未發生過。從我這拿走。我見過公司多次嘗試，我可以毫無例外地說，當一個團隊開始用基本相同的方法重建相同的系統時，他們最終會得到大致相同的系統，包括同樣的問題只有這個他們必須維持兩個系統的時間。
傳統程式碼得到了糟糕的說唱。人們害怕接觸它，但它體現了經過時間考驗的業務規則和程式，即使最棘手的遺留程式碼在用於重構系統時仍然具有價值。
重構也很糟糕，因為開發人員和管理人員都不熟悉它。他們不知道有一種安全的方法來重組他們的“泥球”，他們的軟體已變成更易於管理的塊，這些塊可以獨立驗證，因此維護和擴充套件的成本更低。
重構遺留程式碼通常是打破它的過程。它可能已經過程編寫並且工作良好多年，但是，為了改進構建並支援持續整合，程式碼需要分解為可獨立驗證的部分。
別擔心。困難的部分結束了。該軟體做了它需要做的事情，所以重構它實際上只是重組它的問題。這並不意味著它不容易或沒有風險，但有辦法解決出現的問題，而且這些變化帶來的好處往往能給公司帶來競爭優勢。
可以這樣想，大多數軟體都是程式性編寫的，並且採用全域性視角。這對於簡單的程式來說很好，但隨著系統的複雜性不斷增加，我們需要一種方法來管理這種複雜性。
面向物件程式設計為我們提供了一種管理複雜性的方法，它通過採用我們想要建立的行為並將其放在一個“物件”集合中，這些物件可以互動以建立該行為。
通過這樣做，我們將系統的不同部分彼此隱藏起來。面向物件程式不是具有一個全域性視角，而是由一組物件組成，這些物件相互作用以建立所需的行為。
通過將行為封裝到正確的物件中的額外步驟，我們允許我們的系統通過自動化變得更加模組化和獨立可測試，這降低了我們生產的軟體的變更成本。
在大多數情況下，這絕不是一件容易的事。你的遺留程式碼從多年的疏忽中得到了這種方式，它可能需要一些努力來清理它，但如果它已經做了正確的事情那麼通常是重組和重組程式碼的問題所以它在不同的地方但功能仍然存在相同。重新組織程式碼通常比從頭重寫程式碼更直接。
————————————————————
推薦閱讀：