你是否曾經在時間越來越緊迫、壓力越來越大、問題越來越難以解決的情況下，被安排到一個陌生的程式碼庫工作？
我有過這樣的經歷，那可不是什麼愉快的體驗。
這讓我想到工程團隊很少衡量的一種債務。
不是技術債。
更微妙的一點：
理解債務。
我認為理解債務是指系統變化的速度與團隊對系統的理解程度之間的差距。
人工智慧正在加劇這種差距。
人工智慧並非問題的始作俑者。
這個問題在人工智慧出現之前就已經存在了。
團隊一直飽受知識孤島、系統文件缺失、所有權不明確以及「只有一個人知道這是怎麼回事」等問題的困擾。
但人工智慧可能會加速這個問題。
當人工智慧幫助我們更快地編寫、重構和發布程式碼時，程式碼庫的演進速度可能會超過團隊的共識速度。
如果配合強有力的審查、解釋、文件和責任歸屬，這將非常有用。
但如果演變成這樣，就很危險了：
“程式碼改變了，但沒有人真正更好地理解這個系統。”
這正是我想要讓大家更清楚看到的風險。
如果我能以某種方式量化理解債務呢？至少在一定程度上進行近似量化。
我開始探索各種可能影響理解力的變數和因素，無論好壞。
根據我的經驗、與其他工程師的溝通以及我在各個團隊中看到的模式，我開始建立一種評分方法來近似理解債務。
我的目標是幫助工程團隊發現哪些關鍵系統或高度關聯的系統變化速度超過了團隊的理解速度。
什麼是理解債務？
讓我們先從一個更正式的定義開始：
當系統影響、複雜性、依賴關係範圍、變化速度和 AI 輔助變化速度超過團隊的理解、覆蓋範圍、冗餘、文件和人為所有權時，理解債務就會增加。
我的結論並非僅僅基於理論。
我最近在之前的某個團隊中親身經歷了高理解力債務帶來的負面影響。
這是一次令人倍感壓力和沮喪的經驗。
我總是感覺自己落後於人，不得不迎頭趕上。
隨著時間的推移，事故變得越來越嚴重，也越來越難以解決，因為團隊對系統的理解程度太低。
程式碼是存在的。
這些服務是存在的。
票一直在流動。
但人們對該系統的共同認知模型卻未能跟上情勢。
那是一個很難工作的地方。
你總是覺得自己情緒容易激動。
你不僅僅是在除錯故障。
你正在為自己缺乏上下文資訊而進行除錯。
為什麼人工智慧讓這件事現在值得衡量
人工智慧輔助開發非常有用。
我本人也經常使用人工智慧。
但我總是忍不住去想這個問題：
我們是否在提高運輸速度的同時，卻沒有提高理解速度？
因為它們不是一回事。
隨著時間的推移，一個團隊可以寫更多的程式碼，但對系統的理解卻會越來越少。
人工智慧可以幫助產生實作方案、重構程式碼、解釋文件、編寫測試，並加快重複性工作。
但是，如果人工智慧輔助的變更在缺乏足夠的人工解釋、審查、記錄或所有權的情況下合併，理解債務可能會更快累積。
問題不在於：
“這是人工智慧寫的嗎？”
更恰當的問題應該是：
“團隊還能安全地解釋、審查、修改、部署和恢復這個系統嗎？”
債務評分的計算方法
這並非一個完美的數學模型。
這是為了將看不見的工程風險顯露出來，以便進行討論、比較和改進。
從高層次來看，得分結合了兩個面向：
1）系統壓力
這些因素會加劇理解上的不足：
-
高臨界性
-
高複雜性
-
高變化速度
-
高事件敏感性
-
高依賴表面積
-
高所有權集中度
-
人工智慧在缺乏強而有力的人工監管時，存在著極高的加速風險。
2）團隊理解覆蓋率
這些因素可以減少理解上的不足：
-
更安全的修飾符
-
更清晰的解釋
-
更強的審稿人冗餘
-
更好的文件
-
近期更多實務經驗
-
更強的待命熟悉度
-
更好的工程師系統能力評分
所以，大致模型是：
Comprehension Debt =
System pressure
+ dependency pressure
+ ownership concentration
+ optional AI acceleration
minus
human coverage
+ documentation quality
+ reviewer redundancy
+ recent exposure
+ operational familiarity為了偵測危險的漏洞，對關鍵系統執行最小可行覆蓋率檢查。
對於關鍵系統，表格會檢查它是否具備以下條件：
-
至少 2 個安全修飾符
-
至少需要 2 位合格的審閱者
-
文件品質3級或以上
-
近期有3級或以上實際操作經驗
-
值班熟悉度達3級以上
如果缺少其中任何一個，系統就會出現 MVC 缺陷。
即使整體債務評分看起來一般，也應該標記出存在 MVC 差距的關鍵系統。
討論
我非常樂意接受如何改進方法論的回饋意見。
也很好奇：
你們團隊如何保持對程式碼庫的理解？
哪些訊號顯示你的團隊開始對系統失去理解？
您是否注意到，人工智慧正在改變您的系統演進的速度，使其與團隊理解系統的速度形成對比？
我認為隨著人工智慧和自動化技術的加速發展，這將成為一個更大的工程領導問題。
我們在生成程式碼方面越來越熟練了。
但我們仍需在維護共同理解方面做得更好。
取得模板
為了便於理解，我將方法論轉換成了以電子表格為先的模板：
系統理解熱圖
其中包括：
-
系統清單
-
工程師-系統矩陣
-
概覽儀表板
-
風險建議
-
可選的AI加速評分
-
最小可行覆蓋率檢查
-
快速入門 PDF 指南
我非常希望得到回饋。
原文出處：https://dev.to/javz/your-codebase-has-technical-debt-but-does-your-team-have-comprehension-debt-385f
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
