目錄
一、轉載地址
如何讓自己看起來不像編程菜鳥?別犯這9個編程錯誤 去看看
二、轉載內容
前言
-
在我們剛開始走進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 語句是軟件的核心部分。
在僞代碼中,它們通常看起來像這樣。
if x is true
do this
else
do that
但是在我參與編寫的第一個APP中,用了這樣的邏輯:
do this
if this fails
do that
當我們遇到不可靠的API時,就需要挽救錯誤,雖然這只是例外。
9.提交包含多個功能的代碼以供審覈
-
在工作中,我學到的第一件事就是不要在同一個審批請求中合併多個功能。這對審查代碼的人很不友好。
-
超過幾百行的代碼,會讓人很難集中精神看完那麼多功能模塊。
-
我經常跟新人說,如果他們認爲一個功能可以進一步細分,那麼我們就要後退一步,把它分得越小越好。
結論
-
學習編程是很難的一件事。你只能通過實踐來學習多種寫代碼的技巧。
-
不知道你看了我犯過的編程錯誤有什麼感想?
-
在我們的IT職業生涯中,總有那麼一個大神,幫助我們,把我們提交的每一段代碼給出詳細的反饋,我們才能一邊犯錯,一邊成長。
以上是本文的所有內容,希望能給編程新人一些幫助!