程序員請注意：一個小bug就足以消滅一個火星氣候探測儀！

NASA的火星氣候軌道探測儀於1998年12月11日發射，其任務是研究火星氣候; 該計劃的成本超過3億美元，其中很大一部分用於開發必要軟體。不幸的是，隨著軌道探測器逐漸接近紅色的星球，它突然就消失了，監視的科學家們意識到它可能是永遠消失了！

事後追責，發現導致軌道探測器故障的原因是一個非常簡單的軟體故障。軌道探測儀不是用牛頓定律來計算一個特定的度量，程序正在使用磅來省略對轉換函數的單一調用，這不過是一個可以用幾個字元代碼修復的錯誤，而這個錯誤足以摧毀整個空間程序，使全世界數千名最有資格的科學家和工程師的努力無效！

火星氣候軌道探測儀只是由於非常愚蠢的編程錯誤而失敗的眾多項目之一，它可以被用作驗證沒有任何一個軟體完全無缺陷且經過了完全測試。即使是最廣泛的測試套件，也只是代表了任何應用程序預期擁有的所有可能路徑的極其有限的子集。因此，即便一個軟體經歷了十億次成功的測試也不能證明應用程序的有效性，但一個失敗就足以將其指定為無效！問題在於如何發現可能導致失敗的原因，沒有人可以確定它們不存在，因為不可能測試所有可能的變數和執行路徑的組合。

儘管存在由簡單的「錯誤」導致應用程序失敗的巨大記錄，但許多軟體開發人員堅持認為，它們可以提供完美無缺的，完全無錯誤的應用程序！每當我聽到這樣的事情，我相信它來自於一個初級的，不是很有才華的程序員的看法，聽起來像一個推銷員試圖吸引聽眾的耳朵！

軟體開發人員最關鍵的技能之一在於有能力決定代碼的不完整性和低效率已達到其客戶可以容忍的水平。雖然這個聽起來很挑釁和奇怪，但聲稱自己正在努力提供無缺陷和功能完備的代碼的軟體工程師，開發人員和項目經理都是在說謊，或者根本就不知道他們在說什麼。

經常可以聽到開發人員和產品經理吹噓，儘快修復所有已知錯誤並且永遠不會發布下一個版本，而所有的修復都是承諾！這種方法不過是一種希望的想法或座右銘，可能被用來說服一些不太懂開發的產品經理。

高級程序員的責任是做出一個成功的判斷，決定解決方案已達到可以合理完整和穩健部署到用戶的級別！毫無疑問，用戶會發現其中的一些錯誤和缺點，其中一些將成為下一個版本的參考功能，偉大的軟體依賴於定期的版本更新，這些版本正在修復現有的錯誤，並根據用戶反饋添加新功能。

失敗項目背後的主要原因是缺乏有經驗的程序管理人員，他們不了解軟體開發既不是一門精確的科學，也不是可以使用某種數學程序進行驗證的邏輯結構。無論軟體如何重要，嘗試解決的問題多麼關鍵，程序員都必須清晰表明，不可能達到一個完美的解決方案。

無論是自動交易系統，核反應堆保護系統還是Android遊戲，在某些時候有人必須決定軟體已經準備好運送給用戶了！決定軟體已經達到了用戶可接受的完整性水平，其錯誤是可以容忍的，這是開發人員最關鍵的判斷原則之一。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！