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