在某問答平臺有個有意思的問題：假如任何 bug 都能被我在一天內定位并給出修復方案，在編程領域我能混成什么地位?

除開一些搞怪的回答外，有些人覺得，把這項技能用到世界級的偉大項目中，可以創造巨大價值。

[[321551]]

我發現，大家對 bug 的定義是多樣的、模糊的。主要分為兩類：

• 觀念意義上的 bug，即代碼出現任意不滿足人的需求的行為，都叫 bug。
• 程序意義上的 bug，即代碼執行時不停機，或者拋出錯誤，才叫 bug。

如果我們圍繞觀念意義上的 bug，去討論這個問題。很容易發散聯想，把問題變成超能力的小說創作。

如果我們圍繞程序意義上的 bug，去討論這個問題，會發現，這個能力實際上在做的，是對代碼進行靜態分析。即，在不運行代碼的情況下，對代碼的結構進行分析，判斷它是否能正確運行。

Type Checking 類型檢查技術，可以對代碼實現這種靜態分析。在特定 Type System 類型系統下，推斷出程序接收給定的所有可能輸入，能否正確輸出指定類型的值。

main: input -> output

將代碼簡化成 main 函數看待，input 為參數類型，output 為返回值類型。main 函數執行的可能結果如下：

• 接收 input 類型的參數，在有限時間內返回 output 類型的結果
• 接收 input 類型的參數，永遠執行，不停機，沒有返回值
• 接收 input 類型的參數，執行期間拋出錯誤(output 類型或者內部中間環節出現類型匹配錯誤)

根據上述 3 種結果，我們可以對 main 函數或者編寫 main 函數的語言，做出分類：

• function 或 language 的行為包含上述 3 種可能性
• function 或 language 只有第一種行為，即輸出指定類型的 output

我們將第二種稱之為 total 的，第一種則是 partial 的。

大家可以理解為，total 就是所有可能輸入，都有正確類型的輸出，是全量的，無遺漏的。而 parital 則是所有可能輸入，只有部分才有正確輸出，是非全量的，有遺漏的。

回到那個問題，任何(程序意義上的) bug 都能被我在一天內定位并給出修復方案，可以認為等價于低效的 Type Checker 類型檢查程序。

而任何復雜的大型代碼庫，它里面包含的會引發不停機或者拋錯的類型錯誤，往往數不勝數。

觀念上的一個 bug，它對應的程序意義上的 bug 數量可能是很多很多個。

其中大多數 bug 是無關緊要且瑣碎的。每次花一整天時間，定位到一個低級的類型問題，然后給出簡單的修改，這種效率難以滿足有價值的開發工作。

因此，從程序意義上的 bug 來看，一天內定位任意 bug，由于 type check 的精確性，極大概率每次定位到的是代碼里首次出現的低級類型錯誤。隨便一個 lint 或 type check 程序，都可以在 1 秒鐘找出代碼里成千上萬的 bug(其中絕大多數是無關緊要，在觀念上不構成 bug，在程序上則構成)。

也就是說，假如任何 bug 都能被我在一天內定位并給出修復方案，在編程領域我能混成低效的 Type Checker。

沒有完備的類型檢查，程序員修復一個 bug 的同時，可能引發另一個 bug，或者另一批 bug 的出現。

大家的代碼對嚴格的 Type Checker 來說錯漏百出，為什么它們被那么多公司發布到生產環境，為什么我們大部分人還能相對正常地使用各種技術產品?

這是因為，盡管用戶數量級龐大，但絕大部分的產品操作流程，訪問路徑，行為數據等等，是同質化的，只占程序的 input 類型的極小部分(如 int 數字類型對應的成員數量理論值為無限，實際值根據不同語言有不同邊界，數量級通常很龐大。發生數值邊界溢出屬于少數情況，然而一旦遇到，卻是很嚴重的)。

因此，盡管代碼對 Type Checker 來說，是 partial 的，有效的輸入，只有極少部分有正確輸出。但對用戶來說，這極少部分，往往也夠用了。

要寫出 total 的代碼，需要的 type system 能力是可以做數學命題的證明級別的。學習和開發的成本都相對較高。而用相對不那么嚴謹的語言，用相對不那么可靠的方式編寫代碼，從現實角度，可以更快地構建出在某個范圍內可用的產品，在后續迭代中不斷擴大可用范圍。

這正是我們能在不完美的代碼中前進的原因所在。