2008年3月14日 星期五

將技術債務視覺化

技術債務(Technical Debt)這個詞是Ward Cunningham提出的。當程式設計師為了時效,用一個又快又髒,後續維護成本卻很高的作法解決問題,後續需要多做整理,我們就說他是負債,後續該整理的工作就是"債務"。例如不當地使用copy-paste、做出超複雜沒人懂得的if-else分支,或是該寫註解而沒有寫,都是典型的例子。用"債務"一詞是非常好的比喻,教我們處理技術債務就像處理財務上的債務的方法一樣。

怎麼說呢?我們先想想房貸有什麼特性︰

  1. 會讓我們早幾年住到一間舒適的房子,但是我們要長年背負著每個月負擔高額利息。
  2. 有能力的話我們可能會選擇大額清償,還本金要一次拿出很多錢,但是之後負擔的利息就輕鬆多了。
  3. 如果有一期還不出來,再去刷卡借錢來還,之後的利息就又更高了。
  4. 萬一債越欠越多,信用破產,會轉向地下錢莊借高利貸,以債養債。有一天黑道會在停車場堵你,摀住你嘴巴,用車門夾你手指要你還債。
現在我們看看技術債務︰
  1. 會讓我們快一點做出功能,但是專案後續的延伸跟維護要持續付出較高的成本
  2. 情況允許的話,我們儘早做翻修與重構。短期要付出一些成本,但後續延伸與維護的成本會降低。
  3. 如果你現在要改的程式碼本身就一團亂,不過時間很趕你不能好好處理,你被迫用另一個又快又髒的方法改,就像在違章建築上再蓋一層違章。之後延伸與維護的成本又比原來更高了。
  4. 如果我們堅決不處理技術債務,反而一層一層加蓋違章建築,開發進度變慢而且不穩定。整個系統到處都是未爆彈,工程師用拆彈專家的心情熬夜趕程式,團隊因壓力情緒緊繃到極點。deadline越近,系統問題越多,客戶也越來越不安。

有感受到這個類比的巧妙之處嗎?所以該怎麼對待技術債務,也跟對待財務的債務很像。我們知道房貸不是壞事,早點有個安穩的家對事業與家庭都有幫助。只是要謹慎處理。貸款買房子要量力而為,不是籌得到頭期款就放心大膽地買下去。因為現在能買不表示未來養得起。

對待技術債務的正確態度也是一樣。有智慧地用一些技巧趕進度,會讓專案運作更順利。因為遵守時程會增加與客戶及主管的信任,早點做出功能也能提早跟客戶溝通,驗證可行性。只是要記得適時的翻修與重構。技術債務不能累積過多,累積過多可能造成未來無力清還利息。

貸款買房子,讓你看起來“擁有”一間房子,別人因為你的房子而誤以為你經濟狀況很好。雖然你窮到為了還利息,三餐吃泡麵而且沒錢坐公車。只要你沒說,別人不知道。在軟體專案裡,工程師做了又快又髒的處理的話,如果沒有說出來,專案經理不會知道,以為一切順利,而太過樂觀地計算專案進度。

所以工程師一旦製造了債務出來,應該要將技術債務視覺化,將它做成大家看得到的具體項目。讓專案經理知道這個債務,能納入專案計畫中。千萬不要只在原始碼中埋一句註解:"這段程式很亂,需要再翻修"。依照你的團隊管理專案的方法與工具的不同,還債的工作可以是列在一張列表上,或是工程師的待辦事項中,或是直接排進MS Project裡面。

技術債務視覺化是個很重要的專案管理技巧,本來是隱藏在系統中神秘問題,現在變成專案團隊可以共同管理、計畫與解決的工作事項。專案經理隨時知道負債量多少,就不會錯估專案時程與進度。

在文章最後我要誠實地承認一點,如同Martin Fowler指出的,技術債務有一點跟財務的債務不同,就是難以量化。理財你可以用計算機或excel找出最適合你的財務規劃︰要貸款多少,幾時做大額清償,清償多少金額。但是技術債很難量化。你可以估算還債refactor的工時,但是你很難估算不去翻修的話,未來六個月你要多付出多少成本。這一切還是要靠經驗、專業判斷跟一些賭注。但我個人的經驗是,即使不能夠量化,將它視覺化也對專案管理有非常大的幫助。

沒有留言: