[[131972]]

本文列出的 10 個錯誤，并不局限于C＃，Delphi，JavaScript 等——幾乎涵蓋了所有的編程語言。是不是大吹大擂，歡迎各位品鑒……

1. 面向編譯器寫代碼，而不是面向用戶

當(dāng)人們使用編譯器創(chuàng)建自己的 app 時，在把自己的想法訴諸于機(jī)器代碼的過程中，常常會將那些可以使得編程更為簡單卻又冗長的語法遺忘于腦后。

無論你使用的是單字母的標(biāo)識符還是更易于人腦理解的標(biāo)識符，對于編譯器而言，毫無區(qū)別。編譯器不在乎你寫的是否是優(yōu)化表達(dá)式，也不在乎你是否用括號封裝了子表達(dá)式。編譯器要做的就是將這些人腦可讀的代碼，解析為抽象的語法樹，并將這些樹轉(zhuǎn)換成機(jī)器代碼，或某種中間語言。

那么，為什么不使用更可讀或者語義更明顯的標(biāo)識符呢——而不要僅僅是I，J或x。老實(shí)說，現(xiàn)在我們用來等待編譯器完成轉(zhuǎn)換標(biāo)識符的時間幾乎是微不足道。但是，這么做卻可以大大減少你和其他程序員用于閱讀理解這些源代碼所用的時間。

還有一個類似的觀點(diǎn)是：或許你可能已經(jīng)記住了相關(guān)的運(yùn)算符優(yōu)先級，于是省略了表達(dá)式中一些不必要的括號，但是卻沒有考慮到后面的程序員有可能會誤讀你的代碼，并就它是如何工作的作出一些無效的假設(shè)。

我的想法是，假設(shè)大家都知道，乘法（或除法）優(yōu)先于加法和減法。其他任何我放到表達(dá)式中的內(nèi)容我都會用上括號，以確保能真正表達(dá)我的意思，其他人也能真正理解我的想法。

有研究表明，有的代碼維護(hù)所需要的時間甚至超出其編寫時間的五倍以上。所以將代碼寫得易于閱讀和理解是非常有意義的。

2. 函數(shù)方法過于龐大

有一個經(jīng)驗(yàn)法則就是，我們寫的程序不應(yīng)該過于龐大。而且我們也可以發(fā)現(xiàn)，現(xiàn)在方法趨向于越來越小巧——有時候僅僅只是幾行代碼。

從本質(zhì)上說，要想快速把握程序的目的和意義，只需要一定的代碼就夠了。長方法不但令人難以接受，而且往往最終趨向于支離破碎。

其原因也非常簡單：長方法既難以理解，又難以維護(hù)，甚至還難以正常測試。

有一個相當(dāng)不錯的測量方法可以衡量你的代碼的復(fù)雜程度，以及出現(xiàn) bug 的概率—— 循環(huán)復(fù)雜度。

該方法由 Thomas J. McCabe Sr 于 1976 年開發(fā)。循環(huán)復(fù)雜度使用方便簡單，能讓你在匆忙之中盡可能地保證代碼運(yùn)行正常。只需要數(shù)一數(shù)代碼中‘if’語句和循環(huán)的數(shù)量，再加1，就是該方法的 CC 值。

當(dāng)然這只是對代碼執(zhí)行路徑數(shù)量的粗略計(jì)數(shù)。不過，如果你的某個方法其循環(huán)復(fù)雜度值大于 10，我建議你重寫。

3. 過早的優(yōu)化

這一點(diǎn)非常簡單。當(dāng)我們在編寫代碼的時候，有時我們會自作聰明地對某些代碼過于注重細(xì)節(jié)過于精益求精，雖然看上去這些“明智”的代碼比原先寫的那些提高了速度，但是你忽略了一個事實(shí)，這些“明智”的代碼往往是難以閱讀難以理解的——而且真正節(jié)省的時間往往只有幾毫秒。這就是所謂的過早的優(yōu)化。

著名的計(jì)算機(jī)科學(xué)家 Donald Knuth 曾經(jīng)說過，“過早的優(yōu)化是一切罪惡的根源”。

