[[342882]]

生活中的很多道理都是親身經(jīng)歷過才能真正明白的，在編程中也是一樣的，時(shí)間和經(jīng)驗(yàn)?zāi)芙探o你的東西在別處學(xué)不到。下面這9點(diǎn)，我必須很艱難地去實(shí)踐學(xué)習(xí)！

1.最便宜、最快和最可靠不可兼得

戈登·貝爾（Gordon Bell）曾經(jīng)說過這樣的話。在此要我們學(xué)到的是，應(yīng)該盡可能保持系統(tǒng)或軟件簡單易懂。降低其復(fù)雜性，漏洞也會(huì)隨之減少。

2.Voodoo編程

很多程序員自始至終都有這樣的經(jīng)歷：有時(shí)你成功修復(fù)了漏洞卻不理解問題出在哪里。請(qǐng)務(wù)必要理解自己寫下的代碼，并且找出修改奏效的原因。這種心態(tài)會(huì)比書本教給你的更多。不要覺得不好意思，實(shí)在不明白的話就去向別人請(qǐng)教。沒準(zhǔn)哪一天，你就會(huì)發(fā)現(xiàn)自己也變成了別人請(qǐng)教的對(duì)象。

復(fù)制粘貼代碼也是如此。有時(shí)候，我們都會(huì)使用堆棧溢出，這沒關(guān)系的。但是如果你不理解代碼，要么就別用，要么就找人問問清楚。創(chuàng)造或使用自己不理解的代碼也被稱為Voodoo編程，這是一個(gè)潛在的漏洞。

3.代碼不會(huì)騙人，但有時(shí)注釋會(huì)

注釋起著很重要的作用，但是如果可以的話，盡量不要使用注釋，而是書寫更多的描述性代碼。這是因?yàn)樵谀阈薷拇a的時(shí)候，注釋往往會(huì)被忽視。因此我這樣說：注釋有時(shí)會(huì)騙人（有錯(cuò)誤），因?yàn)樗車拇a已經(jīng)改變，而它自己沒有被修改。

有三種方法書寫代碼：

· 在代碼中使用注釋。

· 將注釋寫在單獨(dú)的文件中。

· 書寫自我說明的代碼。

我來詳細(xì)說明一下最后一點(diǎn)。下面是書寫更多描述性代碼的意義：

· 好好設(shè)計(jì)代碼庫，使它方便查找且結(jié)構(gòu)合理。

· 不要嘗試保存縮寫字母。在對(duì)變量、類和函數(shù)命名的時(shí)候使用全稱，比如不用wm用windowManager，不用rf用readFileToString。當(dāng)你或者其他人間隔數(shù)月再看代碼試圖理解其意思時(shí)，這種命名方式會(huì)有很大幫助。

· 盡可能多地提取函數(shù)并讓它們各司其職。根據(jù)其功能進(jìn)行命名，比如，創(chuàng)建一個(gè)將文件讀入字符串的函數(shù)，將其命名為readFileToString(String fileName)，不用仔細(xì)閱讀代碼就能明白它的作用。

最理想的情況是，你的代碼由一系列這樣的函數(shù)調(diào)用組成，讀起來就像人類語言一樣。只有在需要的時(shí)候，讀者才會(huì)去深入理解，這些代碼本身就有說明的作用。

4.正則表達(dá)式

在面對(duì)問題時(shí)，有些人會(huì)想：“要用正則表達(dá)式！”好的，現(xiàn)在他要面臨兩個(gè)問題了。這個(gè)笑話有點(diǎn)兒年頭了，但依然是人間真實(shí)。正則表達(dá)式是一種痛苦，當(dāng)你以為終于為一個(gè)案例找到正確答案的時(shí)候，對(duì)于下一個(gè)案例就只有70%匹配。

以上僅僅是我的想法，除非萬不得已，建議不避免濫用正則表達(dá)式。通常，像split、substring、endsWith、indexOf等函數(shù)的組合將會(huì)產(chǎn)生更加易讀的代碼。

5.軟件就像大教堂：我們建造它們——然后祈禱

《大教堂與集市》一書對(duì)比了兩種不同的開發(fā)模式。正如維基百科中所寫：

“在大教堂模式下，每個(gè)軟件版本都可以獲得源代碼，但在不同版本之間開發(fā)的代碼僅限于軟件開發(fā)人員這個(gè)專屬群體；集市模式下，代碼是在公眾視野中通過互聯(lián)網(wǎng)開發(fā)的。Linux內(nèi)核項(xiàng)目的領(lǐng)導(dǎo)者林納斯·托瓦茲（Linus Torvalds）被認(rèn)為是這個(gè)過程的發(fā)明者。”

兩種模式各有利弊。然而，人們普遍認(rèn)為軟件需要迭代開發(fā)，在這個(gè)過程中其功能逐漸變多，所以終端用戶最好從早期就參與開發(fā)過程。

6.在便宜、快速和可靠中三選二

我喜歡這個(gè)部分，它讓聽者（你的經(jīng)理）自己思考：

· 你想要可靠且快速？可以是可以，但你要聘用最好的程序員。

· 又便宜又快？那就別指望它可靠了！

· 又可靠又便宜？也許你很幸運(yùn)，但是你需要花費(fèi)更多時(shí)間找到廉價(jià)的勞動(dòng)力，或者需要大量迭代（因此需要更多時(shí)間）才能做好。

7.在軟件工程中有兩件難事

· 0.命名

· 1.緩存失效

· 2.大小差一

我們?nèi)祟愐话銜?huì)從1開始計(jì)數(shù)，而計(jì)算機(jī)從0開始。這項(xiàng)簡單的事實(shí)成為了很多漏洞和困難的來源。你很可能已經(jīng)犯過大小差1的錯(cuò)誤，如果還沒，別著急，它們總會(huì)找上你。

8.好的程序員在通過單行道時(shí)會(huì)查看兩邊

最好的程序員可以處理所有錯(cuò)誤，注意，我說的是所有，即使是那些“永遠(yuǎn)不會(huì)出現(xiàn)的錯(cuò)誤”。

大多數(shù)軟件都是為了實(shí)現(xiàn)“快樂流”而編寫的——一切都按照預(yù)期進(jìn)行，用戶不會(huì)做些奇怪的事情。然而現(xiàn)實(shí)世界是混亂的，隨著時(shí)間的推移，有潛在風(fēng)險(xiǎn)的事情也會(huì)出錯(cuò)。嘗試捕捉盡可能多的錯(cuò)誤，特別是當(dāng)你的軟件正在實(shí)現(xiàn)重要功能的時(shí)候。

9.按代碼行衡量編程進(jìn)度就像按重量衡量飛機(jī)制造進(jìn)度一樣

更多代碼行并不代表更多進(jìn)度。同樣，書寫更多代碼并不意味著你比別人更高效。最好的代碼應(yīng)該能夠言簡意賅地完成任務(wù)，這也是最難寫的。這是一個(gè)眾所周知的軟件原理，叫作KISS，是“Keep It Simple, Stupid（保持簡單、易懂）”的縮寫。

如果對(duì)哪條感到不甚理解，沒關(guān)系的，你只需要記住它們，然后靜候?qū)嶋H經(jīng)歷的那一刻讓你深刻理解它。