很多剛剛入行的同事，他們能有自己的想法，我鼓勵他們用自己的想法去實現，但是我對他們最低要求是實現功能同時，能夠保證代碼的閱讀性，能夠保證代碼的一定質量。和所有人一樣，首先你能夠實現產品的功能，如果你不能實現也沒關系（偶爾一兩次），必須要講清楚不能實現的原因，我鼓勵他們加入自己動腦去思考，而不是成為一個麻木的復制粘貼的碼農。希望他們能夠從一開始就養成愛思考的，會寫代碼的程序員。下面說說一下，看了他們代碼，覺得不足的地方吧。

（一）很多重復的代碼

對於剛剛入行的人來說，他們很容易的就會犯這個錯誤，因為有些時候，復制對於實現一個類似的功能來說，可能更快。尤其是進度比較趕的時候。你說項目趕，然後你去復制了代碼，去讓自己的代碼重復，我覺得這樣做反而更不好。首先不說遠的，就當你要改一下你復制這段代碼，你都要改變那幾個地方。等下又忘記了，就會給系統留下Bug。

（二）寫代碼缺少遠見

平時在開發環境下， 由於數據量少，一個請求看起來都不是很慢，但是很多時候到了真正的開發環境下，系統真正的開始用起來了，數據量不斷增長，慢慢的整個系統都會變得很卡，最終這個系統就爛掉了，所以大家寫代碼的時候，一定要前瞻性，考慮到今後三五年的變化，就算現在做不到，至少意識要有。

（三） 命名很亂，代碼不夠整潔

可能很多人都是看了很多關於代碼整潔之道的書，代碼整潔，其實要保證的就是命名規則良好，命名盡量都用英文。平時也要養成自己的習慣，哪些要怎麽弄，怎麽做。就比如簡單的查詢一個列表，應該是從路由，到方法名，都是可以體現出這是和列表相關的，對應列表，我比較喜歡用，QueryUsers 查看詳細，GetUserDetail。就是類似於這樣。很多時候，可能都在糾結如何命名，有一個好的辦法就是，多看高手寫的代碼，特別關註下，別人怎麽命名的，然後學習他的。

（四）寫代碼比較心急

有些時候，理解不夠，就馬上動手寫代碼，最後就是一場空。所以各位切記不要急著寫代碼，必須了解清楚的需求，並且在寫在做的時候，應該要考慮未來幾年內的變化。

（五） 從用戶角度出發

不去模擬實際的業務場景，啥事都來問我，寫代碼時候，始終牢記一點，技術是給人帶來方便，減少人的負擔的。所以實現某個功能的時候，需要去想想實際的業務場景是什麽。

由於時間關系，暫時就總結這麽多了。上面的都是我個人覺得很重要的。簡單兩個字，就是“思考”。

寫給剛入行的小夥子們