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

banq發表於2019-10-28
架構

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

 

相關文章