只要在軟體開發圈子混一段時間，尤其已經有系統 run 在 production 環境上，十之八九會聽到這句廣為流傳的經驗談：「
東西沒壞就不要修。」
這句話，常常被反對重構（
refactoring）者掛在嘴上。
朋友在看到我上一篇『
TopDown or BottomUp』的文章，對我說：「
這年頭能找到願意重構的人真是太少了。」
常有人以為做軟體工程跟蓋房子這種建築工程相似，若是這樣，想像你所居住的房子像是個搖搖欲墜、像是比薩斜塔的危樓，主結構樑柱都腐爛破損，但遮風避雨的主要功能還是有，要住人也是可以，偶爾漏水放個水桶也過得去。但住在這樣的房子，你真的覺得可以『不用修』嗎？
覺得這個例子很誇張嗎？但事實上在軟體圈內，在光鮮豔麗的使用者操作介面背後，系統經常就是這樣充滿壁癌的海砂屋重新油漆粉刷牆壁而成，原來你以為的樑柱內其實是沙拉油桶堆立起來的模樣，
這間房子之所以還能使用，只是剛好達到一個巧妙的平衡，只要多加一點或少一點，就可能瞬間坍塌。而負責維護這間危樓的人，自然會充滿著「東西沒壞就不要修」的想法。
『
技術債』這個詞在軟體工程界已經行之有年，但是在台灣，似乎只有很小圈子內知道這個概念，而高層一點的管理者、專案經理，根本不知道這些債常常都是為了他們而欠下的，而欠債還債，這種原本天經地義的事情，卻往往變成呆帳。
高層主管總是抱怨、或是不理解，為何他想改一個功能，或是加上一個新需求，工程師會如此面有難色，掙扎很久，然後報出一個出乎他意料很多的人日成本？尤其該系統活得越久，後面提出修改的人日成本就會越來越高，做出來的穩定性也越來越差。
因為技術債的利息正在發酵。
當東西越來越難改的時候，就代表已經欠下『技術債』。
技術債的產生，通常是開發人員受迫於專案壓力下妥協的產物，可能是挖東牆補西牆，因而破壞了建築結構；可能是便宜行事，臨時改用不合規格的劣質建材；也可能是臨時挖出一條地圖上看不到的地道或水路，讓專案需要的物資通行。
而當底下的工程師開始說出經典名言：「沒有壞的東西就不要修。」代表債臺高築已經瀕臨破產邊緣，
因為工程師已經失去可以安心修改調整的自信心。
一個系統剛建立時，往往是結構分明、邏輯最直覺清晰易懂的時候。隨後歷經各種需求調整，如果不是跟隨調整整個架構設計，往往會變成『硬塞進去』的異類，
將不同的邏輯放入同一個系統內，開始逐漸形成所謂的『例外』。隨著這種架構上『例外』的增加，系統越來越艱澀難懂，任何一個修改的需求提出，工程師不再有把握能夠正確預測與知道所需的代價成本。這個時候，充滿無力感的工程師會陸續離職，新人進來缺乏交接也更不可能勝任，終於變成 legacy system，老闆最後只能
打掉重練。
時常『重構』，是維持系統新鮮活力的必要活動，隨時保持系統整體的設計方向是符合商務直覺，盡可能消除『例外』的設計，達到一致性，才能真正減輕工程師的生理與心理負擔，保持需求修改的直覺與穩定性，同時減少不開心的工程師流動率。
內心 OS：推行重構最難的魔障，往往是看不到乾淨易懂的程式碼的業務單位⋯⋯。
留言
張貼留言