iT邦幫忙

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

再戰軟體工程系列 第 9

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

https://ithelp.ithome.com.tw/upload/images/20171223/20107429aYpMCDIU6H.jpg

琛哥說了,出來混,遲早要還的。工程師出來職場上打滾,不論專業度高或低,責任心好或壞,都或多或少會累積出一些技術債。技術債這種東西,有很多點都跟真實生活中的借貸一樣。當年大師Ward Cunningham提出『技術債』這個概念,而後來因為比喻得太好,而把這三個字變成一個專有名詞,代表那些『因為某種原因,而做了技術上較差,並產生出來一些負面效應的較草率的決定。』

『技術債』的比喻之恰當,就連後來出版的專業DevOps與Agile相關書籍,如Continuous DeliveryEssential Scrum都為此專闢篇幅論述,可見其對技術與品質的影響之深遠。

說真的,技術債這個主題實在是太大,於是我決定把它拆成兩個部分來陳述。本篇會介紹技術債的種類、成因、與影響,而在下一篇。我才會解說對於技術債的管理與修正,有哪些原則與策略。前言至此,那我們就開始吧:

分類

一般我們很常把『技術債』的定義講得很廣泛,而實務上,技術債可以分為三類:

  1. 無法避免的 (Unavoidable):指公司或產品草創期,對於技術與未來發展方向都還不是很清楚,於是不得不做了一些早期決策,雖然後續回頭看起來不事很洽當,但卻是當時的時空背景下不得不的選擇。
  2. 幼稚無知的 (Naive):指在開發過程中,因為團隊的知識不足,要求不嚴謹,或是流程上的缺失,導致在明明有更好的選擇情況下,應是走了技術上比較差的路(大多數是因為這樣比較方便)。
  3. 策略性的 (Deliberate):只在面臨技術決策時,與商業利益衝突(譬如:為了搶奪市場先機),權衡長期利益後做出積欠技術債的決定。

影響

一旦技術債生成,一開始可能沒什麼感覺,但是一旦同樣的商品要再做擴充或是修正時,苦難就來了。大部分的情況下,形成技術債的第一個犧牲對象都是耦合度。為什麼?因為他不影響功能,只影響擴充性,這點我們待會會再聊到。然而,一旦技術債形成,管理上就會變得困難,因為耦合度高,所以交付時間會變得難以預估、同樣的需求的變更成本會變高,成果的可預期性都會下降。同時,你的產品要再順應潮增加新功能時,困難度會比你的同業高出許多,這將使你自市場上很快遞失去競爭力。在越是成熟龐大的產品上越是如此。

對於私人來說,績效當然就降低了。這是你,一個成熟的工程師,樂意見到的嗎?相信不是。

成因

其實由分類就可以看出,有些技術債是不得不然的無奈決定,而有些卻是工程師貪圖一時眼前方便所下的草率決定。上述的第二項:『幼稚無知的』技術債,則是我們一定要避免,並且一旦發生了,就要盡量去修正的。這種技術債的成因有很多,但大部分都可以歸咎成兩種:『假加速』與『對於測試的迷思』。

假加速:

在產品開發時,我們大多會在心中有一個規劃好的功能與框架,然而當時程很趕時,我們經常去『簡化』原定要做的事情。在一個產品開發過程中,『做出功能』與『規劃框架』都是需要時間的。然而,客戶要的功能又不能討價還價,這時候怎麼辦?當然就是犧牲設計框架嚕,因為客戶看不出來呀。

一旦產品上了線,這個被犧牲掉的殘缺框架就會變成永久框架,因為只要他功能不出錯,就沒有人會去改。你的維護成本客戶在意嗎?客戶不在意。於是這樣高耦合又缺乏延展彈性的程式框架就這樣留了下來,形成典型的技術債。

對測試的迷思:

雖然大家都知道測試對品質是有幫助的,但是坊間(尤其是台灣的資訊業)有很多人對於測試卻有一個迷思:『測試會導致延遲』。這件事,我覺得要認真的看待。我記得我在前文中有提到,維護品質是大家的責任。也許你會認為這麼簡單的邏輯沒有必要測,花時間寫測試會耽誤商機。問題來了,不花時間寫測試你怎麼維護品質?難道你要真的像我們經常開玩笑說的:『把客戶當成QA』,就這樣把一份未經測試的程式碼放上產線?

就讓你上線吧,也跑了一段時間,在半年一年後,你能保證所有邏輯你都記得一清二楚?如果不行,你怎麼能肯定每一次在A處的修改或新增功能不會破壞原本B處的邏輯?誰能證明?難道又要叫客戶幫你QA一次?

犧牲測試,或是減少測試,除了把傷害延後發生,以及把不確定品質的商品推出去給客戶測試以外,他並不能真的減少成本,因為你總有一天一定會付出代價的。

不管是假加速,還是對測試的迷思,如果再往下深究,其實發生的時間點,都是在感受到時程的壓力時,所做出來的決定。所以,安排時程時沒有考慮到品質,才是造成技術債的關鍵因素


上一篇
『焦不離孟,孟不離焦』 -- 談增量與迭代
下一篇
『出來混,遲早要還的』 -- 工程師心中最軟的一塊:技術債 (下)
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言