iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 11
0
自我挑戰組

再戰軟體工程系列 第 10

『出來混,遲早要還的』 -- 工程師心中最軟的一塊:技術債 (下)

不可能不欠技術債

前文中我們其實已經提到了,技術債與金錢上的債務,有很多的共同點。在產品開發過程中,有時候為了搶奪商機,你不得不在深思熟慮後,決定用比較快速的方法解決問題,盡快將產品推上線,以獲取利益。就像開店做生意一樣,如果要累積到一定的資金才要投入市場,那商機早就已經被瓜分掉了,所以在有一定的信因與信用後,就可以利用借貸方式先踏入市場,日後再來償還這些債務。

為什麼這裡會強調深思熟慮這四個字?因為我們其實很常見到一些工程師,明明有足夠的時間與技術,去做出比較好的決定,卻選擇比較欠缺彈性、耦合度比較高的設計框架,導致後續維護成本提高,同事拚命加班幫忙擦屁股,產品擴展速度越來越慢,錯誤率越來越高等。唯有經過成熟考慮的欠債決定,才是我們能忍受的技術債。

技術債需要被管理

如同上一段說的,我們不能認受的,是『幼稚無知的(Naive)』技術債。這樣的債務是無論如何都不可以欠的。容我再說一次:

『幼稚無知的(Naive)』技術債,是無論如何都不可以欠的。

我們能夠容忍的,是策略性的技術債,與草創期不得不欠下的技術債。然而,也像金錢債務一樣,技術債一旦欠下了,就一定要管理這些債務,因為,建立在技術債之上的開發,不只利息重 (工程師的加班費),以後『債上加債』的風險也會更高,等你的產品來到了龐大又笨重的臨界點,你就不得不放棄他又重新再造一次,那個沉沒成本也是很沉重的。

管理的第一步就是要知道我們欠了哪些債。這裡當然大家的管理方式不一樣,有些人特地開啟專案記錄下來,有些人編輯成冊,定期拿出來審視。不管你怎麼做,絕對不可以的,就是這樣放著,讓它隨著時間淡淡而去。接著就是要安排時間償還了。你償還得越快,你就越早進入財務自由的生活,而技術債償還得越快,你每天每天付出的利息就會越來越少。所以,『先還利息高的』則是還債策略的原則。

危險的償還方法

『我們這個月正在做重構』、『我們的xxx產品正準備進行結構性的大重構』這樣的對話,筆者每次聽到都會為對方捏一把冷汗,尤其最嚴重的:『我們OOO功能和xxx功能的連合大重構已經完成了,剛進QA了,等QA測完就可以上線了。』簡直是要用盡畢生功力才可以不當場翻白眼,阿彌陀佛。

為了快速償還技術債,將目前線上正在營運的產品,徹頭徹尾地進行一次大重構,是非常非常危險的作法。這就像你為了盡快還債,於是都不要吃飯,把每個月賺到的錢全部拿去還債一樣,那是會餓死人的!都說要『債務協商』,債務協商就是討論你的收入與債務情形,擬定出一套可行的,不會餓死的方法,這個月還李先生,下個月還王太太,再下個月...,在處理一般債務時,你會分批還款,那麼在處理技術債時,怎麼不會呢?

『打著重構的大旗』,是危險的。為什麼?因為你會有一段時間,也許是一個月或是兩個月,什麼新需求都不能接,不管客戶要什麼,你因為有了『重構』這個擋箭牌,於是在這段時間,產品完全都沒有進度。要知道,重構是解決你的問題,但你的問題客戶關心嗎?不要鬧了,客戶一點也不擔心。

另外,因為你花了很長時間進行大規模的、結構性的重整,影響範圍是很大的。依照工程師的習慣,你花2個月寫的東西,會給QA測2個月嗎?不會的,因為東西寫完丟給QA,你的事就結束啦!QA當然只要給他2周測就夠啦!反正到時候線上出狀況再回頭怪QA為什麼沒測出來就好啦!

但其實最可怕的是,你已經告訴全世界,說這個月我除了重構,什麼東西都不做,你覺得,客戶會這麼體諒你嗎?我業務生意都談回來了,這個宜上線就是多少又多少的收入,你在那邊跟我談什麼軟體工程個屁!現在就要給我做!好啦,老闆都說了,就做唄!於是開了兩條支線,一邊開發新功能,一邊重構舊功能做完還不忘時不時地merge一下,別的客戶看到了,嚷嚷著我也要我也要,於是開出了一個重構支線,8個新功能支線,可憐了妳小小的腦袋瓜兒。

出錯率能不高嗎?

較實際可執行的還債方法

『我們還是來債務協商吧。』

先前說的,你可以造冊管理,慢慢修,慢慢還。造冊管理還不夠,你還得排序,我們在意的不是還了多少條債,我們在意的是怎樣還才可以快速地降低每期的利息。於是,排序就很重要了,先把那些『痛苦指數超高』的拿出來還,再慢慢還那些沒那麼痛的。

還的過程也要注意,在一個sprint中,我們不能整個sprint都拿來還債,我們必須說好一個特定比例,譬如還債時間不可以超過此sprint工時的1/4等。這是『特地安排』還債的情形。那有『不特意安排』的嗎?有,當然有。

有讀過一些DevOps或是Agile相關書籍的人,大概就聽過所謂的『童子軍法則』,亦即,我每次在一個地方紮營,離開後我要把營地收拾乾淨,甚至要比原本還乾淨。這就是最安全又可行的還債方法。舉例,今天你要為了登入葉面增加一個新功能,於是打開後端程式,準備要加一個新method,這時發現原有個兩個函式,有一段長的很像的程式碼,裡面也有些魔術數字,令人不容易閱讀,於是你就順手把這兩段code抽成共用函式,並且在你的新函式裡也引用。不只如此,你還順手幫這些函式都加上了簡單基礎的test case,以確保這個小修正不會導致功能錯誤。
https://ithelp.ithome.com.tw/upload/images/20171225/20107429ppOcQ3d1p4.jpg

所謂的『童子軍法則』說起來未免嫌有些洋派,我比較喜歡另一種說法:『路過幫修』。聽起來不是親切多了?不論怎樣,路過幫修的好習慣,可以在開發新功能時,順便還掉一些技術債,這樣一來,需要特地安排時間還的債就又少了一筆了。


上一篇
『出來混,遲早要還的』 -- 工程師心中最軟的一塊:技術債 (上)
下一篇
『你是在回顧,還是在驗屍?』 -- 談回顧會議的產出
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言