1.方案不論證，直接使用
遇到一個問題時，以自己的思路找出一個解決方案，接下來直接去實現他。並不會去考慮該方案的實現效率和實現危機。方案本身看似沒有問題，但是在最初只是爲了解決該問題，從問題本身衍生出的擴展邏輯，其實你並沒有很好的關注到。作爲專業的程序員，你的職責不是找出問題的一個解決方案，而是找出問題的最簡單的解決方案。我所說的“簡單的解決方案”是指這個解決方案必須是準確的，性能足夠好，還要易擴展、易理解和易維護。
2.從不願意花時間搜索問題
很多情況下，搜索自己遇到的問題，是可以很容易找到最優解的，你的問題在別人那裏可能已經被解決，並提出了各種各樣的解決方案，這個方案可能比你理解的更全面，更徹底。因此，在遇到問題的情況下，首先百度一下，也是一種很不錯的解決問題方式。但是，這裏的誤區在於，你直接copy別人的代碼，而不去思考爲什麼這樣寫的情況，可能會導致你只會成爲一個問題的搬運工。對你的成長並沒有什麼好處。
3.從不重構代碼
從學習編程的第一節課，就會遇到一個標準的編程思想：高內聚和低耦合。這個思想不僅僅是編程的核心，也是整個編程生涯中，最重要的一句話。在一個應用中，一個功能應該只在一個地方處理，這通常就是一個對象的職責，這個對象應該只向其他需要用到它的對象暴露必須的接口。這無關乎機密，而是爲了降低一個應用中的不同部分之間的相互依賴。敏捷開發過程中，效率帶來的，往往無法兼顧這樣的問題。因此，後續帶來的就是所謂的重構代碼問題。因此，問題的關鍵在於，從一開始就要以高內聚和低耦合的思維去編程，而不是爲了省事事後重構，業務的複雜性加上“騎驢找驢”的線上特性，使得重構難度將大大的增加。
4.做一些多餘的計劃方案
解決問題時設計的方案，可能會多方面的去考慮實現的穩定性，可讀性，以及後續的業務擴展，但是這樣就會有多餘的“萬一”場景出現在你的代碼裏，這樣做會大大的降低業務開發的效率。在這裏，針對這一點，要強烈的提出一點，任何代碼的實現都是以業務驅動的。離開了業務形態，你的代碼就沒有任何用處。過多的兼顧只會降低代碼的性能，大大增加了業務的複雜性。這樣的形式在開發中是絕對不可取的。
5.精通算法，並不等於自己編程能力強
面試的過程通常要經過所謂的算法關，利用算法去實現各種各樣的高性能的最優解。但是這些算法在現實中並不一定會用到，大部分情況下，都是簡單的邏輯去處理複雜的事情，畢竟從可讀性上來講，性能並不一定到達最優解的情況，一般只需要次優解即可。而通過各種高大上的算法去解決問題的情況，會使得代碼的維護和可讀性的難度大大的增加。因此，判定自己的編程能力的高低，是自己的代碼具有很高的可維護性，可讀性，和穩定性。
6.代碼的實現要符合既定的邏輯
代碼管理是一項很重要的內容，從最基本的代碼格式，到文件命名，再到文件包分類，最終的配置文件分離都是編程過程中，特別需要注意的點。需要經常更新的值，就放在配置文件中，BO層文件，就放到BO文件夾裏，這樣一目瞭然的文件目錄，會讓你的代碼風格變得更加可控。在合作開發中，你的代碼將更加符合別人的閱讀習慣。
7.大量的代碼註釋
爲了別人讀懂你的代碼，而過多的增加註釋，這種方式是絕對不可取的。最好的代碼可讀性是一目瞭然的，通過函數名去給與代碼天然的註釋，而不是依靠自己的註釋去告訴大家這段代碼實現的意義。由於對於顯而易見的代碼，更不要去增加多餘的註釋，這樣反而會吸引人的目光，降低讀寫的效率。
8.代碼沒有測試
自我測試是一個很好的過程，你寫過的每一個代碼，爲了保證能夠主流程的通暢，自測的過程是必不可少的。不要覺得這件事麻煩，在自測的同時，也是代碼穩定性的一種驗證，可能在細節處理上很難發現的坑，在測試過程中就會體現。如果你是一個新手，代碼的自測環節將會是你最基礎的一個步驟。
