在我們剛開始走進(jìn)IT行業(yè)時(shí)，寫代碼總會(huì)戰(zhàn)戰(zhàn)兢兢，不斷地向前輩大神請(qǐng)教，經(jīng)過反復(fù)確認(rèn)之后才敢發(fā)布代碼，發(fā)布代碼后也會(huì)時(shí)不時(shí)看后臺(tái)，會(huì)不會(huì)產(chǎn)生BUG......

下面我來列舉一些我作為一個(gè)菜鳥時(shí)，經(jīng)常犯的一些錯(cuò)誤，希望能幫助大家及早改正，早日成為編程老鳥。

1.代碼沒有可讀性

寫好代碼很難，但是理解錯(cuò)誤的代碼更難。雖然在我們剛?cè)胄械臅r(shí)候，這個(gè)體現(xiàn)得不是很直觀。

下面是我整理的一些關(guān)于代碼可讀性上的關(guān)鍵錯(cuò)誤，千萬別犯了。

• 同一行代碼上有多個(gè)嵌套的 if/else 語(yǔ)句
• 過度使用鏈?zhǔn)椒椒?/li>
• 從堆棧溢出復(fù)制/粘貼正則表達(dá)式，不帶注釋
• 過度抽象

雖然我們應(yīng)該把邏輯壓縮到最小，但這也會(huì)讓我們的代碼變得不可讀。即使是一些編程老鳥，在可讀性方面也會(huì)經(jīng)常犯錯(cuò)誤。

調(diào)試代碼的難度是編寫代碼的兩倍。因此，如果你花了大量的時(shí)間和精力編寫了很漂亮但不可讀的代碼。根據(jù)定義，那就是你還不夠聰明，無法調(diào)試它。--克尼根定律

2.使用沒有上下文的變量名

想出好的變量名很難，為了快速完成工作，我們經(jīng)常起一些事后很難回想起來的變量名。

例如，

• 用戶的姓名寫成uln；
• 很多電子郵箱寫成了陣列。

兩種做法都不好，這會(huì)讓很多人理解不了我寫的代碼，其中就包括我自己。

3.允許安全漏洞

為了讓我們的代碼免于遭到黑客攻擊，我們應(yīng)該反復(fù)檢查代碼，是否有以下錯(cuò)誤操作：

• 允許SQL注入
• 允許通過URL跳轉(zhuǎn)訪問受限頁(yè)面
• 僅使用前端驗(yàn)證
• 具有增量ID的命名空間URL

在檢查安全漏洞時(shí)往往會(huì)花很多時(shí)間來排查漏洞源，我現(xiàn)在在檢查其他開發(fā)人員的代碼時(shí)會(huì)著重檢查以上4項(xiàng)，趕緊回去檢查一下自己的代碼里有沒有這些安全漏洞！

4.拿到需求后立即開始寫代碼

如果我們這樣做了，后果往往是做無用功。花大量的時(shí)間在這個(gè)功能上，然后發(fā)現(xiàn)這個(gè)方向就是錯(cuò)誤的。

對(duì)于程序員來說，我們應(yīng)該深呼吸靜下心來，先理解業(yè)務(wù)問題并圍繞它來規(guī)劃代碼才是正確的做法。

現(xiàn)在，我一般都會(huì)讓新手程序員，在開始寫代碼之前，必須詳細(xì)地了解需求，做出規(guī)劃。這種規(guī)劃有助于理清思路，制定更有效的解決方案，從而避免浪費(fèi)時(shí)間做無效功。

5.注釋太多或太少

剛開始工作時(shí)，我不會(huì)對(duì)代碼進(jìn)行注釋。

然后，我經(jīng)歷了一個(gè)階段：對(duì)每一行代碼都添加注釋。 一個(gè)名為add_two_numbers的方法被注釋為＃將兩個(gè)數(shù)字相加。 這明顯是多余的操作。

現(xiàn)在回想起來，當(dāng)我看了很多其他開發(fā)人員編寫的代碼時(shí)，并注意到他們添加注釋的位置后，才真正規(guī)范地添加正確的代碼注釋。

6.推送重復(fù)和未使用的代碼

我曾經(jīng)做過這些傻事：

• 已存在于應(yīng)用程序中的編寫函數(shù)
• 保留自動(dòng)生成但未使用的文件（即：測(cè)試文件）
• 添加了沒有用的包

有些框架會(huì)自動(dòng)生成許多沒用的文件，換句話說，就是當(dāng)你開始用app時(shí)，你也不知道現(xiàn)有代碼會(huì)生成什么東西出來。

后來，我發(fā)現(xiàn)避免這些問題的最佳方法，就是在提交代碼前，仔細(xì)閱讀我們編寫的代碼，那么你就能夠快速找到問題所在。

7.編寫低效的數(shù)據(jù)庫(kù)查詢

我的第一份工作，對(duì)數(shù)據(jù)庫(kù)一無所知。我大概花了一年時(shí)間才計(jì)算出數(shù)據(jù)庫(kù)索引。

那時(shí)我寫了很多N+1查詢，創(chuàng)建了db表來存儲(chǔ)大量沒有索引的數(shù)據(jù)。

這兩個(gè)都是運(yùn)行緩慢，讓人厭煩的APP都會(huì)用的數(shù)據(jù)庫(kù)查詢索引。

8.使用基于錯(cuò)誤的條件邏輯

條件 if / else 語(yǔ)句是軟件的核心部分。

在偽代碼中，它們通?？雌饋硐襁@樣。

if x is true 
do this 
else 
do that 

但是在我參與編寫的第一個(gè)APP中，用了這樣的邏輯：

do this 
if this fails 
do that 

當(dāng)我們遇到不可靠的API時(shí)，就需要挽救錯(cuò)誤，雖然這只是例外。

9.提交包含多個(gè)功能的代碼以供審核

在工作中，我學(xué)到的第一件事就是不要在同一個(gè)審批請(qǐng)求中合并多個(gè)功能。這對(duì)審查代碼的人很不友好。

超過幾百行的代碼，會(huì)讓人很難集中精神看完那么多功能模塊。

我經(jīng)常跟新人說，如果他們認(rèn)為一個(gè)功能可以進(jìn)一步細(xì)分，那么我們就要后退一步，把它分得越小越好。

結(jié)論

學(xué)習(xí)編程是很難的一件事。你只能通過實(shí)踐來學(xué)習(xí)多種寫代碼的技巧。

不知道你看了我犯過的編程錯(cuò)誤有什么感想？

在我們的IT職業(yè)生涯中，總有那么一個(gè)大神，幫助我們，把我們提交的每一段代碼給出詳細(xì)的反饋，我們才能一邊犯錯(cuò)，一邊成長(zhǎng)。

以上是本文的所有內(nèi)容，希望能給編程新人一些幫助！