編程須謹記：大象不咬人，蚊子卻致命
本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。
1996年6月24日，歐洲航天局的阿麗亞娜5號無人火箭在發射僅37秒后爆炸。三億七千萬的投資和十幾年的努力在一瞬間付諸東流。
原因為何?源自一個簡單的軟件漏洞。它試圖將可代表數十億個潛在值的64位浮點型變量存儲至只能代表65535個潛在值的16位整數中。也就是說，為了讓火箭進入太空，需要分配更多的儲存空間。
這告訴我們，小的失誤會造成嚴重的后果，潛在危險最大，為此付出的代價最高。
大象不咬人，它們只想與你成為朋友
程序出錯時，幾乎每一個明顯的錯誤都會在代碼中顯現。這些錯誤會引發顯而易見的編譯器錯誤或運行錯誤，而編譯器錯誤或運行錯誤會在用戶界面或編譯器中體現出來。開發人員很清楚，這些問題需要立即解決，所以這些錯誤幾乎不會引發擔憂。
最有可能的情況是，發現錯誤后，開發人員立刻進行修復，絕不會提交一份板上釘釘的半成品或編寫了不符合預期目標的代碼。
大象不咬人，因為可以以直觀的方式將它們輕易馴服。從長遠角度來看，它們不會惹任何麻煩，也不會造成任何傷害(除非命令它們那么做)。它們容易識別，通常會說，“看看我!關注我，我會向你表達愛意，你不會后悔的。”
蚊子會成群結隊地叮咬你，讓你患上萊姆病，甚至殺死你
與大象相對的是蚊子——代碼中看似無關緊要且并不明顯的部分，作為隱藏數據藏匿于看似有效的代碼的backburner中。他們隨時準備發動攻擊，讓代碼毀于一旦。由此導致的錯誤包括：邏輯錯誤、設計問題、雜亂的代碼以及有缺陷的非優化算法。
阿麗亞娜5號火箭發射的問題在于，研究人員復制了此前成功發射的阿麗亞娜4號火箭的工作代碼。研究人員顯然認為這些代碼同樣適用于阿麗亞娜5號，但這些代碼并不能滿足阿麗亞娜5號火箭的環境需求，無法應對新環境的要求。
圖源：unsplash
最小的錯誤卻造成了最大的問題
- 邏輯錯誤會引發產品處理問題和產品信息顯示問題，減損預期功能，影響用戶體驗。即便開發人員沒有在應用程序的運行方式上發現任何相關的或可立即識別的問題，也會導致用戶流失。
- 設計不當會導致類似阿麗亞娜5號火箭爆炸等問題。這種設計下的代碼可以在低計算量的環境中工作，但不能在高計算量的環境中工作。忽略相關事宜會導致系統故障，因為系統不是為處理大規模操作而設計。
此類問題通常在編寫良好的測試代碼中出現，這些測試代碼旨在給系統施加盡可能多的壓力，但如果不編寫測試代碼處理這些情況，可能會發生令人震驚的黑天鵝事件，從而造成嚴重的后果。
- 雜亂的代碼會增加代碼中的錯誤和問題識別難度。除此之外，隨著代碼的擴展和修改越發困難，開發成本也會急劇增加。這會使代碼更容易出現常見錯誤。雜亂的代碼出現時，應即刻提高警惕，進行代碼重構。
- 在計算量大的情況下，非優化算法會影響性能。尤其對于適用于不適應重構代碼以更好地執行算法的程序員來說，這個細節很容易被忽視。
當遇到加載時間長、超時或限制時(特別是使用云后端時)，通常會注意到這個細節。有些代碼單獨運行時效果會很好，但在編程時需意識到，單獨運行順利并不意味著它能夠與大型數據集和其他組件協同工作。
如果不顧這些小問題，其結果將會令人大吃一驚。好消息是，有很多方法可以降低并最小化這些錯誤的影響。
使用驅蟲劑!
不注意小的問題，最終會面臨最大的問題。在某種程度上，阿麗亞娜5號事件的程序員值得同情。但是此類事件說明，在大量的壓力測試和測試驅動開發的支持下，仔細編寫代碼尤為重要。
編程不只是寫出能運行的代碼，它還需要仔細周到的考慮：代碼不是胡亂編寫，許多新老程序員只是把代碼片段拼湊在一起，就像試圖把圓柱體塞進方孔一樣。雖然圓柱也能塞進去，但并不合理，而且無論如何也不穩固。
圖源：unsplash
因此，在編寫代碼時最好把這些問題放在心中：
- 代碼是否過于復雜?應如何將其簡化?
- 是否為代碼編寫了嚴格的測試類，這些測試類具有強大的斷言和測試功能，以應對多種不同的數據飽和和高計算量情境?是否了解代碼的局限性?
- 函數是否太小?可以將大型函數的方法應用于小型函數嗎?
- 變量，類和函數是否擁有清晰明確的名稱?僅通過閱讀名稱能否明確了解代碼的功能?
- 是否復制了過多的方法，而這些方法可在多種不同的過程中重用并具有通用功能?重復方法是絕對必要的嗎?它們值得應用于不同的功能情境嗎?
- 如何處理錯誤?是否使用try-catch塊拋出錯誤，并對變量運行null檢查?錯誤被發現時，是否有特定的過程來確保功能平穩?
- 代碼是否易于擴展和延伸?如果進行了修改，需要擔心任何相依性嗎?
- 代碼是否有能力優化來處理大量數據?代碼在運行壓力過大時是否會引發錯誤或超時?
當然，還可以問自己更多的問題，這些問題足夠匯編成一個詳盡的清單上述問題可能是最重要的，但卻未得到足夠的重視。通過限制潛在的未知錯誤，使不確定的事情成為已知，來降低代碼中任何錯誤的風險，而非觀察后才成為已知。
這些大錯誤不應成為長期關注點，因為大錯誤很容易更正和解決。日常的微小錯誤和不一致性才是真正需要關注的問題。
