技術債是什麼?

你的工程師跟你說團隊真的需要花些時間來減少技術債。這到底是什麼意思?為什麼他們不能趕緊開發新的功能呢?難道我雇了一群肉腳工程師嗎?

不是這樣的。

我共事過的所有工程師,包括我自己在內,都認為自己的使用的程式碼才是最跟的上潮流的。工程師們最喜歡的消遣就是抱怨他們從離職的同事那裡繼承來的程式碼。如果他們是第一個工程師,並且編寫了所有的程式碼,他們就無法忍受 6 周以前寫的程式碼。他們一邊成長,變得更聰明,並且學到了很多。

那技術債是什麼?

技術債是一種低效率的程式碼,這些程式碼的效率與可維護性比較低,隨著時間的推移,可能會影響效能、或是產生 bug、或是其他維護上的問題(就像是卡債一樣)。因此,忽視技術債長期下來將會使你的團隊在花費更長的時間來完成任務,使產品變得遲緩,有更多的 bug,或者使程式碼難以閱讀。工程師們經常把技術債務看作是一種內在的恥辱,並沒有因為尷尬或難以解釋技術細節而與非工程師公開討論,但這是很不幸的,因為這對團隊的短期和長期績效至關重要。

那麼,為什麼會出現技術債務呢?我將涵蓋四大類,但還有許多其他類別。

趕時間

和所有人一樣,工程師有時也會走捷徑。而且你可能是同謀——還記得你跟他們說「我有一個非常重要的 presentation,如果你們可以再兩週內把這個東西做出來,那對公司會很有幫助。」神奇的是,他們真的做到了!?這並不代表他們平常都在偷懶,也不代表你有高超的說服力或是激勵員工的能力。他們可能只是透過「快方法」而不是「好方法」,從而創造了未來需要解決的技術債務。

「待辦事項」是工程師之間的一個內部笑話。我們對我們的程式碼發表了評論,說「這行代碼寫的不好,我稍後會重新整理一下」,我們完全清楚,沒有人真的會這樣做。五年後,當這位謊言的作者早已離開公司的時候,一些可憐的新初級工程師將會試圖找出一些晦澀難懂的漏洞,並找到那些無法幫助他們的人寫的「代辦清單」註釋。

這是我在大公司和小公司之間看到的最大的差異之一。大公司通常對不完美的程式碼有更少的容忍度,以花費更長的時間來完成任務。為了生存,初創公司必須快速完成任務,而且要想讓某些東西快速執行,最好的辦法就是讓某些東西工作得完美無缺。這也許是正確的商業決定,但請記住,以後你會為此付出代價的。

缺乏重構

隨著新的使用情境,有可能導致現有的程式碼不再理想。你可能聽說過「重構」這個詞。讓我來解釋一下什麼是重構。

假設你正在寫一個包含句子的故事「我昨天去了商店。」。你重新審視這個故事的這一部分,意識到你遺漏了你去商店買蘋果的這個細節。要想解決這個問題,一個簡單的方法就是加上一句話:「我昨天去了商店。我買了蘋果。」好吧,這麼寫也許不是最簡潔的,但至少意思對就好。

但是等等!第二天,你回到你的辦公桌前,意識你漏掉了你買了香蕉的這個細節。但是你真的很忙,一秒都不能浪費,最快的方法就是把句子改寫成「我昨天去了商店。我買了蘋果。還買了香蕉。」

很明顯的,這個句子比較合適的寫法應該寫成「我昨天去商店買了蘋果和香蕉,」這就是重構。

當然這是一個過於簡單的例子,但它實際上類似於工程師在專業環境中工作的方式。修復一個關鍵錯誤的最簡單方法可能是在某個地方新增幾行程式碼。產品經理要求一個新功能?當然,我們只需要在這裡新增一些程式碼。這就像溫水煮青蛙的比喻:每一個小的變化看起來都很好,但最終你會得到一個死青蛙,一個混亂的程式碼庫。

有經驗的工程師會嘗試預測程式碼庫的方向,並確保今天編寫的程式碼能夠適應未來的用例(但這有可能是雙面刃:工程師傾向於花費大量時間來概括程式碼,以處理那些從未實現的複雜的用例)。您可以幫助您的工程師瞭解他們在執行當前工作負載時可能需要考慮的未來計劃。它可以在以後節省很多重複工作。

新工程師

技術債務可能不是由於客觀的糟糕程式碼,而是來自不同的工程師的不同風格。這就像寫一本書,每個段落都是由不同的作者寫的。即使所有的作者都很優秀,這本書也不會很連貫。工程師可能有不同的風格或偏好,這可能導致在整個程式碼庫中明顯不同的聲音。有時,在程式碼的不同部分中,這並不比不同的重音更糟糕,但有時會非常糟糕,以至於新工程師不知道實現新特性的正確方法,因為現有的例子非常分散。

例如,一名高階工程師可能會在一段時間內開始將整個程式碼庫轉換為新樣式的意圖,但隨後工程師被拉到另一個專案中,得到提升,或者離開公司。一名新的高階工程師接管並採取第三種方法,留下三種不同的風格分散在整個程式碼庫中。三個人中的任何一個都會更好。一個新來的初級工程師將很難確定在實現其新特性時使用哪種方法。

缺乏所有權

好吧,有時它可能是蹩腳的工程師。或者,在我的經驗中,更常見的是承包商。如果你知道你不會對程式碼長期負責,你就不太可能花費精力去確保它經得起時間的考驗。他們的動機是把錢花在賺錢的地方; 他們不在乎發生了什麼。即使你有一個高階工程師在監督他們的工作,他們也不能捕捉到所有的東西,或者他們可能在想「這只是臨時程式碼,我以後再修復」。短期承包商也使更多的新工程師面臨不同風格的問題。

非工程師經常看到短期資源約束的解決方案,比如「讓我們外包這個功能吧」。但要明白,工程產出與你付出的時間並不成正比。如果做這項工作的人對你的產品的長期成功沒有既得利益,你未來的工程師就會付出代價。

好吧,這跟我有什麼關係?

如果你對產品的質量和你的工程組織的長期效率有利害關係,請與你的工程領導就技術債務進行坦率的討論。我經常覺得工程師和非工程師之間在質量和速度上存在分歧——工程師們希望花更多的時間去做正確的事情,而非工程師們則在施加壓力讓事情儘快完成——但這不是必須的。如果你相信你的工程師,你發現自己經常為時間線和資源爭論不休,那麼你可以考慮一下,你的工程師可能正在考慮更多地以一種穩健的方式建造一些東西,而不是提前下班。在過去,我發現很難進行溝通,因為“健壯”的細節可能是高度技術性的,所以我用抽象的術語說,這只會使衝突升級。

簡而言之,你得到了你所付出的。特別是在創業的時候,我意識到技術債務有時是可以的,如果它能讓公司渡過難關,讓它活下去,但是你應該鼓勵你的工程師花時間去做他們需要做的事情。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *

*
*