本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。

1996年6月24日，歐洲航天局的阿麗亞娜5號無人火箭在發(fā)射僅37秒后爆炸。三億七千萬的投資和十幾年的努力在一瞬間付諸東流。

原因為何?源自一個簡單的軟件漏洞。它試圖將可代表數(shù)十億個潛在值的64位浮點型變量存儲至只能代表65535個潛在值的16位整數(shù)中。也就是說，為了讓火箭進入太空，需要分配更多的儲存空間。

這告訴我們，小的失誤會造成嚴重的后果，潛在危險最大，為此付出的代價最高。

[[389166]]

大象不咬人，它們只想與你成為朋友

程序出錯時，幾乎每一個明顯的錯誤都會在代碼中顯現(xiàn)。這些錯誤會引發(fā)顯而易見的編譯器錯誤或運行錯誤，而編譯器錯誤或運行錯誤會在用戶界面或編譯器中體現(xiàn)出來。開發(fā)人員很清楚，這些問題需要立即解決，所以這些錯誤幾乎不會引發(fā)擔(dān)憂。

最有可能的情況是，發(fā)現(xiàn)錯誤后，開發(fā)人員立刻進行修復(fù)，絕不會提交一份板上釘釘?shù)陌氤善坊蚓帉懥瞬环项A(yù)期目標(biāo)的代碼。

大象不咬人，因為可以以直觀的方式將它們輕易馴服。從長遠角度來看，它們不會惹任何麻煩，也不會造成任何傷害(除非命令它們那么做)。它們?nèi)菀鬃R別，通常會說，“看看我!關(guān)注我，我會向你表達愛意，你不會后悔的。”

蚊子會成群結(jié)隊地叮咬你，讓你患上萊姆病，甚至殺死你

與大象相對的是蚊子——代碼中看似無關(guān)緊要且并不明顯的部分，作為隱藏數(shù)據(jù)藏匿于看似有效的代碼的backburner中。他們隨時準(zhǔn)備發(fā)動攻擊，讓代碼毀于一旦。由此導(dǎo)致的錯誤包括：邏輯錯誤、設(shè)計問題、雜亂的代碼以及有缺陷的非優(yōu)化算法。

阿麗亞娜5號火箭發(fā)射的問題在于，研究人員復(fù)制了此前成功發(fā)射的阿麗亞娜4號火箭的工作代碼。研究人員顯然認為這些代碼同樣適用于阿麗亞娜5號，但這些代碼并不能滿足阿麗亞娜5號火箭的環(huán)境需求，無法應(yīng)對新環(huán)境的要求。

[[389167]]

圖源：unsplash

最小的錯誤卻造成了最大的問題

• 邏輯錯誤會引發(fā)產(chǎn)品處理問題和產(chǎn)品信息顯示問題，減損預(yù)期功能，影響用戶體驗。即便開發(fā)人員沒有在應(yīng)用程序的運行方式上發(fā)現(xiàn)任何相關(guān)的或可立即識別的問題，也會導(dǎo)致用戶流失。
• 設(shè)計不當(dāng)會導(dǎo)致類似阿麗亞娜5號火箭爆炸等問題。這種設(shè)計下的代碼可以在低計算量的環(huán)境中工作，但不能在高計算量的環(huán)境中工作。忽略相關(guān)事宜會導(dǎo)致系統(tǒng)故障，因為系統(tǒng)不是為處理大規(guī)模操作而設(shè)計。

此類問題通常在編寫良好的測試代碼中出現(xiàn)，這些測試代碼旨在給系統(tǒng)施加盡可能多的壓力，但如果不編寫測試代碼處理這些情況，可能會發(fā)生令人震驚的黑天鵝事件，從而造成嚴重的后果。

• 雜亂的代碼會增加代碼中的錯誤和問題識別難度。除此之外，隨著代碼的擴展和修改越發(fā)困難，開發(fā)成本也會急劇增加。這會使代碼更容易出現(xiàn)常見錯誤。雜亂的代碼出現(xiàn)時，應(yīng)即刻提高警惕，進行代碼重構(gòu)。
• 在計算量大的情況下，非優(yōu)化算法會影響性能。尤其對于適用于不適應(yīng)重構(gòu)代碼以更好地執(zhí)行算法的程序員來說，這個細節(jié)很容易被忽視。

當(dāng)遇到加載時間長、超時或限制時(特別是使用云后端時)，通常會注意到這個細節(jié)。有些代碼單獨運行時效果會很好，但在編程時需意識到，單獨運行順利并不意味著它能夠與大型數(shù)據(jù)集和其他組件協(xié)同工作。

如果不顧這些小問題，其結(jié)果將會令人大吃一驚。好消息是，有很多方法可以降低并最小化這些錯誤的影響。

使用驅(qū)蟲劑!

不注意小的問題，最終會面臨最大的問題。在某種程度上，阿麗亞娜5號事件的程序員值得同情。但是此類事件說明，在大量的壓力測試和測試驅(qū)動開發(fā)的支持下，仔細編寫代碼尤為重要。

編程不只是寫出能運行的代碼，它還需要仔細周到的考慮：代碼不是胡亂編寫，許多新老程序員只是把代碼片段拼湊在一起，就像試圖把圓柱體塞進方孔一樣。雖然圓柱也能塞進去，但并不合理，而且無論如何也不穩(wěn)固。

[[389168]]

圖源：unsplash

因此，在編寫代碼時最好把這些問題放在心中：

• 代碼是否過于復(fù)雜?應(yīng)如何將其簡化?
• 是否為代碼編寫了嚴格的測試類，這些測試類具有強大的斷言和測試功能，以應(yīng)對多種不同的數(shù)據(jù)飽和和高計算量情境?是否了解代碼的局限性?
• 函數(shù)是否太小?可以將大型函數(shù)的方法應(yīng)用于小型函數(shù)嗎?
• 變量，類和函數(shù)是否擁有清晰明確的名稱?僅通過閱讀名稱能否明確了解代碼的功能?
• 是否復(fù)制了過多的方法，而這些方法可在多種不同的過程中重用并具有通用功能?重復(fù)方法是絕對必要的嗎?它們值得應(yīng)用于不同的功能情境嗎?
• 如何處理錯誤?是否使用try-catch塊拋出錯誤，并對變量運行null檢查?錯誤被發(fā)現(xiàn)時，是否有特定的過程來確保功能平穩(wěn)?
• 代碼是否易于擴展和延伸?如果進行了修改，需要擔(dān)心任何相依性嗎?
• 代碼是否有能力優(yōu)化來處理大量數(shù)據(jù)?代碼在運行壓力過大時是否會引發(fā)錯誤或超時?

當(dāng)然，還可以問自己更多的問題，這些問題足夠匯編成一個詳盡的清單上述問題可能是最重要的，但卻未得到足夠的重視。通過限制潛在的未知錯誤，使不確定的事情成為已知，來降低代碼中任何錯誤的風(fēng)險，而非觀察后才成為已知。

這些大錯誤不應(yīng)成為長期關(guān)注點，因為大錯誤很容易更正和解決。日常的微小錯誤和不一致性才是真正需要關(guān)注的問題。