先介紹下背景，博主由運營轉行前端，入職乙個月，完成了乙個相對較大的模組。由於基礎相對薄弱，犯下了不少錯誤，故想記錄下來警醒自己和分享各位。
前端技術棧是es6+backbone+react+antdui,後端使用的ruby on rails。
mvc說起來非常簡單易懂，即model+view+controll，資料-檢視-控制分離，特定的模組做特定的事情，便於程式的維護和拆分。我的體驗是我有這個意識，卻常常寫出不合規範的**。
出現問題的原因是抽象是不符合人的天性的，天性就是怎麼簡單怎麼來，不會顧及到整體架構如何。
解決辦法也很簡單，改！不停的修改你的**，改到完美為止！改的過程中不斷告訴自己，我這樣寫是錯的，下次不能這樣寫。堅持一段時間很有效果。
大段的if-else缺少注釋，讓維護者無法快速分辨分支邏輯。特定地方存在hack或複雜邏輯的**，缺少注釋會讓後來者不明所以。為了你好，也為了後來者好，請務必加上**。說不准以後還是由你來維護這段**。
程式設計師中流傳著一句話，此處不要寫死，將來必改。有經驗的程式設計師會將一些業務層的邏輯抽象出來，寫成配置檔案，好處就是若後續需求有改變，只需改配置檔案即可，肯定不會引入bug。
程式設計師中又流傳著一句話，沒有測試的**等於沒寫。雖不敢全部贊同，卻也有幾分道理。從測試用例驅動開發，持續整合，每次編譯自動跑測試用例，能夠保證系統的穩定同時也減輕測試成本。自己改的的部分做好自測，理解需求，做乙個有責任心的工程師。
你應該通過方法去運算元據，而不是直接運算元據,這樣能夠保證你總能運算元據正確。
例如乙個類中定義的屬性發生變化了，**中所有涉及到直接操作該屬性的**都需要修改。如果通過方法操作該屬性，則僅需修改操作方法，對於外部呼叫者，類屬性變化被遮蔽了，遵循了解耦的原則，**穩定性大大提高。
hard code=>魔法數字，後果是**中不明所以的數字到處亂飛，讓人讀來莫名其妙，全然不動其中的意思。如果你不想你的**被人破譯，請盡情的使用hard code吧
dry,don't repeat yourself!這個話題聊起來估計三天三夜也說不完。電腦擅長人不願意幹的、重複的事情，所以電腦解放了人類。那麼程式設計師如何解放自己呢？那就是不寫重複的**，其中乙個準則就是三次。一件事情重複三次，就可以從中提取出規律。
example: 1， 2， 3， ....
example: 1， 2， ....
寫**從debug開始。每乙個初學c語言的人都會遇到各種各樣的問題，譬如缺了分號，if判斷寫成賦值。初學者不了解語言和其中的坑，唯一能解決問題的就是一步一步進入**的執行，找到其中不合預期的地方，即為bug所在。找乙個稱手的ide，學習一下debug，80%的問題就會被文件和debug解決
制定合理的工作流程能夠減少風險事故的可能和提高工作效率。
對於程式設計師來說，work flow更意味著**的組織，工作成員之間的協作方式。
我常犯的乙個錯誤是直接在alpha或master分支上直接commit，而團隊是不允許這樣做的。所有的修改必須只能通過merge的方式合併到主分支，這樣的好處在於避免bugfix僅在alpha上處理，而忘記merge到master上。這些都可以通過ci或者git hook等一些指令碼或工具完成。
良好的編碼習慣不是一日養成的，要從各個細節處不斷修正提高。好的**結構清晰，讀來賞心悅目，壞的**，混亂糟糕，讓維護者忍不住罵娘。一位初學者要不斷地讀大師的**，汲取其中的養分，不斷修改自己的**，祝願各位有朝一日都能寫出優雅的**。
新手程式設計師常犯的幾個錯誤
優效學院，名師執教，學習更優效，it 四六零五七零八二四 缺少必要的注釋 大段的if else 缺少注釋，讓維護者無法快速分辨分支邏輯。特定地方存在 hack 或複雜邏輯的 缺少注釋會讓後來者不明所以。為了你好，也為了後來者好，請務必加上 說不准以後還是由你來維護這段 不變和變化的部分拆分 程式設計...
程式設計師都會犯的十個錯誤
人非聖賢，孰能無過。尤其對開發者而言，幾乎每天都會有犯錯的可能。對於犯錯，你也不用太困擾，重要的是及時反思和總結錯誤，才能使自己進一步成長。此前，開發者daan 列舉了一些常見的錯誤，infoq對其進行了翻譯。希望你能從別人的錯誤中吸取教訓，成為乙個優秀的開發者。首先提到這個問題是因為，當錯誤被及時...
程式設計師的十個級別
第一級 神人，天資過人而又是技術狂熱者同時還擁有過人的商業頭腦，遠矚，技術過人，大器也。如丁磊，求伯君。第二級 高人，有天賦，技術過人但沒有過人的商業頭腦，通常此類人不是頂尖黑客 就是技術總監 之流。第 牛人，技術精湛，熟悉行業知識，敢於創新，有自己的公司和軟體產品。第四級 工頭，技術精湛，有領導團...