新手程序員常犯的十個錯誤

先介紹下背景，博主由運營轉行前端，入職一個月，完成了一個相對較大的模塊。因爲基礎相對薄弱，犯下了很多錯誤，故想記錄下來警醒本身和分享各位。

前端技術棧是 ES6 + backbone + react + antdUI,後端使用的 Ruby on Rails。

1.未遵循MVC分離思想

MVC提及來很是簡單易懂，即model+view+controll，數據-視圖-控制分離，特定的模塊作特定的事情，便於程序的維護和拆分。個人體驗是我有這個意識，卻經常寫出不合規範的代碼。

出現問題的緣由是抽象是不符合人的天性的，天性就是怎麼簡單怎麼來，不會顧及到總體架構如何。

解決辦法也很簡單，改！ 不停的修改你的代碼，改到完美爲止！改的過程當中不斷告訴本身，我這樣寫是錯的，下次不能這樣寫。堅持一段時間頗有效果。

2.缺乏必要的註釋

大段的if-else缺乏註釋，讓維護者沒法快速分辨分支邏輯。特定地方存在hack或複雜邏輯的代碼，缺乏註釋會讓後來者不明因此。爲了你好，也爲了後來者好，請務必加上代碼。說不許之後仍是由你來維護這段代碼。

3.不變和變化的部分拆分

程序員中流傳着一句話，此處不要寫死，未來必改。有經驗的程序員會將一些業務層的邏輯抽象出來，寫成配置文件，好處就是若後續需求有改變，只需改配置文件便可，確定不會引入bug。

4.忽視測試部分

程序員中又流傳着一句話，沒有測試的代碼等於沒寫。雖不敢所有贊同，卻也有幾分道理。從測試用例驅動開發，持續集成，每次編譯自動跑測試用例，可以保證系統的穩定同時也減輕測試成本。本身改的的部分作好自測，理解需求，作一個有責任心的工程師。

5.直接操做數據

你應該經過方法去操做數據，而不是直接操做數據,這樣可以保證你總能操做數據正確。
例如一個類中定義的屬性發生變化了，代碼中全部涉及到直接操做該屬性的代碼都須要修改。若是經過方法操做該屬性，則僅需修改操做方法，對於外部調用者，類屬性變化被屏蔽了，遵循瞭解耦的原則，代碼穩定性大大提升。

6.代碼中存在hard code

hard code=>魔法數字，後果是代碼中不明因此的數字處處亂飛，讓人讀來莫名其妙，全然不動其中的意思。若是你不想你的代碼被人破譯，請盡情的使用hard code吧

7.寫重複的代碼

DRY,don't repeat yourself! 這個話題聊起來估計三天三夜也說不完。電腦擅長人不肯意乾的、重複的事情，因此電腦解放了人類。那麼程序員如何解放本身呢？那就是不寫重複的代碼，其中一個準則就是三次。一件事情重複三次，就能夠從中提取出規律。

Example: 1， 2， 3， ....

Example: 1， 2， ....

8.不懂debug和如何解決問題

寫代碼從debug開始。每個初學C語言的人都會遇到各類各樣的問題，譬如缺了分號，if判斷寫成賦值。初學者不瞭解語言和其中的坑，惟一能解決問題的就是一步一步進入代碼的執行，找到其中不合預期的地方，即爲bug所在。找一個稱手的IDE，學習一下debug，80%的問題就會被文檔和debug解決

9.不規範的工做流

制定合理的工做流程可以減小風險事故的可能和提升工做效率。
對於程序員來講，work flow更意味着代碼的組織，工做成員之間的協做方式。
我常犯的一個錯誤是直接在alpha或master分支上直接commit，而團隊是不容許這樣作的。全部的修改必須只能經過 merge 的方式合併到主分支，這樣的好處在於避免bugfix僅在alpha上處理，而忘記merge到master上。這些均可以經過 CI 或者git hook 等一些腳本或工具完成。

---

良好的編碼習慣不是一日養成的，要從各個細節處不斷修正提升。好的代碼結構清晰，讀來賞心悅目，壞的代碼，混亂糟糕，讓維護者忍不住罵娘。一位初學者要不斷地讀大師的代碼，汲取其中的營養，不斷修改本身的代碼，祝願各位有朝一日都能寫出優雅的代碼。