來看看 Isaac 怎麼談技術債。這原本是一些 tweet，但他後來整理成 blog
最一開始的討論 tweet 是這樣
@copyconstruct What engineers mean by “technical debt” Poor code quality leading to a brittle codebase bad or little to no testing leading to bugs spaghetti code due to rapid feature bloat What CEOs hear: person making 6 figures failing to due their job yet demanding even more resources
@ElleArmageddon IDK who needs to hear this, but: This is not what is meant by “technical debt.” Technical debt is what happens when engineering (and executive) leadership chooses to prioritize net new work over maintaining existing projects.
這原本是在 twitter 上的討論，Isaac 覺得 ElleArmageddon 的回答很不錯，然後順勢寫了這篇文章
很少有話題能像討論技術債務那樣立即顯示出軟體組織中的溝通障礙
- 從業務方面來看，工程師們似乎一直抱怨自己的工作做得不好，而且不理解 shipping 的緊迫性
- 從工程方面來看，充滿了 legacy hacks 的 code 中游走是很糟糕的，這些 legacy 最終會使我們無法向前邁進
在這一點上，senior 工程師的深謀遠慮是
- 對於「商業人士」來說，理解軟體的本質是一個挑戰，所以我們需要找到更好的方法來倡導我們的需求
- 有時包括「對他們撒謊」；說東西會比實際時間長，因為這是一個建立組織凝聚力的好方法
但這有點扯淡
- 「商業人士」往往是能夠理解很多真正複雜的事情，並經常做出涉及競爭利益的困難決定
- 值得考慮的是，如果你不能很好地解釋它，也許是因為你沒有正確理解它
在這些對話中經常缺少的一個重要概念是
- 「技術債」並不是一個普遍的壞東西，而是一系列選擇權衡的結果
- 實際上在很多情況下都是最佳選擇。只有在沒有明確選擇或明智管理的情況下，它才會變得有毒
技術債是
- 當你把「嘗試很多東西」置於「投資於優雅/可維護性」之上時所發生的事情
在軟體開發中
- 優雅/可維護性是有成本的，這就是為什麼你必須投資於它們
- 時間和注意力是有限資源
- 如果你不確定你首先應該建立什麼，為什麼要為它支付額外的費用？
在產品設計的實驗階段
- 最好的辦法是快速搭建出一堆東西
- 設計的方式是很容易替換或移除任何給定的部件，但不一定要讓它容易維護或擴展（甚至理解）
- 如果你真的扔掉了一些東西，那麼在可維護性方面的任何投資都是浪費的
最好的方法是
- 只有當你有足夠的產品驗證時，才切換模式，真正地建立/改進東西
- 也就是說，一旦你知道你要保留的東西，就要償還債務。你把這項工作拖得越久，利息就越多
在可維護性方面的投資應該是這樣做的:
- 其結果是很容易在此基礎上繼續建立可拋棄的實驗
- 關鍵是要承擔大量的技術債，盡可能快地獲得資訊，並且只為重要的產品和功能支付你需要的 cost
做好這點需要保持清晰的觀點:
- 哪些功能仍然是實驗性的？
- 哪些已經被驗證，應該被審查/重構以保證可維護性（或者已經失效，應該被丟棄）？
- 哪些已經脫離了這個階段，可以安全地進一步建立？
我不覺得這些對商業人士來說從根本上說是很難理解的
- 甚至這個詞本身也是一個非常貼切的金融比喻
但是很多時候，工程師（尤其是工程經理）
- 在規劃和管理這種債務方面做得很差
- 因此在溝通所涉及的權衡方面也做得很差，結果是業務經理對他們的選擇了解不多
將公司引向不當的使用技術債的方法是
- 獎勵產品管理部門的 shipping 和
- 獎勵技術領導人的 impact
- 而且，很多大公司都是這樣做的
更糟而且諷刺的是
- 當你把「技術債」當作一個需要不惜一切代價避免的可怕問題時
這就產生了一個巨大的動機
- 去誇大那些尚未驗證的功能的價值，並可能關閉或刪除有價值的產品功能
- 而不是投資於使它們的長期維護成本降低
因此，你會看到 high level ICs 從一個實驗跳到另一個實驗，而不是優化組織和架構
- PM 推動功能設計的工作是為了在下次跟 CEO meeting 中展示，而不是 User 價值
- 而業務領導則想知道為什麼 IC 會如此暴躁(grumpy)
另種失敗模式（有無數種失敗方式！）
- 是過度投資於本應是實驗性的功能的可維護性（no tech debt! tech debt bad!）
- 這代價很高，並增加了公司停滯和失敗的可能性
此外，諷刺的是
- 「沒有技術債」的方法往往意味著長期硬化那些應該為移除或替換而建立的東西
- 這意味著當它們確實需要被改變時，就更難做到了
(健康的 software organizations 都是相似的。每個功能失調的軟體組織都有自己的功能失調方式）
@ElleArmageddon 回覆的最大問題是
- 認為存在某種柏拉圖式的
程式碼品質的理想 - 你越早意識到所有的 code 都是注定要被扔進歷史垃圾堆的臨時垃圾，你就能越早開始做出理性的決定
沒有「高品質的程式碼」"或「低品質的程式碼」這樣的東西
- 把這個想法從你的思維中抹去
- 只有「在特定情況下（而在其他情況下可能不會）做出有利的 tradeoffs 的 software」
下面這兩點是完全不同的事情
- 「通過用現實世界的 user behavior 來驗證功能，找出我們應該建立什麼」的最佳選擇
- 「在可預見的未來有效地提供和維護這個功能」的選擇
而且，應該說
- 所有的 code 都是暫時的，所有的功能都是實驗性的
- 問題是你想賭這個實驗會運行多久
- 在早期對可維護性進行一些投資是非常有說服力的，因為從直覺上來說，在前期進行投資比不進行投資要便宜
- (例如 test）
這種「沒有所謂的程式碼品質」的想法可以讓人大開眼界
- 我們不應該問「這是好的 code 嗎？」
- 我們應該問「這段 code 在做什麼 tradeoff？」
- 什麼情況下這是一個好的選擇？什麼情況下這是一個壞的選擇？我們實際上處於什麼情況？
真正的 10X 工程師 (Isaac: 沒有這種人存在，這是種迷思)
- 是能夠進行這種分析的人，然後確定並規劃出一套針對當前環境進行優化的折衷方案
這就是我們作為工程師應該嚮往的過程
- 對我們產品的所有功能的承諾和投資的適當水平有一個清晰的認識
- 這樣就可以做出合理的決定，知道什麼是需要依賴的，什麼是需要準備拋棄的
- 在與 business 對接時，可以清楚地指出哪些功能是經過強化的，哪些是為了測試預感而臨時拼湊的，等等
我們可以開始詢問 Product
- 哪些東西我們應該丟掉，哪些我們應該投資於加固
- 甚至可以預先設定時間表，說明何時做出這些決定，以及哪些數據將推動這些決定
- 任何產品經理都會為獲得這種可見性和反饋而感到興奮
與其
- 抱怨
The Business不理/不欣賞辛苦工作的工程師 - 或者不得不忍受如「需要多長時間才能 production-ready」這樣的錯誤問題
- 或者不惜以牙還牙為一切昂貴的東西辯護
- 我們反而可以讓整個組織了解現有的權衡，一起做出明智的選擇，並獲得對解決我們面前的問題真正有用的方向
- (當然，前提是我們自己花時間去了解它們)
當然，像大多數突發的軟體問題一樣，這並不那麼簡單
- 當你意識到你有一個問題時，那是因為你有一個大問題
- 但是，從一個混亂的局面中挖掘出來，只是一個採取小的迭代步驟進行改進的問題
對系統的組成部分進行分類
- 確定哪些部分是脆弱的，哪些應該被加固，哪些應該被扔掉
- 構想出你希望你知道你需要的架構，並開始採取小步驟來實現它
- 同時仍然進行試驗，但要睜大眼睛，並有明確的標準和時間表來把它們轉移到非試驗狀態
最後
- 技術債不是由寫 bad code 的工程師或提出不可能的要求的 business leaders 創造的
- 而且它也不總是一個壞主意
- 它是由組織的集體優先事項選擇的，而且只要它得到承認和負責任的管理，它往往是正確的選擇