建站
咨詢
售后
建站咨詢
新聞中心
在某問答平臺有個有意思的問題：假如任何 bug 都能被我在一天內定位并給出修復方案，在編程領域我能混成什么地位?
除開一些搞怪的回答外，有些人覺得，把這項技能用到世界級的偉大項目中，可以創(chuàng)造巨大價值。
我發(fā)現，大家對 bug 的定義是多樣的、模糊的。主要分為兩類：
- 觀念意義上的 bug，即代碼出現任意不滿足人的需求的行為，都叫 bug。
- 程序意義上的 bug，即代碼執(zhí)行時不停機，或者拋出錯誤，才叫 bug。
如果我們圍繞觀念意義上的 bug，去討論這個問題。很容易發(fā)散聯(lián)想，把問題變成超能力的小說創(chuàng)作。
如果我們圍繞程序意義上的 bug，去討論這個問題，會發(fā)現，這個能力實際上在做的，是對代碼進行靜態(tài)分析。即，在不運行代碼的情況下，對代碼的結構進行分析，判斷它是否能正確運行。
Type Checking 類型檢查技術，可以對代碼實現這種靜態(tài)分析。在特定 Type System 類型系統(tǒng)下，推斷出程序接收給定的所有可能輸入，能否正確輸出指定類型的值。
main: input -> output
將代碼簡化成 main 函數看待，input 為參數類型，output 為返回值類型。main 函數執(zhí)行的可能結果如下：
- 接收 input 類型的參數，在有限時間內返回 output 類型的結果
- 接收 input 類型的參數，永遠執(zhí)行，不停機，沒有返回值
- 接收 input 類型的參數，執(zhí)行期間拋出錯誤(output 類型或者內部中間環(huán)節(jié)出現類型匹配錯誤)
根據上述 3 種結果，我們可以對 main 函數或者編寫 main 函數的語言，做出分類：
- function 或 language 的行為包含上述 3 種可能性
- function 或 language 只有第一種行為，即輸出指定類型的 output
我們將第二種稱之為 total 的，第一種則是 partial 的。
大家可以理解為，total 就是所有可能輸入，都有正確類型的輸出，是全量的，無遺漏的。而 parital 則是所有可能輸入，只有部分才有正確輸出，是非全量的，有遺漏的。
回到那個問題，任何(程序意義上的) bug 都能被我在一天內定位并給出修復方案，可以認為等價于低效的 Type Checker 類型檢查程序。
而任何復雜的大型代碼庫，它里面包含的會引發(fā)不停機或者拋錯的類型錯誤，往往數不勝數。
觀念上的一個 bug，它對應的程序意義上的 bug 數量可能是很多很多個。
其中大多數 bug 是無關緊要且瑣碎的。每次花一整天時間，定位到一個低級的類型問題，然后給出簡單的修改，這種效率難以滿足有價值的開發(fā)工作。
因此，從程序意義上的 bug 來看，一天內定位任意 bug，由于 type check 的精確性，極大概率每次定位到的是代碼里首次出現的低級類型錯誤。隨便一個 lint 或 type check 程序，都可以在 1 秒鐘找出代碼里成千上萬的 bug(其中絕大多數是無關緊要，在觀念上不構成 bug，在程序上則構成)。
也就是說，假如任何 bug 都能被我在一天內定位并給出修復方案，在編程領域我能混成低效的 Type Checker。
沒有完備的類型檢查，程序員修復一個 bug 的同時，可能引發(fā)另一個 bug，或者另一批 bug 的出現。
大家的代碼對嚴格的 Type Checker 來說錯漏百出，為什么它們被那么多公司發(fā)布到生產環(huán)境，為什么我們大部分人還能相對正常地使用各種技術產品?
這是因為，盡管用戶數量級龐大，但絕大部分的產品操作流程，訪問路徑，行為數據等等，是同質化的，只占程序的 input 類型的極小部分(如 int 數字類型對應的成員數量理論值為無限，實際值根據不同語言有不同邊界，數量級通常很龐大。發(fā)生數值邊界溢出屬于少數情況，然而一旦遇到，卻是很嚴重的)。
因此，盡管代碼對 Type Checker 來說，是 partial 的，有效的輸入，只有極少部分有正確輸出。但對用戶來說，這極少部分，往往也夠用了。
要寫出 total 的代碼，需要的 type system 能力是可以做數學命題的證明級別的。學習和開發(fā)的成本都相對較高。而用相對不那么嚴謹的語言，用相對不那么可靠的方式編寫代碼，從現實角度，可以更快地構建出在某個范圍內可用的產品，在后續(xù)迭代中不斷擴大可用范圍。
這正是我們能在不完美的代碼中前進的原因所在。
當前名稱：假如我能在一天內解決任意bug……
URL標題：http://m.5511xx.com/article/cccpeop.html
