【51CTO.com快譯】為什么程序出故障？雖然自世界上第一位女程序員艾達·洛夫萊斯（Ada Lovelace）在上世紀第一次看到通用計算的潛力以來我們已取得了很大進展，但是我們編寫的軟件還是錯誤百出。這些年來，盡管我們開發出許多高級方法來確保代碼的成功，但是程序還是不斷的出故障。

原因何在？

雖然這個問題的答案多種多樣，但我們還是決定提供一個務實的答案。程序員難免犯錯。他們有時馬虎了事。他們并不總是使用最佳工具或最佳實踐。

[[176050]]

我在加州大學伯克利分校教面向對象編程這門課，我在學校教優秀編程實踐所花的時間與幫助學生理解代碼本身所花的時間相比只多不少。我在課堂上看到許多常犯的錯誤，本文就介紹其中幾個常見錯誤。

我還聯系上了西北理工大學工程學院的詹姆斯·A·康納（James A. Connor）教授，請他介紹其學生常犯的一些錯誤。

我先來說幾個。

第一個錯誤：糟糕的注釋方法。

注釋是程序里面計算機并不執行的那部分文本。它們被程序員寫成附注的形式，用來解釋代碼里面發生的情況。

我的好多學生避免給代碼添加注釋，也想不明白為何要占用實際編碼的時間去編寫一些注釋。我最實用的例子來自我自己的生活。

早在世紀之交前，我編寫了版本1.0的ZENPRESS，這是最古老的內容管理系統之一。我預計它會帶來好幾年的文章。14年過后，它仍在管理許多文章，準備好了75000篇文章和26億頁的內容。

最后，它運行所依賴的那個平臺過時了。我不得不回過頭去研究代碼。2009年，我把代碼從原始平臺移植到現代平臺。我最近不得不再次改動，因為PHP一個關鍵的語言特性在版本升級后完全消失了。

[[176051]]

19年過后，我根本記不起所有這些代碼是怎么運行的，但是由于我對代碼作了詳細的注釋，所以可以說有了一份路線圖。我可以查看代碼，查看嵌入在代碼里面的注釋，然后進行修改。

你在團隊工作時，或者你的軟件不歸你監管時，注釋也很重要。你的職業生涯可能發生變化，別人可能需要過來了解你的代碼。注釋將大有幫助。

第二個錯誤：糟糕的變量命名。

我會繼續探討這個主題：通過語言讓代碼一目了然。我會用一個例子來表明這點。假設你駕駛一輛每加侖汽油跑20英里的汽車，開了100英里。請問你用掉了多少汽油？

這是個簡單的例子，但是適用于我們的用途。假設你遇到了a = b/c這一行。a指什么？b和c又指什么？它們與你的其余代碼有何關系？在編寫程序十分鐘后，你會記得一干二凈。更不用說別人過來修改代碼或編寫更新版了。

現在看看這個表達式：加侖 = 英里/每加侖行駛英里數。每一個變量的具體用途就一目了然。一個代表加侖，一個代表英里，另一個代表每加侖行駛英里數。很清楚。

想一想為變量賦予清楚的英語（或者其他任何母語）名稱與注釋之間的關系。假設你從別人那里接過了一段代碼，看到a = b/c。這代碼用來干嘛？你有何頭緒嗎？

務必以一種代表其功能的方式來命名變量。那樣可以節省大量的時間，減少許多頭痛的問題。

第三個錯誤：沒有實驗筆記（lab notes）。

我在1997年年中開始編寫ZENPRESS，它在1998年1月份上線。遺憾的是，我當時匆忙完成了項目，沒有花時間為這第一個版本編寫實驗筆記。此后我懊悔多次。從1999年6月份開始（當時我開始編寫版本2），我就經常做實驗筆記了。

[[176052]]

實驗筆記是代碼注釋之外的記錄。科學家一直在使用實驗筆記，作為其研發過程的日志或對話內容。實驗筆記用來證明科學發現歸誰所有，因為研究過程常常記錄在科學家用來記錄進度的每天日志中。

實驗筆記對程序員來說同樣是一種有效的工具。我為ZENPRESS編寫的上一份實驗筆記是在今年3月份編寫的，當時我不得不把ZATZ歸檔從一家主機托管提供商遷移到另一家。我還經常對自己的其他項目做實驗筆記，由于能夠回過頭去查閱筆記，好多次幫了大忙。

如果你還沒有做實驗筆記，現在就開始做。記下你做的任何變化，你的理由，你考慮后丟棄的代碼，參考的實用資源，以及將來幫助你的任何其他內容。你還能幫助將來的同事或接手人――如果你需要證明歸屬權，實驗筆記還能起到證明的作用。

第四個錯誤：不用一種人類語言編寫。

我的學生要考試過關，不僅僅要編程，他們還要編寫討論區帖子，證明他們熟知某些編程概念。

我們提出這個要求出于兩個原因。當然，首先是為了證明熟悉概念。但是更為重要的是需要所有專業人員都有編寫能力。

