從技術債務的角度, 談談重構

首先, 何謂重構(Refactoring)? 

它的名詞定義是:對軟件內部結構的一種調整目的是在不改變軟件可觀察行爲的前提下提高其可靠性 降低其修改成本.

所以重構在我們眼裏  它應該是這樣的

 

關於技術債務(Technical Debt): 

開發團隊在設計或架構選型時, 從短期效應的角度選擇了一個易於實現的方案.  但從長遠來看,這種方案會帶來更消極的影響,亦即開發團隊所欠的債務。

簡單的說就是爲了快速地解決問題, 而採取的不規範的方案, 從而糟了報應,  哈哈.

技術債務可能會導致我們不能預期交付項目

舉個例子

對於房貸, 大家肯定每個月都記着去還.

但是, 對於技術債務,大家似乎都不那麼關心.

比如某小白同學在一個class中欠下了技術債務,例如不責任的寫了一個15個參數300行的大方法, 之後的幾個星期他對這個類進行擴展、修改,老闆催的急, 錯上加錯, 最終: 一個20個參數, 600行的超級變態method產生了。

然而,這個東西不一定誰借誰還,可能是一個人的事情,也可能是一個團隊的事情,

我們再來假設一下: 這個小白同學離職了.....

那麼,這筆債務就壓在了工作接替者的身上,古人語:父債子償,那麼這個應該就叫:  愛TM誰誰吧.........

用不了多久,整個開發團隊就會發現我們已經無力償還這份技術債務啦,只能重構啦, 而且這個重構還是屬於最難, 代價最大的一種重構方式, 計劃性重構(Planed Refactoring),  也就是不得不將重構計劃加入到產品的backlog裏面.

重構的成本隨着項目進展隨之增加

 

剛纔講了什麼是計劃性重構(Planed Refactoring), 我們接着來說下一種: 理解性重構(Comprehension Refactoring)

直接上圖

直觀的變量名就是最好的註釋

 

這段代碼的註釋是多餘的, 導致了我們理解不夠直觀, 所以我們應該刪掉註釋, 用變量名來直接和變量意義關聯, 簡單直接 !

 

上面的都瞭解了吧

接着來!

 

預先重構(preparatory refactoring)

與重構花費的時間相比, 技術債務纔是時間的真兇! 

大家還記得這張圖吧, 最後走曲線的小球先到達了重點, 所以當我們着手新的feature時, 我們不妨進下心來, 審視下代碼, 是否在coding之前, 先優化一下, 重構一下現有的代碼, 然後再心情舒暢的, 高效率的實現新功能呢?

增加feature之前多想想

 

最後一個

計劃性重構(Planed Refactoring) 它爸爸 

長期重構(Long Term Refactoring)

技術債務已經積累到極其嚴重, 重構需要分配一個開發團隊, 佔用整個一次或多次敏捷迭代才能完成, 這種情況和計劃性重構(Planed Refactoring) 都要儘量避免

長期重構(Long Term Refactoring)不多說 你懂得!

 

碼字不易, 謝謝大家!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章