1. 技術債 筆記

1.1. 什么是技術債

1992 年, Ward Cunningham 在敏捷宣言中首次提出了"技術債"概念, 主要指有意或無意地做了錯誤的或不理想的技術決策所累積的債務。隨后, 《重構》一書的作者 Martin Fowler 基于 Cunningham 的比喻, 創建了一個"技術債務四象限", 包括:

• 魯莽/有意: “我們沒有時間去設計”;
• 謹慎/有意: “我們必須現在交付, 之后再處理因為追求速度所產生的結果”;
• 魯莽/無意: "什么是分層? ";
• 謹慎/無意: “我們現在知道應該怎么做了”。

1.2. 討論

前段時間, Reddit 上有關技術債的話題再次引起程序員的廣泛討論。用戶 spo81rtyOP 表示, “大多數軟件的實際使用壽命也就 5 到 10 年。即便軟件能幸存下來, 完全由過時技術棧編寫這一現實也會讓它的路子變得很窄。這就是軟件工程師的真實命運。”

與此同時, 在過去的 20 多年里, 很多編程語言也都"失寵"了, 比如 Perl、Delphi、Fortran、FoxPro、ColdFusion。也許這些古老的編程語言還存在某些應用程序中, 但大多數情況下, 還應用這些編程語言的公司必須要對舊的應用程序進行現代化改造, 并將其淘汰。如果你用這些過時的編程語言構建程序, 最終的結果可能只有重寫, 因為很難再找到使用這些語言的程序員了。

在 21 世紀初, 人們認為 Adobe ColdFusion 是最熱門的產品, 但在今天呢? Ruby on Rails 也可能走上 Adobe ColdFusion 的老路, 它已經失寵了, 并且很難找到使用它的開發人員。曾經 Ruby on Rails 獨有的東西, 現在也可以在其他語言中使用了。

Watson 表示, 編程語言來來往往, 開發人員不希望學習工作中不需要的技能。同時, 開發人員跳槽的速度也很快, 他們總是希望自己的簡歷上有一些熱門的新東西。

Watson 預測, WebAssembly 最終會超越當今的前端開發, 一個全新的世界將不斷發展。

用戶 chesterriley 則想象了一個極端可能: 也許未來終有一天, 人們會繼續使用 100 年前就編寫出來的代碼。最終的大贏家可能會是 Unix 實用程序或者 TCP/IP 代碼之類, 又或者是某些編譯器、運行時引擎或解釋器。還有來自 Linux 或 Windows 等操作系統的代碼。人們可能突然發現, 自己修復的錯誤居然誕生自 100 多年前。

當然, 也有些代碼并沒真正受到當今炒作的影響。有趣的是, 這類代碼大多集中在服務器端。雖然一直有強大的力量在 “顛覆” 微服務、Lambda 函數等服務構建方式, 但如果忽略掉這些實現細節, 那服務器的內存空間里肯定還有 db+ 服務在運行、也還有空閑周期沒有利用起來。

“我希望看到當下誕生的新項目能始終牢記長期可維護性的重要意義, 甚至把它當作一項基本設計前提。畢竟真的沒多少人有能力維護陳舊軟件項目。盡管地球人口仍在增加, 但掌握足夠技能來維護這些古早軟件的開發者數量一直都跟不上。”

1.3. 國內技術從業者怎么看?

百分點 CTO 劉譯璟認為, 判斷技術債務的重點在于"哪些事情是應該做的", 它是一個因組織而異、因項目而異、因人而異的過程, 例如以下一些方面:

• 組織上要求做但沒做的: 制度、流程、規范、分享學習等;
• 業務和技術上要求做但沒有做的: 功能、性能、安全、高可用、擴展、監控、輔助工具等。

如果按照軟件工程環節分類, 技術債務可以分為: 需求分析、方案設計、架構設計(邏輯架構、功能架構、數據架構、部署架構、運行架構等等)、編碼、測試、發布等。如果按照產出物類型分, 可以分為:

• 文檔類: 管理過程文檔、需求分析文檔、設計文檔、測試案例文檔等;
• 代碼類: 代碼、腳本、規范等;
• 軟件包類: 產品軟件包、依賴軟件、依賴資源等;
• 環境類: 開發環境、測試環境、預上線環境、生產環境等。

至于如何決定要重寫還是繼續維護, 需要判斷"繼續維護的收益"和"重寫的收益"哪個更大, 來決定繼續維護還是重寫。可以綜合考慮如下幾方面的收益:

• 開源: 提升現有業務收入、支持新業務的開拓;
• 節流: 節省維護人員、節省運營費用;
• 組織: 人員結構調整、組織能力培養。

債務是避免不了的, 時刻判斷"持有債務的價值", 當價值很低時要盡快處理。

騰訊研發總監王輝表示, 如果人力、物力和工期等資源豐富, 能去優化的就都可以做到極致。但通常, 資源都是不豐富的, 或者說是捉襟見肘的, 那就要根據實際業務情況來看。騰訊一向的方式是"先抗住再優化", 項目是否真的到了非優化不可的地步, 是否真的到了不優化隨時都可能宕機的時候, 如果先抗住了, 就等業務占領了市場, 站住了用戶, 到了項目進度慢下來之后, 一些優化再開展起來, 此時可以要求高可用、高性能、高并發等。

"如果項目資源允許, 一些稍微過度的優化和重構, 個人認為是可以被接受的, 保持團隊的技術熱情是不錯的, 但如果資源不允許, 就要數著錢花, 判斷技術債務的合理性, 如何更好的還債, 是否真的到了非還不可, 是否真的到了影響業務發展, 需要與業務優先級一起看, 業務錯過一個時間窗就可能永遠錯過, 有些技術債務還可以后期再還。"王輝總結道。