我在這方面遭到學生們的反對。每學期都有學生高喊：“我想成為程序員，而不是編寫者。”但是編程、工程、IT和幾乎所有專業工作都不可能在真空狀態下存在。

你需要通過編寫來解釋概念、推銷想法、獲得資金、要求澄清、準備提議，或者甚至為拿到更好的分數據理力爭。開源項目的參與者在非常龐大的團隊協同工作，他們保持同步的唯一手段就是編寫清楚的、易于理解的信息。

結論很簡單：如果你想要從事專業工作或從事任何重要的項目，就需要用一種人類語言（比如英語）來編寫，而不僅僅是用一種編程語言來編寫。

第五個錯誤：糟糕的代碼格式。

毫無疑問，這里的一個主題就是：讓代碼易于了解。代碼維護起來極耗費時間和財力。坦率地說，這也不是很有趣。最好還是能夠把寶貴的工作時間用來添加功能，而不是花幾周來鉆研舊代碼，試圖搞清楚你（或者交給你代碼的那個人）想要完成什么任務。

本人就遇到過這種事，不僅僅是來自我的舊代碼，還來自從別人手里接過的代碼。我接手被丟棄的WordPress 開源插件作為一個副帶項目。據我所知，我接手的插件比其他任何人都要多。每個插件都是由別人開發的，為了保持插件可以正常使用，我不得不鉆研陌生人的代碼。

幸好，那些開發人員都是高手，深諳編程之道。要不然，我也就無法接手這些項目了。但即便如此，要盡快上手還是困難重重。你能想象要是他們編寫的代碼結構很糟糕，那會有多難嗎？

我所說的結構是指代碼的布局方式。我為學生制作了這方面的一段視頻。有興趣的話，大家可以上YouTube觀看（https://youtu.be/0u-I016Hxlw）。

想一想你在網上讀到的文章。一些文章格式優美，每一個段落之間有一行，一切都保持一致。可是有些文章都用一個大大的blob來排列，沒法看清。

每個程序員（或項目）都往往有一種編程風格。你的風格是什么樣不是同樣重要，只要保持一致就行。你需要讓代碼格式來幫助引導。

比如說，在我的代碼中，我堅持代碼段之間的空行不得超過一行。如果我看到一段更大的空白區，我立即就知道這一點：哪里出現了異常，這個空白區里面可能有錯誤。

你在深入研究代碼時，要關注貴企業有沒有編程風格。考慮為你的所有程序員定義一種編程風格，堅持采用清楚、易于維護的那一種風格。

第六個錯誤：糟糕的錯誤檢查。

某位著名的將軍曾經說過，遇到敵人時，計劃根本不管用。我在此基礎上改動一下，遇到用戶時，你的代碼根本不管用。盡管你認為自己知道用戶會如何使用代碼，但你其實并不知道，相信我。

用戶會搞壞你的代碼。

正確的處理方式就是借助測試和錯誤檢查。錯誤檢查是指這種做法：檢查代碼中每一次操作的結果。確保它符合你的預期，或者確保你的代碼可處理意外的結果。

[[176053]]

比如說，我的學生經常有一項任務：閱讀文件。幾乎所有的學生編寫代碼時會調用文件讀取例程。他們檢查用戶是否取消對話框，但是很少查看文件是否實際上被讀入，或者是否存在某種類型的系統錯誤。要是他們試圖編寫文件，那就更糟糕了。他們幾乎從不真正查看文件是不是實際上保存起來。真是要命。

不難發現這會有多糟糕。為了對付這種情形，你總是要考慮能不能絕對預測行為，然后認識到你不能絕對預測行為。你需要測試。測試并不是僅僅指你自己運行代碼。測試意味著讓實際用戶（即行為可能無法預測的那些人）運行你的代碼。

你會發現這會提供大量的信息。

第七個錯誤：使用打印輸出語句，而不是真正的調試器。

這些年來我發現，使用不同語言的程序員往往有不同的文化。總的來說，那是由于他們構建不同種類的解決方案、使用不同的工具。

這方面的一個例子就是我的C#編程學生和與我一起開發一些項目的開源PHP開發人員之間的區別。幾乎沒有一個C#程序員會考慮不使用一種符號調試器來調試代碼。那是由于， C#本身是使用Visual Studio作為編程環境來編寫的，調試器內置在里面。

相比之下，我見到許多PHP開發人員認為只要插入echo語句或var_dump就足以幫助自己調試代碼了。這一方面是由于，大多數PHP程序員往往在編輯器里面編程，而不是在開發環境里面編程。兩者之間的一大區別就是調試器。

那么，調試器是什么東東？簡而言之，這種工具讓你可以在代碼運行時查看代碼內部的情況。它就好比是代碼的X光、超聲波或MRI。可以指令調試器在某些點停止，檢查所有變量的狀態。還可以指令調試器在某些條件下停止。你可以更改值，可以查看和分析值（不過分析有時是另一種工具）。

工作效率方面的差異很大。如果你想更快速、極其準確地完成工作，就要確保使用一種真正的符號調試器。

