技術債和技術稅

想象一下,除了技術債務外,還需要為所欠金額支付技術稅。 每年,工程團隊必須準備一張列出所有應納稅事件的表格:採取了多少快捷方式,由於這些快捷方式而產生了多少小時的運營開銷,等等。這會使軟件工程的工作方式有所不同嗎?

軟件工程中有一個稱為"技術債務"的概念。當您做某事時,您知道不正確,但您仍在這樣做。 正如一些模因所說的那樣,"我們做某件事不是因為它很容易,而是因為它看起來很容易。"所以看起來某件事很容易,(希望)實現它所需的時間更少,但現在卻引起了麻煩。 這是技術債務。

技術債和技術稅

一些項目跟蹤工具將靜態分析工具(例如pmd,findbugs)的輸出視為"技術債務"。方法過長,字符串文字重複,比較複雜等。……這些發現可能很有用, 但是,如果您有足夠的經驗,這種檢查通常很煩人。 而且顯然還遠遠沒有抓住真正的技術債務。 可能會有一個很好的代碼,帶有來自靜態分析工具的大量警告,並且可能有代碼處於技術破產的邊緣,根據同一工具,它的工作令人難以置信。

因此,技術債務很難通過算法檢測出來。 靜態分析工具肯定是由聰明人開發的,如果真是這樣,他們會做對的。

好吧,那什麼是技術債務呢?

什麼是技術債務

儘管彼此之間是相對的,但顯然可以進行衡量:項目" Aurora"比" Bravo"擁有更多的技術債務,但是他們兩個債務的總和遠小於" Charlie"。在這方面,技術債務是類似於人類可能會經歷的感覺和情感:很難以絕對單位說出您對某種咖啡(或茶)的喜歡程度,但是不難給出一個粗略的估算並將其與其他咖啡(或茶)進行比較。

技術債和技術稅

人們也很容易發現技術債務。 通常,您開始一個新項目,然後看到一些奇怪的東西。 您向項目中的某人詢問,答案是:"哦,這是技術債務。 我們開了一個問題來清理它,但還沒有解決。"

這也是積累的東西。 到處走捷徑-很好。 還有更多的切角-看起來不太好,但是該軟件可以完成預期的工作。 儘管進行了下一個更改,但是您可能會發現自己添加了一種變通方法,來變通您之前所做的快捷方式。 為了使它真正起作用,在部署服務時您需要"關閉"更多細節……慢慢地,但是可以肯定的是,您必須花費越來越多的時間在系統中,來解決與您嘗試的實際更改無關的事情 。

技術債和技術稅

尤其令人生畏的是,所有這些快捷方式和變通辦法在您獲得上下文之前都是不可預測,且不合理的。 如果要構建CRUD應用程序,鍵值存儲或字符串處理庫,則在查看實現時可以大致瞭解某些組件的功能。 快捷方式幾乎從來都不是這種情況-通常,您需要對用例有一個很好的瞭解,才能理解為什麼用這種方式來完成事情。

這也是不可避免的。 在大多數情況下,該軟件的存在是為了向用戶添加一些價值,有時並不總是能夠擁有所有資源來交付這一價值,而不是採用捷徑。

因此,技術債務是一組技術決策和實施細節,導致不必要的複雜性,運行時間,開發和運營開銷。

技術利息

繼續講財務隱喻,如果有債務,就應該有利息:花費時間和精力來應對運行和更改充滿快捷方式的代碼所帶來的複雜性。

技術債和技術稅

改變後改變,它遵循複利法則加起來,增加了越來越多的工作。 首先,是更多代碼。 然後,這將需要更多的操作工作:如果啟用了" enable_backoff"標誌-禁用了" experimental_fallout"標誌,如果更改了跟蹤服務中的邏輯-首先請確保更新數據庫中的SQL函數,等等。

該系統變得脆弱,需要更多的時間來解決故障,從而留出更少的時間進行常規開發。 需要更快速的修復來解決緊急問題,從而導致更加複雜。 出現了特定類別的"英雄",即每週加班大膽地撲救火災並從完全災難中拯救項目(或顯著減小爆炸半徑)的人們……

債務沒有什麼壞處

大部分時間都花在撲救火災上的"技術破產"圖景看起來並不好。 但是技術債的問題是,在某些情況下您不必還清債務。

(希望如此)沒有技術收集機構會進行持久呼叫並要求去重構服務以使其不具有共享數據庫。 或者刪除REST協議,並使用適當的RPC工具停止一次又一次地寫入客戶端。 或將一些邏輯移到一個共同的地方(儘管要小心一點)。 實際上,在大多數情況下,如果不涉及技術債務,管理層會很樂意。 令人沮喪的是,要花兩個星期才能移動一個按鈕,但是在哪裡可以保證如果我們花這兩個星期來清理技術債務會更好呢? 當然,我們必須今天支付利息,但是也許我們不需要再次觸碰應用程序的這些部分,還是會重新編寫整個模塊?

在某些情況下,這並不像聽起來那樣瘋狂。 如果利率是10%,但是您可以獲得30%的回報,那麼承擔儘可能多的債務就更有意義了。 一個很好的例子是當主要用戶工作流程和系統設計或多或少地建立起來後便被丟棄的原型。 或者,當產品的成功超過系統的計劃容量時,在開發可處理更大規模的新系統的同時,使系統保持快速補丁可能是有意義的。

但是,即使您不打算很快放棄該項目,也要承擔一些技術債務。 上面的示例描述瞭如果太少注意解決問題會發生什麼。 但是,沒有技術債務就像努力爭取100%的測試覆蓋率:您必須非常努力才能獲得最後的百分比,並且幾乎沒有得到任何回報。

技術債和技術稅

關鍵在天平上。

但是您怎麼知道平衡是否正確? 你沒有,那是不可能的。 因此,兩種策略要麼試圖猜測何時償還某些債務(本質上是賭博),要麼有條不紊地償還債務。

(本文翻譯自Yan Babitski的文章《Technical debt and technical tax》,參考:https://medium.com/swlh/technical-debt-and-technical-tax-839ebd104958)


分享到:


相關文章: