如何維護老舊代碼

咱們在平時的工做中，老是會遇到老舊的系統以及老舊陳的代碼。他們是業務終年累月的積累,以及由於是3、四年前的技術選型形成的系統架構的不合理以及繁瑣的代碼。維護這些代碼老是很頭疼，程序員遇到這樣的代碼老是一邊罵娘一邊憋屈的維護這，維護這些代碼選擇的方式並很少：

• 1.推倒重來，從設計視覺到前端代碼甚至後端接口和邏輯全是新的。

• 2.修舊如舊，既然這麼爛了咱們就讓他更爛吧，反正已經這麼噁心了。。。

• 3.新的邏輯啓用新的架構和技術選型，儘可能減小對舊的代碼的依賴和舊的邏輯的修改

通常來講：第一種選擇老是最好的，程序員最喜歡的，重構麼，你們都喜歡。不過也是工做量最繁重的，它須要從上到下梳理清楚現有業務的全部邏輯，視覺稿，交互稿，文案梳理，邏輯處理，後端接口邏輯以及測試須要迴歸全部的case。當一個系統已經被三四我的維護過，產品經理換了四五茬，後端開發也換了三四茬，文檔不健全，梳理這樣的系統裏的一個模塊都是須要一兩週的，一個系統有十來個這樣的模塊。。想一想就是一個巨量的工做。再加上重構。。。老是會遇到各類阻力的。。。

第二種選擇：修舊如舊，也會有人這麼幹的，「破窗戶理論」嘛，這種方案不發表評論。

第三種方案，算是一種折中的選擇，維護舊的系統大部分狀況下是修修補補，偶爾添加一些新功能模塊。
大體示例以下：

我就在想，能不能經過稍微優雅一點的方式來維護這些老舊代碼呢？好比舊的邏輯代碼咱們儘可能少的改動，對於新加模塊咱們就啓用新的代碼和技術選型，這樣咱們雖然在新舊兩種代碼中穿梭，不過咱們大部分時間都在新的技術選型和架構裏維護代碼。也能夠逐步的梳理熟悉流程，慢慢的把舊的邏輯遷移過來。弊端就是：須要維護兩套代碼，理解兩套技術選型。好處就是隨着新增業務模塊，新的代碼會愈來愈多，慢慢的就把舊的代碼廢棄了。

那麼問題就來了：

新的代碼如何和舊的代碼解耦？

新代碼咱們固然是用新倉庫，新選擇，新打包工具。。。好比：我如今維護的一個系統是四五年前的一直正常的運行，代碼選項是kissy，模塊依賴也是kissy的那一套技術體系，沒有通用的UI控件，打包用的簡單的壓縮，代碼裏還兼容這IE6,7,8。而實際上如今這套系統只跑在chrome上。在如今的視角看，有些東西就能夠捨棄。

新的技術選型是：webpack，vue，ES6之類的，固然這些不是最主要的，最主要的是如何解耦新舊業務邏輯，如何在AB模塊之間插入一個A1模塊。而且這個A1模塊的js不用寫在舊的倉庫裏面，不受舊的技術選型的制約。

重點來了： 發佈訂閱模式(觀察者模式)

觀察者設計模式定義了對象間的一種一對多的依賴關係，以便一個對象的狀態發生變化時，全部依賴於它的對象都獲得通知並自動刷新。觀察者模式-百度百科
具體操做以下：
好比咱們在A模塊操做以後須要A1模塊來處理則只須要在A模塊裏觸發一個自定義事件A1，而後把相關數據帶過去，在A1模塊裏監聽這個事件，作相應處理。示例代碼以下：

// A模塊
function A_active(){
    //balabala...作本身的事情
    $(document).trigger("A1",[data1,data2]);
}
//A1模塊
 $(document).on("A1",function(data1,data2){
     //balabala，作本身的事情
 });

依次類推，你只須要在舊的代碼裏插入諸如

$(document).trigger("A1",[data1,data2]);

這樣的代碼，而後在新模塊裏監聽對應的事件這樣兩個模塊就解耦了。

發佈-訂閱模式弊端

世界上本沒有什麼救世主，也沒有什麼銀彈。。。發佈-訂閱模式並非萬能的，這只是我解決實際項目的一點心得和記錄，發佈-訂閱模式弊端也是有的

發佈者只能發佈事件，並不知道訂閱者有哪些，常年月累,訂閱方可能遍及系統的各個角落。
             ---你終於變成了當初最討厭的那我的--By 高德納-尼古拉斯

解決這個問題：**只能收斂發佈的事件，而且儘可能減小訂閱方，最主要的：文檔，必定要在文檔裏記錄哪些地方有訂閱這些事件，這個文檔能夠是註釋，也能夠是完整的項目文檔。
----未完待續--
https://www.noway.pub/p/101.html