新公司的第一個任務-重構系統(二)

     先簡單說一下感想，重構系統的這半個月，我感受本身的髮際線在慢慢變高。

 按本來的計劃我是要求領導給我一個熟悉這份代碼的人跟我一塊兒結對重構，可世事難料，那我的總共和我結對不到一天的時間，後面就離職了，後面就是我一我的孤單的一我的在重構。

 個人思路本來是先將大的UI、主業務邏輯、數據庫、設備控制解耦，再將各個模塊與業務解耦。這套系統全部的模塊功能都集成到一個類中，基本沒有將數據與功能分類，全部的變量命名徹底沒有可讀性而言，沒有文檔，沒有註釋，可想而知我沒辦法先將各個模塊解耦，而且這樣一會兒腳步太大全部的東西都耦合在一塊兒，容易出現未知的問題，查找起來也麻煩。

 因此我決定先主業務邏輯中各個子業務邏輯剝離，在剝離的過程當中我發現這套系統最大的兩個問題，一個是亂七八糟的數據太多，另外一個是代碼全都是複製粘貼，徹底就是一個失控的系統。通過半個月的重構我將主業務邏輯能剝離的都剝離出，剩下一下耦合很差解開的就放到最後解決，至於單元測試我沒作，我打算在第二輪重構各個模塊時再作，緣由是咱們如今只是簡單的消除重複以及將相關功能歸類，若是作單元測試的話後面測試用例改動太頻繁不過我有對主要功能進行調試。

 在此次重構中讓我印象深入有兩點，一個是破窗戶另外一個是溝通。

破窗戶：

    我第一次那麼深入的意識到，破窗戶竟然能夠大到如此地步，一我的一旦開始複製粘貼後面的人全用複製粘貼，這實在是過於嚇人。

 大部分的人都會隨波逐流，在好的代碼環境下編碼也模仿的有模有樣，在糟糕的代碼環境下讓代碼變得愈來愈糟糕，即便是工做有必定年限的人也是如此，他們一般不會說本身這樣寫出來的代碼有多差，而是說他們以前就是這樣寫的。

 因此我認爲咱們應該在代碼出現壞味道以前就重構它，不要像系統崩壞後開發維護成本很高的狀況纔去重構它。

溝通：

     在重構的過程當中，因爲這代碼真的是寫給機器看的，因此我會比較頻繁的跟相關人員溝通，可是我發現他們不是很願意溝通，我須要想方法引導他們才能獲得我要的答案，一份寫給機器看的代碼與不肯跟你溝通的同事，可想而知重構這份代碼的難度，我自認爲閱讀代碼的能力還算能夠，由於有常常看一些開源代碼，但這短短不到3W行的代碼競讓我如此爲難。不僅是我同事，新公司大部分的人在作事方法及溝通上都存在比較大的問題，他們老是沒有將一件事情高效的溝通完成，而在推卸責任或是對人不對事，這一點咱們新來的一些人都是如此認爲的，跟我同一批進來的一些同事卻是挺優秀的。

 我對面部門的一個領導剛來十天就離職了，我以爲他是個大牛，對軟件開發過程理解很是透徹，作事方法還有溝通方面真的作的很是好，技術方面我不敢判斷，但從作事方法還有溝通我就以爲這人是個大牛，這我的離開確實惋惜了，我想他應該是以爲這部門帶不起才走的吧。