換言之就是：我們的代碼需要清晰、干凈，然后再重點(diǎn)找出真正的瓶頸并對其進(jìn)行優(yōu)化。千萬不要試圖過早的優(yōu)化。

4. 使用全局變量

話說回來，有的編程語言是完全沒有局部變量這個概念的，所以不得不使用全局變量。關(guān)于全局變量，雖然我們可以在子函數(shù)中使用它，但是卻沒辦法聲明這一變量只能在該函數(shù)中使用。盡管如此，全局變量依然非常受歡迎，因?yàn)槲覀冎恍杪暶饕淮危纯傻教幨褂茫r省力了有木有。

但是它的優(yōu)點(diǎn)也是它的缺陷，這也是關(guān)于全局變量最糟糕的事情——我們沒有辦法控制它的改變，也沒辦法控制何時去訪問變量。假設(shè)某個全局變量在調(diào)用到程序之前賦予了一個特定的值，但是很可能調(diào)用完了之后值就變了，而你卻毫無察覺。

5. 不進(jìn)行評估

你的目標(biāo)是寫一個應(yīng)用程序，你斗志昂揚(yáng)，愈戰(zhàn)愈勇。但是突然間，你發(fā)現(xiàn)了性能問題和內(nèi)存不足的問題。

進(jìn)一步的調(diào)查表明，盡管你的設(shè)計(jì)對于現(xiàn)在這樣小型的用戶數(shù)量、記錄、條目運(yùn)行良好，但是卻不適合大規(guī)模的情況——Twitter 就是例子。又或者它現(xiàn)在在你的 8GB RAM 和 SSD 的 3GHz PC 上運(yùn)行順暢，但一旦到普通的 PC 上，它會比烏龜爬還要慢吞吞。

所以，部分設(shè)計(jì)進(jìn)程還是需要評估，需要一系列的封底計(jì)算。有多少用戶需要同時處理多少個用戶？需要處理多少記錄？目標(biāo)響應(yīng)時間又是多少？等等。

盡量對這些類型的問題進(jìn)行評估，這樣就可以對應(yīng)用程序中的一些技術(shù)問題做一些更進(jìn)一步的決策，如不同的算法和緩存。不要什么亂七八糟的都納入到開發(fā)中去——你還需要好好評估目標(biāo)和目的。

6. 大小差一錯誤（數(shù)組邊界溢出）

這個錯誤基本上每一個程序員都犯過，通常在寫循環(huán)的時候，由于循環(huán)變量的步長增加過多或過少，導(dǎo)致循環(huán)遍歷元素的次數(shù)發(fā)生錯誤，產(chǎn)生數(shù)組溢出的異常。

這個錯誤會導(dǎo)致遍歷數(shù)組元素時訪問不存在的元素，或者遺漏應(yīng)該遍歷的元素。產(chǎn)生這個錯誤的原因就是你忘記了數(shù)組下標(biāo)是從 0 開始還是從 1 開始了。

7. 淹沒異常

現(xiàn)在的編程語言大多使用異常系統(tǒng)作為錯誤報(bào)告技術(shù)，而不再是以往傳統(tǒng)的傳遞和檢查故障代碼。現(xiàn)在的編程語言使用新的關(guān)鍵字來處理和捕獲異常，其名稱為 throw、try、finally 和 catch 等。

關(guān)于異常處理值得一提的是，它們的作用是展開堆棧，從嵌套程序自動返回，直到異常被捕獲并處理。不再需要你檢查錯誤條件，從而導(dǎo)致代碼深陷錯誤測試的泥沼。

通過正確地運(yùn)用異常處理，我們能夠使得軟件更為強(qiáng)大。比如說 catch 能讓我們捕獲異常，并根據(jù)異常類型執(zhí)行某種行為。

關(guān)于異常處理，程序員犯的最大的錯誤有兩種。第一種是程序員對于他們 catch 的異常了解得不夠清楚具體。捕獲過于籠統(tǒng)化的異常類型可能會導(dǎo)致你在不經(jīng)意間處理掉一些最好能夠保留的特定異常。而這樣做，可能會導(dǎo)致這些異常被淹沒，丟失。

