“我們對計算機的自信可能使我們犯錯誤，因為我們希望將現實世界都轉化為代碼。”
程序員有充分的理由感到自豪，因為其他人是無權進入數據庫並更改的。世界越是依賴計算機定義，程序員的能力就越強。
實際上，沒有什麼代碼是完美的代碼，計算機也會經常犯錯誤。
當然，許多問題源於我們的程序員所做的假設，這些假設雖然在某些時候是正確的，但在根本上是不正確的。正如馬克·吐溫（Mark Twain）所說：“這不是讓您陷入困境的原因，但是您肯定會知道事實。”
編程語言不同
曾經我們也滿是理想，我們曾寫過很長的項目啟動宣言，然後向老闆保證，這次，採用新的語言將改變一切，同時精彩的軟件功能將從鍵盤上快速湧現，以至每個項目都將提前完工。
可是到了最後，我們將數據粘貼在變量中並編寫一些 if-then 邏輯來對其進行測試，慢慢消磨了程序員的夢想。程序員在他們的代碼中看到了結構的偉大之處，並夢想著從中消除所有的低效率。因此，他們稱之為“腳手架”，“平臺”或“框架”，他們希望所有內容都可以用代碼來編寫。哎，下一個任務又具有不同的代碼結構。
最後，所有這些都是技巧和語法上的砂石。結構性消除了編碼壽命的痛苦，直至其逐漸消失。計算機是由晶體管構成的，沒有任何巧妙的標點符號和類型理論可以掩蓋一個事實，即我們所有的代碼都歸結為像一點點摻雜的硅，選擇在代碼中向左或向右向下移動來優化，沒有其他技巧可以逾越。
框架越來越好
也許您是因為對 Vue 中構建的頁面不滿意而在 React 中構建了一個新的 Web 應用程序？還是因為 WordPress 界面笨拙且過時，您將 Ruby 與一些由模板引擎構建的靜態頁面包裝在一起？還是您將所有內容重寫為更小、更新或更酷的產品，例如 Marko 或 Glimmer 或 Ghost？程序員一直在尋找完美的框架，但是像彩虹的盡頭那樣的完美的框架永遠不會出現。
因此，當開發人員創建新框架來修補舊框架的問題並一路引入新問題時，我們會一遍又一遍地看到。如果框架添加了服務器端渲染，則會使服務器癱瘓。但是，如果一切都留給客戶，他們就會開始放慢腳步。每個新功能都需要在時間、代碼和網絡帶寬之間進行權衡。
null 可以接受
弄清楚如何處理空指針是現代語言設計的一個大問題。有時我認為我編寫的 Java 代碼的一半工作是在檢查指針是否為 null。
某些語言使用問號檢查 null 的方法會有所幫助，但這並不能解決問題。許多現代語言試圖通過完全消除 null 來測試問題。如果編譯器告警必須初始化每個變量，則永遠不能設置為 null。
這一發現的樂趣在幾行新代碼中逐漸消失，因為數據結構經常存在信息的漏洞。人們將表單上的行留空、有時數據還不可用。然後，您需要一些謂詞來確定元素是否為空。
如果元素是字符串，需要測試長度是否為零。如果在類型定義上花了足夠的時間和精力，通常可以針對特定問題提出合乎邏輯的建議，至少在有人修改規範之前。完成幾次後，你將開始希望得到一個簡單的單詞，表示一個 null。
計算機可以捕捉人的選擇
性別選擇代碼問題對程序員來說是一個大雷區。計算機處理固定的選項列表和定義明確的菜單沒有問題，但是需求人員不斷更改規則，如一所非常前衛的學校也僅僅是在表單給出了兩種性別選擇。
計算機科學家從來沒有真正解決過這類問題，他們只是添加了另一層間接尋址，在這種情況下，它是指向空字符串字段的指針，人們可以在其中填寫自己的選擇。然後，一些笑話出現，並選擇“ his”作為代詞，這使一些孩子發笑，另一些人則感到冒犯。
此設計失敗模式一次又一次出現。如果您強迫每個人都使用名字和姓氏，那麼有些人將只有一個名字。或者，有人不想被一串 Unicode 字符所認識。而且，如果有人為自己的姓名字符串選擇了新的表情符號，但該表情符號未在列表框列出，該怎麼辦？
Unicode 代表所有文本編碼協議
當委員會經常開會，試圖確定哪些表情符號應包含在人類交流的標誌符號的最終列表中。他們還會拋棄某些表情符號，從而否認某人的感受。
如果全世界都發現表情符號過於侷限，促使他們轉向將文字與文化偶像的圖片混合在一起，那麼任何表情符號列表都足夠嗎？
再就是表情符號字體的問題。一種字體看起來可愛的東西，在另一種字體中可能看上去晦澀而令人不舒服。
人類語言是一致的
開發人員提供的方法之一是在文本字段中供用戶錄入內容，註釋部分是為人類編寫的，很少由算法解釋，因此它們不是問題的一部分。
真正的問題在於帶有文本的結構化字段。當我的 GPS 希望我選擇一條以 Johns 命名的道路時，它會告訴我“轉入 Johns Road”。帶撇號的道路名稱也會使看到“聖約翰之路”拼寫為“聖約翰斯”，“聖約翰約翰”，“聖約翰”，甚至是複數形式：“聖約翰”。美國郵局有一個規範的地址列表，沒有多餘的字符，並且維護著精心設計的算法，可以將任意隨機地址轉換為規範形式，這個非常贊。
時間在世界中是一致的
似乎時間一直在以恆定的速度流動，而且確實如此，所有人的理解時間是一致性。這不是計算機的問題，是人類弄亂了規則 。時間使程序員的生活變得令人討厭，如您可能認為每天有 24 個小時，但最好不要馬上就動手編寫代碼，前提假設的總是正確的。如果有人在美國東海岸起飛並在西海岸著陸，則這一天將持續 27 個小時，看起來是不是很令人抓狂。
時區僅僅是開始。
夏令時會增加和減少小時數，這個在每年某個變化的時間點都會這樣做。如 2000 年美國這一轉變發生在 4 月。今年，美國在 3 月的第二個星期日更改了時鐘。同時，歐洲在三月的最後一個星期日移至“夏令時”。
如果您以為這樣就可以了，那麼您可能是一個厭倦了編寫代碼的程序員。亞利桑那州根本沒有實行夏令時。但是，納瓦霍族（Navajo Nation）是亞利桑那州的重要組成部分，並且確實改變了時鐘，因為它是獨立的並且能夠自行決定這些事情 -- 修改夏令時，確實如此。
但是，等等，還有更多。如納瓦霍人 (Navajo ) 在霍皮族國家（Hopi）內部擁有一塊土地，這使得使用地理座標來準確跟蹤亞利桑那州的時間一致性變得更加困難。
文件是一致的
似乎記住數據應該是計算機可以做的事情。即使文件裡面充滿了許多邏輯、樣式、數字或其他不一致之處，我們也應該能夠恢復。但可能我們甚至都做不到這點。
每當我要求 Mac 檢查文件系統並修復錯誤時，它總是會告訴我文件“權限錯誤”，它們會盡力為我修復文件錯誤。如果沒有我的授權許可，該軟件如何獲得更改我的文件訪問權限？
這只是文件系統無法實現用戶和機器之間的緊湊關係的一個例子。任何程序員都會告訴您，還有數百種其他情況下文件不包含我們期望的內容。數據庫公司確保能夠以一致的方式讀寫數據，這個會給數據庫公司帶來鉅額收入，沒錯，是這樣的。即使那樣，還是可能會出問題，如數據庫高級顧問們會得到了額外的費用來修理已經過時的數據庫表和恢復數據。
我們掌控一切
我們喜歡相信指令告訴計算機該怎麼做。
對於沒有編碼能力的普通非編程的你來說，這肯定不是正確的，但是邏輯和算法代碼對我們來說對的吧？不，我們都是無能為力者，如果你堅持要用機器給我們帶來的一切，如操作系統由操作系統負責，它可能也不會讓我們的代碼獲得執行計算的內容。
如果我們從頭開始編譯 Linux 內核，並僅安裝經過我們審查過的代碼該怎麼辦？那時我們當然可以全面控制。
首先，BIOS 在計算機上是第一個程序，如果 BIOS 出現故障，它可以隱藏地對代碼進行微妙的更改。如果通過遠程訪問運行，則虛擬機監控管理程序將具有更大的權限，這個就出了你的掌控權限。
如果我們用自己的自定義引導程序替換 BIOS，可以嗎？或許可以，但是您的計算機中仍然有許多固件程序需要替代， 如您的磁盤驅動器、網卡和視頻卡等等。
不僅如此，您的 CPU 可能具有“隱藏的上帝模式”，可以讓其他"特殊"指令執行。請不要在文檔中尋找解釋，因為那裡沒有解釋。這些只是應該放在沙盒裡的官方芯片的問題，也可能有人洩露了計劃外芯片，它帶有秘密隱藏程序。
即使是很小的拇指大小的驅動器也具有內置芯片，該芯片具有自己的代碼來做出決定。所有這些嵌入式處理器都被發現藏有惡意軟件。可悲的事實是，你辦公桌下那個電腦主機的晶體管都沒有向你報告這些意外情況。
閱讀更多 InfoQ 的文章
