KentBeck:“改善架構”比“還清技術債務”可以帶來更好的感覺,決定和結果。

19-10-28 banq
                   

比爾蓋茨說過:人們不會為修復bug付費,只為新功能付錢。技術債務作為Bug產生的根源,技術債務只是針對開發人員而言,如何能做到向最終用戶收費?創造新的商業價值?KentBeck提出投資改善體系結構或架構,這樣比單純去修復bug、重構等還請技術債務的方式會更好嗎?

眾說紛紜:

商業價值來自:增加收入,保護收入或降低成本。我傾向于找到最好的方法來出售設計的改進。這樣可以更快地添加新功能。[降低成本]這將防止我們在高峰期下降[保護收入]

“技術債務”一詞太籠統,無法采取行動。這是一個很好的概念,但是在討論時間的實際投資時不能使用。

我最近將“軟件重構”重構為“軟件升級”。各方面態度的變化是顯而易見的。

不贊成,技術債務本身是一個錯誤的稱呼。該名稱使非技術決策者的優先級降低。這是錯誤的稱呼,因為干凈,經過測試覆蓋的代碼對企業具有非常明顯的成本和時間收益。

據我所知,“技術債務”是指為發布功能而暫時接受的次優架構。解決以前的技術問題的問題是,我們目前不知道下一個功能需要什么樣的架構。

重構無需計劃,可以隨機完成

我認為,“償還技術債務”的用法如此寬松,以至于在許多情況下它都是模棱兩可的。談論結構和投資確實需要更精確的跟進對話。

長期以來,我一直是這種方法的支持者。它還有助于確定投資地點的優先級,而不是爭論最大的債務是什么。使每個人更容易與產品積壓/路線圖保持一致。

我一直不喜歡“技術債務”一詞。解決實際問題的方法是:設計和體系結構選擇不佳通常是由于缺乏技能和經驗造成的。有時,時間限制是一個因素,但很少會影響經驗豐富的工程師的素質

在這個措詞上不同:關于“還清技術債務”的思考使我感到難過。“投資改善結構”使我感到高興。我喜歡正能量。

我認為技術債務帶有負面含義,這種表述是積極/有動機的。

這是一個區別,但有一個重要區別:“債務”是指為權宜之計而進行的短期入侵;工程上自覺做錯了。

在大型工程組織中,我發現“還清技術債務”實際上并不是一個特別有用的目標-因為團隊可以以此為借口從事幾乎所有工作!如果一個團隊花了三個月的時間將某些代碼重寫為他們喜歡的另一種樣式,這是否是有用的債務償還方法?我更傾向于有針對性的償還債務。到目前為止,我所看到的最好的方法是專注于“擺脫重復的系統”。如果您有兩個系統可以解決一個特定的問題,并且將其合并為一個,那么肯定可以得到改善。而且,向非技術利益相關者很容易解釋為什么擁有一個系統比維護兩個系統更好。(banq注:對于老板而言:重用高于解耦,因為重用可以似乎節約成本,降低人力)

我已經注意到,當“技術債務”出現時,業界的人們會視而不見。我很同情,因為以前不是那樣。大型機上的COBOL將會持續數十年。如今,工具和語言非常分散。我最近嘗試啟動并運行一個受歡迎的node.js應用程序,但是npm只是不斷轟炸廢棄的軟件包。該項目已有2年歷史,并且已經“負債累累”。Java非常擅長于此。在進行拼圖之前,我們有13年沒有接觸過的項目,但它們仍在最新版本上進行編譯。當然,這是有利有弊。

總的來說,我不認為技術債務應該傳達給商人。這是工程工作的內部部分,不會影響用戶。如果愿意,您可以將其視為“封裝”。對外界來說,這聽起來也像是“我們正在抽出時間來解決我們一開始就不愿意做的事情”。那不是* 100%錯誤的...

技術債務應該傳達給商人或用戶,由于業務需求,幾乎總是產生技術債務。需要讓他們知道當時正在產生債務,因此他們知道需要盡快償還。示例:投資者要求一家初創公司從現在起一周內為貿易展覽會實施一項特定功能。如果正確完成,該功能將需要更改數據庫架構,否則查詢將非常緩慢。幸運的是,對于貿易展覽會,要查詢的數據量足夠小,因此無關緊要。但是,一旦開始使用,問題最后還是出現了,需要使管理層意識到這里發生了技術債務。是的,將在最后期限之前完成,并且交付將順利進行。但是最好在時間表上列出待完成事項。

商務人士對債務一無所知,因為企業靠債務經營很普遍。

有趣的一種技術債務是當您意識到對問題的建模錯誤,或者問題已更改并且需要更改模型時。一個簡單的示例是一個權限系統,該系統假定帳戶和用戶登錄名之間是一一對應的。然后,您發現代理機構在概念上是一個帳戶,但具有多個登錄名(每個客戶才能只能看到他們自己的帳戶)。糟糕,這破壞了模型。更改此要求需要數據庫遷移,代碼更改,UX更改等。從概念上來說,這是一個簡單的更改,但意義廣泛。

我只在工程團隊中使用“技術債務”一詞。為了與更廣泛的受眾交流,我使用:“改善產品,工程和運營卓越性”。想法是,更廣泛的受眾關注點是總體收益和成本,而不是我們是否有債務。這句話還使我能夠進行流程更改,從而提高了Tech Debt之外的團隊效率。

您不還清技術債務。充其量,您可以為其再融資。除非您要終止功能,產品或公司。

大多數時候,我聽到程序員在談論技術債務,他們真正的意思是概要分析和性能(因為隨著時間的流逝,需求變更和代碼大小增加)或代碼“清理”,但是技術債務是完全不同的。顧名思義,這是債務,債務意味著不會持久。通常情況下,管理層只是按照計劃表看到了問題,因此無需回頭再“重做”。盡可能地償還技術債務。這將最終得到回報,這只是您這樣做時會感到多么痛苦的問題。

我認為,可能公司需要在管理文化上進行根本性的轉變,然后才能更加認真地對待技術債務。我曾經設法對技術債務做任何事情的唯一方法是隱藏我正在做的事實-因為完全不可能獲得任何程度的管理層支持甚至是許可。其實不必那樣做,我應該得到更高級別的支持,可以與其他開發人員一起工作并擁有勝任的測試人員-在這種情況下工作最終使我不再希望為其他任何人編寫軟件。這是一種無能的疾病,并且滲透到軟件開發行業的眾多機構的管理結構中。

由于生活的現實,技術債務是程序員造成的必然弊端。唯一的問題是,當您開始向他人撒謊時,您可能最終會自己相信。

?

                   

1
美女漫画大全