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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 使用全局變量

話說(shuō)回來(lái)，有的編程語(yǔ)言是完全沒(méi)有局部變量這個(gè)概念的，所以不得不使用全局變量。關(guān)于全局變量，雖然我們可以在子函數(shù)中使用它，但是卻沒(méi)辦法聲明這一變量只能在該函數(shù)中使用。盡管如此，全局變量依然非常受歡迎，因?yàn)槲覀冎恍杪暶饕淮?#xff0c;即可到處使用，太省時(shí)省力了有木有。

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

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

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

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

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

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

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

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

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

7. 淹沒(méi)異常

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

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

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

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

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

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

8. 純文本格式存儲(chǔ)密碼

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

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

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

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

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

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

新型的攻擊大多是因?yàn)槿狈?duì)用戶輸入的檢查。其中最著名的是 SQL 注入，通過(guò)標(biāo)記注入，不好的用戶輸入可能會(huì)引發(fā) XSS 攻擊(跨站腳本)。

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

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

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

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

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

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

作者：佚名

來(lái)源：51CTO

總結(jié)

以上是生活随笔為你收集整理的每个程序员都可能犯过的10个错误的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。