以上就是我所介紹的幾個常見錯誤，下面看看詹姆斯·康納教授介紹的幾個。

第八個錯誤：使用魔數（magical number）。

許多程序員認為，他們只要編寫一次代碼，代碼就能完美無缺。然而，為了優化企業軟件和工業軟件的長期生命周期成本，有必要編寫能夠抵御不斷變化的條件的代碼。

這方面的一個典例就是魔數這個想法。我所說的魔數是指程序員認為總能經受得住時間考驗的數字。

以可能基于客戶的采購數量的傭金計算為例。截至截稿時，傭金比例可能是三個百分點，即0.03。

現在，設想一下會如何編寫這段代碼：傭金= .03 *銷售額。在這個上下文中，這個魔數就是0.03。由于程序員認為這會是永遠神奇地有效，他將0.03這個數字硬編碼到代碼中。

這一切很好，但是每年的傭金往往發生變化。如果下一年傭金漲了0.5%，漲到0.035，那么就很難在成千上萬行代碼中找到它。

切忌使用魔數，而是在一個地方定義變量或常量，讓代碼使用那些變量。如果你預先定義commission_rate，那么commission = commission_rate * sale之類的代碼就不需要改動。

要考慮的另一個方面是，無論你在何處找到魔數，都應該找到想要提供給用戶的選項，以便用戶可以在偏好設置部分可以設置。

第九個錯誤：馬虎對待的日期和時間。

這里有個難題：一年有幾天？365天也許是平常的回答，但今年當然有366天。一天會有365.25天嗎？這不可能。

但我的一些學生認為，既然閏年每四年就出現一次，所以每年平均下來因此是365.25天。在進行日期計算時，他們使用這個平均值；因而，結果根本不正確。

常常更好的辦法是使用系統庫來計算日期，因為你計算的日期可能不是西方日歷日期。

不妨看一下時間方面的類似問題。每幾年，由于地球轉速減慢，有一天會多出一秒來，通常是在6月30日或12月31日那天。這叫作閏秒，因而，時鐘可能從11:59:59走到11:59:60再走到12:00:00。

這是第二個時間挑戰。在使用夏令時的地方，交易的進行有可能亂套。比如說，先置入交易A，但是隨后時間被向后重置1小時，那么就置入交易B。然而，如果你在時間序列方面很馬虎，它就會記錄為交易B先發生。這種類型的時間錯誤會導致產生不必要的罰款，還會導致其他各種各樣的混亂。

再次，有許多好的語言和系統庫可以處理這兩種時間問題。常常更好的辦法是使用現有的庫，而不是編寫自己的時間計算代碼。

第十個錯誤：沒有選擇合適的數據結構。

數據結構是表示程序中數據的一種機制。許多人聽說過鏈表、樹和數組之類的術語。這每一個術語都是數據的邏輯表示，對應于你試圖表示的數據的一些架構結構。

我看到程序員（無論編程高手還是菜鳥）最常犯的錯誤之一就是，很少注意數據結構方面的選擇。由于你的幾乎所有代碼都建立在選擇的那種數據表示方法上，一旦選錯數據結構，會在將來帶來嚴重的影響。

下面這個例子可以表明這種設計錯誤：選擇一個簡單的堆棧或隊列，而不是循環隊列。堆棧就好比是一堆盤子。你取下底部盤子，然后放上另一只盤子，再取下另一只盤子，依次類推。

如果你想拿走一只盤子，你從最上面拿走。這就叫后進先出。可問題，如果你需要拿走早些時候放的東西，就很麻煩了。假設一堆棧盤子有10只盤子。想找到第一只盤子，你就得先拿走其他所有的盤子。

現在，不妨想象一下隊列。如果你在銀行排隊，就處于隊列中。第一個進去的也是第一個出來的。一旦第一個人得到了服務，下一個人跟上，然后該人得到服務。出現的另一種情況是，每個人都向前邁一步，在隊列中向前移動位置。

要是許多人來排隊，會出現什么情況？要么他們被拒之門外，要么隊伍排到門外面。第一個人叫到后，所有這些人都要往前移動。

如果你有大量數據，這種隊列就會極其低效。每當從隊列的開頭獲取數據，所有數據都要移動。我們置身于大數據時代，有源源不斷的數據從我們的系統通過。

在這種環境下，一種更好的辦法也許是實施循環隊列。在這種情況下，數據根本不動。相反，設置的指針指向隊列的開頭和末尾；在內部，隊列首尾相連，那樣數據以圓環、而不是隊列的方式來加以組織。當數據元素使用、從圓環中移除后，就不需要移動圓環中的所有數據。發生的只是第一個元素的指針指向圓環中的新元素。

有許多例子可以表明選擇正確的數據結構會給你代碼的效率帶來重大影響，這僅僅是其中一個。

但愿你在看完本文后，會成為一名更高效的程序員，避免其中一些嚴重錯誤。

原文標題：Software bugs? Avoid these 10 costly programming mistakes，作者：David Gewirtz

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】