這一篇的契機,其實是很久之前曾在社群媒體看到一張佛系技術債的圖,當時就在代辦事項裡留個紀錄,不過一直都被其他題目插隊 (代表我很 agile,更重要的先寫,精簡 ── 或最大化未完成工作量之技藝 ── 是不可或缺的),但年代久遠,我已經忘記那張圖上有那些文字了,印象中是不看、不找、不改,程式自然會變好的樣子,稱為佛系技術債。
事隔多日,會把這題目再拿出來,是前陣子回母校聽了一場有趣的演講,主講人是《Software Architecture in Practice》、《Designing Software Architectures: A Practical Approach》等知名著作的作者 Rick Kazman,題目是《Finding and fixing Design Debt》,內容主要介紹如何自動化偵測六種設計上的壞味道 (個人覺得還是比較偏 code level 的設計壞味道,無法找出 high level 的 conceptual design 問題)。
演講提到一個重要的觀念,設計債或技術債要能自動化被偵測出來,時時做才會願意修,就好像很多專案會在 CI 上跑 CPD/PMD 或 SonarQube 等靜態分析檢測,提醒團隊整體 code base 的品質如何。這是偏知難行易的情況,知道債在哪就容易改。
提問時間,有一位應該是有在業界待過的男生問道:「我有能力說服我的主管給資源修技術債,但我要如何說服同儕修技術債?特別是他不覺得這段程式有問題?」,業界情況百百種,也會有另一種是團隊知道有技術債,但無奈沒有資源 (或是工程師自己拿下班後的時間)。這是知易行難的情況,其實有點 sense 的開發人員,大概都知道哪裡有技術債...
先不管是知難行易或是知易行難,是否有想過為什麼借用「債」這個詞?一般的生活中,錢不夠,但需要車,於是跟銀行貸款買車 (租車其實也是一種方式,但不夠酷),然後每個月還利息跟本金。車能幫助產生新的價值,所以即便要還利息還是件值得的事。也就是說,我們會為了某個未來可能有助益的目標 (買車),願意欠債去提前去完成,而這個助益的價值高於利息。
但在軟體開發中呢?利息是什麼?在演講中有提到幾個:開發效率降低、產生的 bugs 數變多、開發體驗變差可能導致人員離職等等。一般生活中的利息是錢,白紙黑字很清楚,但上述的幾點卻很難量化。所以很難判斷助益的價值是否高於利息...
自己的觀察是技術債都是選擇來的,只是這個選擇有幾種可能:
無知的選擇。這裡的無知是中性詞,並不是在罵人。軟體開發的領域,技術一直在革新,沒有人是無所不知的,即便是資深的的工程師也會有盲點,只是資歷較淺的工程師通常比較容易做出無知的選擇,因為不知道有更好的設計。這個階段,比較是知難行易,有工具自動化的偵測確實能幫助團隊移除技術債,或是透過 code review,讓資深的工程師有機會介紹更好的設計來避免留下技術債。
當下的選擇。根據當下已知的需求,在眾人討論後做出的合適選擇,但可能隨著時間,業務規模變大或方向轉換,當時的選擇成為了現在的阻礙,這種情況蠻常發生的,但通常是利息開始變重,團隊才會有明顯的感知,能靠自動化的工具時時提醒團隊絕對是好事。
無奈的選擇。之所以無奈,就是團隊知道這樣不好,但可能為了時程,為了快速搶佔市場或是測試市場,團隊只好選擇一個較快但是不好的設計。這是刻意留下的技術債,所以需要一個清單管理這些刻意留下的技術債,日後要安排時間還,但有多少公司確實還債呢?在難以量化的利息前,決策者能否很好地判斷:要欠新的債去追求更大的目標,還是停下腳步來還債?於是,通常是到利息痛到受不了時才決定要還債 (或是工程師自己受不了,用下班的時間還債)。
這裡分享一個故事,大家覺得這是哪一種選擇:
一個小 app,是針對某個知名客戶做的新嘗試,由於不知道之後會有多少客戶會使用,加上要用的客戶很急,於是當時決定以最快速最簡單的方式,要在數天內就交付給客戶,承接的工程師想:至少套個簡單的 MVC 吧?但由於時間會拉長,最後就寫成一團能動的泥球。而這個 app 後來越來越多客戶使用,工程師只好用下班之餘的時間慢慢修改...
事實上,技術債是還活著的公司才需要考慮跟煩惱的,如果產品失敗,公司倒閉了,技術債就不用煩惱了,當然也會有人說:「就是因為技術債才拖垮產品的。」這句話可能是對的,但由於難以量化技術債帶來的影響,沒有充分的證據來證明這句話。因此,我不會說永遠不要欠技術債,畢竟無奈的選擇很常出現。
但是,即便要貸款,也有多種選擇,可以全額貸款,也可以部分額度貸款,技術債也是一樣,排除無知的選擇和當下的選擇,在做出無奈的選擇時,個人的建議是不要 all in,和決策者討論一個平衡點,讓之後還債時能比較輕鬆一點。
特別是某些技術決策一旦決定了,後面要再修改就非常痛苦。像是資料庫的選擇,一開始可能沒有大量的資料,沒有特別的感覺,當資料越來越多,不同資料庫可能遇到的狀況不同,但都會慢慢開始浮現,這時不只程式要轉換很麻煩,光是資料要轉換就是一件苦差事。所以,最起碼,存取資料庫一定要保留抽象層 (參閱閒談軟體設計:Repository)。
另外,便是避免 vendor lock-in,通常技術廠商會提供不少開發上的糖衣,讓使用該廠商的技術時,省去不少工夫或時間,一開始開發效率會很好,但系統流量開始增加後,和資料庫一樣,也是會有奇怪的問題冒出來,此時,如果已經被廠商鎖死時,轉換也是相當痛苦。解決辦法還是一樣,至少留下抽象層隔離 (參閱閒談軟體設計:友善的距離)。
也就是說,不管要欠什麼樣的技術債,切記,抽象層花不了太多的時間 (不是零,也不見得很少),卻可以讓之後要還債時,容易一點。