1、命名不規範
命名很隨意，當時寫**特別high，什麼奇奇怪怪的命名都有的，完全意識不到全名規範的價值和意義。
2、不寫單元測試
確切來說，是不按tdd的方式開發。在現在ide這麼強大的情況下，先寫單元測試的習慣，不僅僅是**的嚴謹性，也是效率的代名詞啊。好的單元測試，邏輯必然會清楚
3、先整合，再測試，再放棄。
很多時候，初級程式設計師在引入第三方的庫，框架，介面或者是服務的時候，最喜歡的事情就是直接和自己原有的**整合在一起。好的方法是先跑通官方提供的demo，再想辦法一點一點加上自己的業務。
4、理不清楚邏輯，邊做邊猜
前端在這裡的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是介面處理好資料展示好拉倒。很多初級程式設計師都會有這種習慣，這樣不好，先把邏輯處理好，弄清楚流程，再去動手才好。
5、不關注效能
不關注效能也是新人很容易犯的錯。什麼是效能呢。對後端來說就是tps和響應時間，對前端來說就是響應時間。很多新人程式設計師的習慣就是把東西做出來，然後再優化。最後就是東西做出來了，優化留給別人了。對效能的關注也是晉公升中級程式設計師最關鍵的技能點。在寫**的時候，有經驗的工程師已經知道了這個方法這個函式這個功能點的效能怎麼樣，瓶頸在**。
6、害怕重構
程式設計師最大的勇氣就是看自己三個月之前寫的**。其實重構並不應該是在幾個月之後重構，最好的方式是實時重構。寫一天**，70%的時間都放到重構上都不過份。不重構在某種程度上也意味著你的**實現無法重塑。
7、做出來就好，不考慮優雅的方案
有個詞叫做最佳實踐，其實編碼規範和最佳實踐，是程式設計功底的重要體現。優雅方案可以認為是最佳實踐的公升級版，它和上面說到的不斷的重構是相輔相成的。不好的方案是什麼呢？硬編碼居多，沒有可擴充套件性，用很醜陋的方式完成了功能。
8、遇到問題的時候不會試錯
這也是初級程式設計師常見的問題。很多時候初級程式設計師會遇到問題，解決不了，去找乙個有經驗的工程師，這個有經驗的工程師呢，大概也未曾遇到這種情況，但是他解決問題的思路很清楚。一會兒試試這個，一會兒刪刪那段**，很快就跑通了。解決問題就是乙個分析推理的過程，而在這裡呢，背後的功底就是你知道很多哪些是肯定不會錯的小公理，然後再挨個去定位可能產生錯誤的環節，分解流程是最基礎的工作。
從初級程式設計師到CEO的蛻變
從初級程式設計師到ceo的蛻變 現在對程式設計師的普遍 暗黑 看法是，這是一群所有時間都窩乙個黑暗的房間裡，與數百萬行 為伍，也許甚至不具備人際交往能力的 程式猿 好吧，雖然我也有程式設計背景，所以可能會有點偏頗，但是這顯然是無稽之談。php程式設計師不僅能力卓絕 是創造現代生活和商業的基石，而且還...
從程式設計師到CEO
從程式設計師到ceo 序言 今天我無意中在網路上看到某位仁兄通過部落格出了一本 程式設計師的羊皮卷 我突然感覺這個世界表達個人際遇的機會太多了。同時作為一名在it行業打拼了近15年的老鳥的我，覺得很多時候年青人的區辨力，很多時候比較隨波，如果我們能及時的多種真實的聲音，我想可以為新人提供多點參考。我...
從程式設計師到非程式設計師之部落格篇
最近工作有所調動，現在已經不是程式設計師崗了，正好藉此文章，說說我非程式設計師生活中的些許沉澱。也籍此送給公司的sun同事，以感謝他一直以來對我寫作的支援。我非常熱愛程式設計師的工作 coding。因為每一次寫 心中總會有很多湧動的熱血，經常支撐著我徹夜地思維。為什麼？編碼對於我來講，已經不僅僅是工...