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

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

[[321551]]

我發(fā)現(xiàn)，大家對 bug 的定義是多樣的、模糊的。主要分為兩類：

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

如果我們圍繞觀念意義上的 bug，去討論這個問題。很容易發(fā)散聯(lián)想，把問題變成超能力的小說創(chuàng)作。

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

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

main: input -> output

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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