雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
在我們剛開始走進IT行業時，寫代碼總會戰戰兢兢，不斷地向前輩大神請教，經過反複确認之後才敢釋出代碼，釋出代碼後也會時不時看背景，會不會産生BUG......
下面我來列舉一些我作為一個菜鳥時，經常犯的一些錯誤，希望能幫助大家及早改正，早日成為程式設計老鳥。
1.代碼沒有可讀性
寫好代碼很難，但是了解錯誤的代碼更難。雖然在我們剛入行的時候，這個展現得不是很直覺。
下面是我整理的一些關于代碼可讀性上的關鍵錯誤，千萬别犯了。
- 同一行代碼上有多個嵌套的 if/else 語句
- 過度使用鍊式方法
- 從堆棧溢出複制/粘貼正規表達式，不帶注釋
- 過度抽象
雖然我們應該把邏輯壓縮到最小，但這也會讓我們的代碼變得不可讀。即使是一些程式設計老鳥，在可讀性方面也會經常犯錯誤。
調試代碼的難度是編寫代碼的兩倍。是以，如果你花了大量的時間和精力編寫了很漂亮但不可讀的代碼。根據定義，那就是你還不夠聰明，無法調試它。--克尼根定律
2.使用沒有上下文的變量名
想出好的變量名很難，為了快速完成工作，我們經常起一些事後很難回想起來的變量名。
例如，
- 使用者的姓名寫成uln；
- 很多電子郵箱寫成了陣列。
兩種做法都不好，這會讓很多人了解不了我寫的代碼，其中就包括我自己。
3.允許安全漏洞
為了讓我們的代碼免于遭到黑客攻擊，我們應該反複檢查代碼，是否有以下錯誤操作：
- 允許SQL注入
- 允許通過URL跳轉通路受限頁面
- 僅使用前端驗證
- 具有增量ID的命名空間URL
在檢查安全漏洞時往往會花很多時間來排查漏洞源，我現在在檢查其他開發人員的代碼時會着重檢查以上4項，趕緊回去檢查一下自己的代碼裡有沒有這些安全漏洞！
4.拿到需求後立即開始寫代碼
如果我們這樣做了，後果往往是做無用功。花大量的時間在這個功能上，然後發現這個方向就是錯誤的。
對于程式員來說，我們應該深呼吸靜下心來，先了解業務問題并圍繞它來規劃代碼才是正确的做法。
現在，我一般都會讓新手程式員，在開始寫代碼之前，必須詳細地了解需求，做出規劃。這種規劃有助于理清思路，制定更有效的解決方案，進而避免浪費時間做無效功。
5.注釋太多或太少
剛開始工作時，我不會對代碼進行注釋。
然後，我經曆了一個階段：對每一行代碼都添加注釋。 一個名為add_two_numbers的方法被注釋為＃将兩個數字相加。 這明顯是多餘的操作。
現在回想起來，當我看了很多其他開發人員編寫的代碼時，并注意到他們添加注釋的位置後，才真正規範地添加正确的代碼注釋。
6.推送重複和未使用的代碼
我曾經做過這些傻事：
- 已存在于應用程式中的編寫函數
- 保留自動生成但未使用的檔案（即：測試檔案）
- 添加了沒有用的包
有些架構會自動生成許多沒用的檔案，換句話說，就是當你開始用app時，你也不知道現有代碼會生成什麼東西出來。
後來，我發現避免這些問題的最佳方法，就是在送出代碼前，仔細閱讀我們編寫的代碼，那麼你就能夠快速找到問題所在。
7.編寫低效的資料庫查詢
我的第一份工作，對資料庫一無所知。我大概花了一年時間才計算出資料庫索引。
那時我寫了很多N+1查詢，建立了db表來存儲大量沒有索引的資料。
這兩個都是運作緩慢，讓人厭煩的APP都會用的資料庫查詢索引。
8.使用基于錯誤的條件邏輯
條件 if / else 語句是軟體的核心部分。
在僞代碼中，它們通常看起來像這樣。
但是在我參與編寫的第一個APP中，用了這樣的邏輯：
當我們遇到不可靠的API時，就需要挽救錯誤，雖然這隻是例外。
9.送出包含多個功能的代碼以供稽核
在工作中，我學到的第一件事就是不要在同一個審批請求中合并多個功能。這對審查代碼的人很不友好。
超過幾百行的代碼，會讓人很難集中精神看完那麼多功能子產品。
我經常跟新人說，如果他們認為一個功能可以進一步細分，那麼我們就要後退一步，把它分得越小越好。
結論
學習程式設計是很難的一件事。你隻能通過實踐來學習多種寫代碼的技巧。
不知道你看了我犯過的程式設計錯誤有什麼感想？
在我們的IT職業生涯中，總有那麼一個大神，幫助我們，把我們送出的每一段代碼給出詳細的回報，我們才能一邊犯錯，一邊成長。
以上是本文的所有内容，希望能給程式設計新人一些幫助！
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-05-27
本文作者：為AI呐喊
本文來自：“
cocoachina”，了解相關資訊可以關注“cocoachina”