第二個錯誤更為有害：程序員不想要任何異常離開自己的代碼，因此捕獲之后忽略了它們。這就是所謂的空 catch 塊。他們可能是這樣想的，只要 throw 某些類型的異常就可以了：于是名正言順地忽略了這些異常。

而現(xiàn)實(shí)是，這可能會導(dǎo)致其他致命的運(yùn)行時異常——如內(nèi)存不足的異常，代碼無效的異常等等，從而使得程序無法正常運(yùn)行。因此，調(diào)整異常 catch 塊時應(yīng)盡可能的具體化。

8. 純文本格式存儲密碼

數(shù)據(jù)安全性是永遠(yuǎn)值得探討的話題，其重要性是不言而喻的。在這里，我要鄭重告訴你的是，千萬不要將密碼用純文本格式保存。

密碼的標(biāo)準(zhǔn)是，先存儲經(jīng)過加密后雜亂無章的原始密碼，然后再輸入通過相同加密方法后的雜亂的密碼，看看它們是否匹配。

還不清楚這樣做的害處，那么給你個提示：如果某個網(wǎng)站承諾，如果你忘記了原始密碼，他們會給你發(fā)送電子郵件告訴你，那么遠(yuǎn)離這種網(wǎng)站。這可能會出現(xiàn)巨大的安全問題。假設(shè)有一天，該網(wǎng)站會被黑的話，那么你所有的登錄信息都會被泄漏出去，而你除了忍氣吞聲惶惶而不可終日卻毫無辦法。所以，千萬不要接觸這類網(wǎng)站，同樣的，也不要在你的 app 里用純文本的格式存儲密碼或其他的“秘密”。

9. 不驗(yàn)證用戶輸入

以前的程序是單用戶的，于是我們對用戶輸入往往不以為然：畢竟，如果程序崩潰的話，只會影響到一個人的使用。我們的輸入驗(yàn)證僅限于數(shù)值驗(yàn)證、日期檢查，或其他類型的輸入驗(yàn)證。

文本輸入往往不會特別驗(yàn)證。不過后來出現(xiàn)了網(wǎng)頁。于是，你的程序有了遍布世界的用戶。而一些惡意用戶則會通過輸入數(shù)據(jù)到你的程序，以試圖接管你的 app 和服務(wù)器。

新型的攻擊大多是因?yàn)槿狈τ脩糨斎氲臋z查。其中最著名的是 SQL 注入，通過標(biāo)記注入，不好的用戶輸入可能會引發(fā) XSS 攻擊（跨站腳本）。

這兩種類型都依賴于用戶提供包含了 SQL 或者 HTML 片段的文本，來作為正常表單輸入的一部分。如果應(yīng)用程序不驗(yàn)證用戶輸入，直接就拿來用，那么很可能就會執(zhí)行篡改的 SQL，或者產(chǎn)生一些被攻擊的 HTML/JavaScript。

這反過來可能會使得 app 崩潰，或被黑客接管。為了避免這些情況，所以我們應(yīng)該時時驗(yàn)證或消除用戶輸入。

10. 不與時俱進(jìn)

上述這些我總結(jié)的內(nèi)容或許并不新鮮——你可能已經(jīng)在其他的書籍或網(wǎng)頁上涉獵過。但是隨著時代的發(fā)展，會有越來越多的新的設(shè)計(jì)和編程技術(shù)面世。

而你如果還抱著一些陳舊的逐漸在被淘汰的技術(shù)不放，不愿意學(xué)習(xí)和了解新的編程方法和技術(shù)——那么你終將會被拍死在沙灘上。對于程序員，學(xué)習(xí)是永恒的課題。例如 TDD 和 BDD，SLAP 和 SOLID 方法，以及各種敏捷技術(shù)，都是我們應(yīng)該學(xué)習(xí)的技術(shù)。

我們應(yīng)該時刻保持對最新的編程藝術(shù)和實(shí)踐的同步。