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

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

[[321551]]

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

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

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

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

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

main: input -> output

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

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

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

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

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

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

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

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

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

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

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

也就是說，假如任何 bug 都能被我在一天內(nèi)定位并給出修復(fù)方案，在編程領(lǐng)域我能混成低效的 Type Checker。

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

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

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

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

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

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