編譯 | 劉雅夢、核子可樂、凌敏
那些年，寫過的代碼終將成為技術債？
1992 年，Ward Cunningham 在敏捷宣言中首次提出了「技術債」概念，主要指有意或無意地做了錯誤的或不理想的技術決策所累積的債務。隨後，《重構》一書的作者 Martin Fowler 基於 Cunningham 的比喻，創建了一個「技術債務四象限」，包括：
- 魯莽 / 有意：「我們沒有時間去設計」；
- 謹慎 / 有意：「我們必須現在交付，之後再處理因為追求速度所產生的結果」；
- 魯莽 / 無意：「什麼是分層？」；
- 謹慎 / 無意：「我們現在知道應該怎麼做了」。
前段時間，Reddit 上有關技術債的話題再次引起程式設計師的廣泛討論。用戶 spo81rtyOP 表示，「大多數軟體的實際使用壽命也就 5 到 10 年。即便軟體能倖存下來，完全由過時技術棧編寫這一現實也會讓它的路子變得很窄。這就是軟體工程師的真實命運。」
創業公司 CTO Matt Watson 則直言，他過去 20 年的職業生涯全是技術債。
Watson 13 歲開始編程，22 歲時創辦了自己的第一家科技公司 VinSolutions，實現了 3000 多萬美元的 ARR，並於 2011 年以 1.5 億美元的價格將其出售給 AutoTrader。離開 VinSolutions 後，Watson 創辦了一家名為 Stackify 的公司，為軟體開發人員提供應用程式監控。此外，Watson 還在菲律賓創辦了離岸開發公司 Full Scale ，以支持他的 SaaS 公司。Watson 透露，Full Scale 已發展到擁有 300 多名員工。
Watson 在博客中提到，當他聽到有人說「我們正在快速開發 MVP，同時最大限度地減少技術債」時，他只是笑笑，因為他知道，最終所有東西都會變成技術債。Watson 在博客中介紹了自己的 20 年職業生涯發生的變化，他悲觀地表示：「如果時間足夠長的話，你的所有代碼都將被刪除。」
1「如果時間足夠長，你所有的代碼都將被刪除」
那些早被遺忘的技術和過時的程式語言
Watson 的職業生涯始於 Visual Basic 6 的開發。從 1999 年到 2003 年，Watson 構建了多個不同的應用程式。後來，Watson 又花了很多時間進行經典的動態伺服器頁面（ASP）開發，自己也成為了在 Internet Explorer 6 和 Netscape Navigator 製作兼容網站的專家。
但在今天來看，Visual Basic、ASP、IE6 和 Netscape 都是早已被遺忘的技術了。
與此同時，在過去的 20 多年裡，很多程式語言也都「失寵」了，比如 Perl、Delphi、Fortran、FoxPro、ColdFusion。也許這些古老的程式語言還存在某些應用程式中，但大多數情況下，還應用這些程式語言的公司必須要對舊的應用程式進行現代化改造，並將其淘汰。如果你用這些過時的程式語言構建程序，最終的結果可能只有重寫，因為很難再找到使用這些語言的程式設計師了。
在 21 世紀初，人們認為 Adobe ColdFusion 是最熱門的產品，但在今天呢？Ruby on Rails 也可能走上 Adobe ColdFusion 的老路，它已經失寵了，並且很難找到使用它的開發人員。曾經 Ruby on Rails 獨有的東西，現在也可以在其他語言中使用了。
Watson 表示，程式語言來來往往，開發人員不希望學習工作中不需要的技能。同時，開發人員跳槽的速度也很快，他們總是希望自己的簡歷上有一些熱門的新東西。
曾輝煌過的 ActiveX、Java Applets、Flash 和 Silverlight
Watson 最初開發的一些應用程式使用了 Internet Explorer 6 中的 ActiveX 控制項。當時，需要用它們來做列印和其他一些非常不安全的黑客工作。PDF 在當時並不常見，用瀏覽器列印簡直就是一場噩夢。
Java Applets 也曾輝煌過，但它運行緩慢，並且在電腦上安裝正確版本的 Java 總是一團糟。Watson 稱自己永遠不會忘記處理 Java 小程序網絡防火牆的噩夢。「我一點也不懷念它們，幸運的是，它消失了。」
此外還有 Macromedia/Adobe Flash。當時 Flash 遊戲層出不窮，許多軟體都是用 Action 在 Flash 中構建的。現在，一個名為 CheerpX 的產品允許使用 WebAssembly 運行舊的 Flash 應用程式。
微軟曾推出一個名為 Silverlight 的 Flash 競品。對於 C# 開發人員來說，這實際上是一個非常棒的框架。Watson 的公司也曾用 Silverlight 構建了一些非常棒的東西。不過後來，蘋果在瀏覽器中放棄了對 Flash 和 Silverlight 的支持，從而終結了它們。
下圖是十多年前，Watson 在 VinSolutions 中使用 Silverlight 構建財務計算器的螢幕截圖。Silverlight 現在早已不復存在，他們用 Java 重寫了它，但 Watson 認為，新版本沒有舊版本酷了。
開發工具的變化有多快？
2004 年還沒有 iOS 和 Android，當時，Watson 曾為 Compaq PDA 編寫了一個應用程式，用於跟蹤汽車經銷商的庫存。它是用 C# 編寫的，用於在 Windows CE 上運行的 .NET Compact Framework 中。
這個 PDA 有一個 100 萬 像素的攝像頭，只要外面是陰天，照片就會糟糕些。這個應用程式很早以前就被淘汰了，但在 2005 年時它還很前衛。
Swift
Swift 是另一個很好地說明開發工具變化速度之快的例子。蘋果公司發布 Swift 後，就很難再證明用 Objective C 編寫代碼是合理的了。雖然在某些用例中仍然需要用 Objective C，但 Swift 明顯更易於開發，並且是向前邁出的重要一步。
Watson 認為，現在任何用 Objective C 編寫的應用程式都可能是技術債了。
WebForms
在為構建 Web 應用程式編寫了瘋狂的內聯腳本之後，Watson 很樂意使用新的 ASP.NET Web 表單，其伺服器端控制項大大簡化了開發。它們的目標是讓創建 Web 應用程式變得像在 Visual Basic 6 中一樣簡單。開發者可以在伺服器端構建可重用的 UI 組件以呈現給瀏覽器，就像今天使用 100% 的 Java 所做的那樣。
WebForms 並不完美，但它是一個相當大的提升。在 Ruby on Rails 出現並普及了用於開發 Web 應用程式的 MVC（Model-View-Controller，模型 - 視圖 - 控制器）框架之前，它一直運行得很好。
MVC 很快就淘汰了開發者製作的所有 Web 表單應用程式。Watson 認為，任何網頁形式的東西都絕對是技術債。
MVC
不知不覺中，每種程式語言就都支持 MVC 框架了。Watson 也曾轉而使用 ASP.NET MVC 做所有的新功能。它無處不在，包括 Django、Laravel、Symfony、Spring 等。
快進到今天，MVC 已經過時了。現在一切都是在 React、Angular、Vue 和其他框架中完成的。在此之前，開發者還會使用 Java 框架。在 Stackify 工作時，Watson 還曾使用過 Knockout，這是一個相當流行的前端框架。
但在今天，還有人記得 Knockout、Ember、Aurelia、Meteor、Backbone、Handlebars 這些框架嗎？它們都「失寵」了，甚至被劃分為技術債。毫無疑問，第一代前端框架輸給了 React 和 Angular。
Angular JS
2015 年，谷歌創建了 Angular，Angular 迅速成為最受歡迎的前端框架。2016 年，Angular 進行了一次重大升級，不再向後兼容。這意味著，原始版本中的任何內容現在都是技術債。
Watson 曾在項目中使用過舊版本的 Angular，如今卻成了他必須升級的主要技術債。
過時的 SOAP 和 WCF
在 REST API 和 JSON 成為事實上的標準之前，另一種選擇是 SOAP，它代表簡單對象訪問協議，主要由基於 XML 的 Windows 通信框架（WCF）來使用。它使得調用 Web 服務並通過自動代碼生成代理類來正確調用服務變得更容易。
Watson 職業生涯中最糟糕的一個項目，就是要弄清楚如何在他的公司和另一家供應商之間通過 WCF 和 SOAP 使用安全證書。SOAP 和 WCF 的承諾令人驚嘆，但隨著時間的推移，維護它簡直是一場噩夢。
微軟決定不再支持 .NET Core 中的 WCF，REST、gRPC 和 GraphQL 現在才是首選。儘管如此，有個社區項目最終使 CoreWCF 得以繼續發展。
隨著時間的推移，開發者用來調用 Web 服務的技術類型已經發生了變化。舊的方式仍然有效，但大多數人可能更願意淘汰它們。
此外還有程式語言的版本更改問題。無論是 Ruby、PHP、.NET 還是其他語言，它們通常需要改寫大量的代碼，甚至是完全重寫。
當 .NET Core 剛發布時，它是專為在 Linux 上運行而設計的更新、更輕、更快的 .NET 版本。基本的 C# 代碼都很容易移植過來，但沒有人會在真實的應用程式中只使用基本代碼。然而，在複雜的企業應用程式中，想要升級時可能會出現許多潛在的問題。這就成為了一筆必須解決的重大技術債。否則，開發者最終會陷在一個古老的版本中。
這些主要版本的更新，最終會成為重大的技術債項目。
Watson 在 Stackiy 遇到的最大挑戰之一是卡在了舊版本的 Elasticsearch 上。有一次，它們對其工作方式進行了一些重大的更改，但這些更改並不完全向後兼容。Watson 的團隊大量使用了它，於是所有的升級工作都變成了海量的技術債和升級項目。
所有的代碼都將被替換
在 Stactify 時，Watson 曾為 6 種程式語言構建了自己的跟蹤 / 測評分析庫，這項工作的工作量令人難以置信。隨著 OpenTelemetry 出現，Watson 過去的這些工作變得毫無用處。既然可以使用開源的行業標準，為什麼還要自己管理呢？Stackiy 正在慢慢地消除那些 Watson 幫忙構建的.NET 測評分析器。
Watson 在職業生涯早期開發的幾個應用程式都已經被終止了，因為這些公司被收購了，並且決定使用完全不同的技術。
Watson 認為，隨著時間的推移，你會看到你創造的幾乎所有的東西都會因為各種原因而被廢棄和替換，或者現在就已經都是基於舊技術的了。大多數軟體的使用壽命都很有限，比你想像的要短。所有的代碼最終都變成了技術債，每個人都想用更現代的方式重寫，或者業務需求發生重大的變化。
誠然，在企業界，更有可能擁有似乎永遠存在的內部應用程式。像鐵路或大型銀行這樣的公司使用同樣的基於大型機的軟體已經有 40 年了。
Watson 預測，WebAssembly 最終會超越當今的前端開發，一個全新的世界將不斷發展。
2一切終將變成技術債？
在做新項目時，大家總是希望將技術債降至最低。但 Watson 認為，不可能不產生技術債，因為根本沒有十全十美的東西。隨著時間的推移，今天完美的東西將來也會不完美，因此，我們需要學會與不完美共存。
而技術債的另一面是，隨著時間的推移，一切都會慢慢「腐爛」——要麼在升級到最新版本方面存在重大問題，要麼由於更新的操作方式而最終失寵。
「一切最終都會變成技術債，否則項目就會夭折。如果幸運的話，你的代碼能存活足夠長的時間，從而成為別人的技術債。如果時間足夠長的話，你的所有代碼都將被刪除。」Watson 在博文的最後說道。
Watson 的觀點引發了很多開發者的討論。贊同者認為自己過去做的很多工作最終都被取代了，辛苦編寫的代碼可能幾年後就沒有了用武之地；反對者則認為不應如此悲觀，因為有些代碼真的可以長青不老。
Reddit 用戶、前幾年剛退休的開發者 vital_chaos 提到，他這輩子在編寫代碼方面投入了 40 年時間，在他參與過的所有技術要素當中，只有一種至今仍在得到實際應用：
「我的團隊從 1988 年起著手開發一款應用程式，直到 1994 年正式開發完成，這就是 Deltagraph。如今，它的持有公司已經在新冠疫情的衝擊下倒閉。據我所知，我做過的所有其他工作最終都被取代了，或者是僱主倒閉，總之成果消失在了歷史的長河中。當然，有些可能仍被使用，這個我也不敢完全確定。
所以我覺得雖然很多事情在做的時候看似無比重要，老闆也總在催促要加班加點完成任務，但事後回頭再看，這些辛苦編寫的代碼很可能幾年之後就喪失了生命力！」
「我的團隊從 1988 年起著手開發一款應用程式，直到 1994 年正式開發完成，這就是 Deltagraph。如今，它的持有公司已經在新冠疫情的衝擊下倒閉。據我所知，我做過的所有其他工作最終都被取代了，或者是僱主倒閉，總之成果消失在了歷史的長河中。當然，有些可能仍被使用，這個我也不敢完全確定。
所以我覺得雖然很多事情在做的時候看似無比重要，老闆也總在催促要加班加點完成任務，但事後回頭再看，這些辛苦編寫的代碼很可能幾年之後就喪失了生命力！」
用戶 spo81rtyOP 也非常認可 Watson 的觀點：「感謝你讓我確定，有這種感覺的不單是我自己。我覺得大多數軟體的實際使用壽命也就 5 到 10 年。之後，因為企業倒閉或者其他原因，軟體被替代的可能性會非常高。即便它能倖存下來，完全由過時技術棧編寫這一現實也會讓它的路子變得很窄。這就是軟體工程師的真實命運。」
用戶 com2kid 表示，他曾於 2008 年前後在微軟工作，當時他看到過一個版權為 1994 年的頭文件，裡面還有作者姓名。搜索後發現，那位程式設計師已經在微軟當上副總裁了。所以他認為，有些代碼真的可以長青不老。
用戶 chesterriley 則想像了一個極端可能：也許未來終有一天，人們會繼續使用 100 年前就編寫出來的代碼。最終的大贏家可能會是 Unix 實用程序或者 TCP/IP 代碼之類，又或者是某些編譯器、運行時引擎或解釋器。還有來自 Linux 或 Windows 等作業系統的代碼。人們可能突然發現，自己修復的錯誤居然誕生自 100 多年前。
也有開發者認為，有些代碼受到當前炒作趨勢的影響很大，而 Web 開發應該就是其中最典型的代表了。考慮到過去二、三十年間 Web 開發領域發生的一系列根本性變化，這種情況也在情理之中。
用戶 Otis_Inf 擁有 28 年從業經歷，他表示，他還記得網景（Netscape）發布背景圖像的那一天，cgi 處理程序中的 Perl 腳本也曾經是常態。無論是當年還是現在，技術的發展速度都相當驚人，開發者必須適應新的做事方式——包括提交給 cgi 處理程序的靜態 html 頁面，也包括異步獲取部分新元素來構成視圖的客戶端渲染頁面。
當然，也有些代碼並沒真正受到當今炒作的影響。有趣的是，這類代碼大多集中在伺服器端。雖然一直有強大的力量在「顛覆」微服務、Lambda 函數等服務構建方式，但如果忽略掉這些實現細節，那伺服器的內存空間裡肯定還有 db+ 服務在運行、也還有空閒周期沒有利用起來。
Otis_Inf 認為，IBM DB2 仍能運行 30 年前的 SQL 代碼是有原因的，這個原因就是組織仍然依賴這些功能。或者說，根本就沒有足夠多的人把它「重寫」成新代碼。那這些代碼是「爛代碼」或者說「技術債」嗎？還是得看具體情況。你家的錘子可能也用了十來年了，它過時了嗎？如果還能幹活，那就沒過時。只有當代碼確實需要變更，但卻沒人處理這項工作時，它才會真正淪為「爛代碼」。
「我希望看到當下誕生的新項目能始終牢記長期可維護性的重要意義，甚至把它當作一項基本設計前提。畢竟真的沒多少人有能力維護陳舊軟體項目。儘管地球人口仍在增加，但掌握足夠技能來維護這些古早軟體的開發者數量一直都跟不上。」
3國內技術從業者怎麼看？
針對技術債問題，InfoQ 曾採訪過國內一些技術從業者。
百分點 CTO 劉譯璟認為，判斷技術債務的重點在於「哪些事情是應該做的」，它是一個因組織而異、因項目而異、因人而異的過程，例如以下一些方面：
- 組織上要求做但沒做的：制度、流程、規範、分享學習等；
- 業務和技術上要求做但沒有做的：功能、性能、安全、高可用、擴展、監控、輔助工具等。
如果按照軟體工程環節分類，技術債務可以分為：需求分析、方案設計、架構設計（邏輯架構、功能架構、數據架構、部署架構、運行架構等等）、編碼、測試、發布等。如果按照產出物類型分，可以分為：
- 文檔類：管理過程文檔、需求分析文檔、設計文檔、測試案例文檔等；
- 代碼類：代碼、腳本、規範等；
- 軟體包類：產品軟體包、依賴軟體、依賴資源等；
- 環境類：開發環境、測試環境、預上線環境、生產環境等。
至於如何決定要重寫還是繼續維護，需要判斷「繼續維護的收益」和「重寫的收益」哪個更大，來決定繼續維護還是重寫。可以綜合考慮如下幾方面的收益：
- 開源：提升現有業務收入、支持新業務的開拓；
- 節流：節省維護人員、節省運營費用；
- 組織：人員結構調整、組織能力培養。
債務是避免不了的，時刻判斷「持有債務的價值」，當價值很低時要儘快處理。
騰訊研發總監王輝表示，如果人力、物力和工期等資源豐富，能去優化的就都可以做到極致。但通常，資源都是不豐富的，或者說是捉襟見肘的，那就要根據實際業務情況來看。騰訊一向的方式是「先抗住再優化」，項目是否真的到了非優化不可的地步，是否真的到了不優化隨時都可能宕機的時候，如果先抗住了，就等業務占領了市場，站住了用戶，到了項目進度慢下來之後，一些優化再開展起來，此時可以要求高可用、高性能、高並發等。
「如果項目資源允許，一些稍微過度的優化和重構，個人認為是可以被接受的，保持團隊的技術熱情是不錯的，但如果資源不允許，就要數著錢花，判斷技術債務的合理性，如何更好的還債，是否真的到了非還不可，是否真的到了影響業務發展，需要與業務優先級一起看，業務錯過一個時間窗就可能永遠錯過，有些技術債務還可以後期再還。」王輝總結道。
參考連結：
https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt
https://www.infoq.cn/article/xgP9W*MC6Svi9Zcqd5KX
https://news.ycombinator.com/item?id=35955336
https://www.reddit.com/r/programming/comments/13ihrtx/my_20_year_career_is_technical_debt_or_deprecated/
中國最大公有雲服務商，如何從零開始構建一支雲效團隊
工信部要求所有 App、小程序備案；某國產電商被提名 Pwnie Awards 「最差廠商獎」；阿里財報超預期 | Q資訊
谷歌的反「背鍋」文化
生成的代碼會出錯、質量差？面對 AI 編程工具的老大難問題，華為這群人打算這樣做
直播預告
8 月 23 日《超級連麥. 數智大腦》將邀請金融行業資深專家，圍繞智能技術如何與金融場景結合，背後涉及什麼樣的技術升級以及 AIGC 等智能化技術落地過程有何挑戰又如何順利推進等話題，分享其在各自領域內的洞見和實踐，為金融業的智能化創新實踐找到更優的解題思路。
掃描下方二維碼預約直播，及時獲取開播提醒！
讀者福利
騰訊技術實踐案例（必備）