這兩天一直在考慮一個問題，在公司表現不錯，基礎知識扎實的實習生，每天馬不停蹄地編碼，完成任務，怎么提升自己的能力呢？
首先分析一下，不停編碼的原因：
1.業務不熟悉，導致在開發的時候需要深入去了解業務，導致技術和業務之間不停地切換，降低開發效率;
2.設計不合理，不合理的設計加上緊迫的開發時間，導致代碼質量從合乎規范到冗余到混亂不堪，逐漸淪陷為自己眼中的“垃圾代碼”;
3.不夠專注，一天時間其實不多，程序員最怕的就是開發的時候，突然有個啥事叫到，然后花了一大片的時間，最后得知是操作人操作失誤，或者是一個優先級並不高的東西;
4.任務真的重，真的多（一般情況很少啦， 如果是真的每天都是拼了命寫都寫不完，那剛開始的計划排了還有什么作用呢？）
分析完原因之后，定位一名程序員實習生或者剛剛工作不久，常思考工作層面的程序員：
業務方面的問題，有這個一個現象，大多數的程序員都有一個想法，“我只做技術開發”，我對業務不需要有太深入的理解和滲透，可是優秀的架構和設計編碼總是服務於業務的，脫離業務技術就失去了意義。而且熟悉的業務能夠讓你在編碼的時候考慮更加全面，在設計程序架構的時候能夠規避風險和評估影響范圍，有這么一種情況，就是不熟悉業務的程序員，可能連自己的代碼犯了很明顯的錯誤之后，他是完全不知道，這想當於這位程序員開發的代碼就是“三不管”地帶了。
設計，對於剛剛入門程序開發的人來說，總是覺得編碼比設計總要，先實現了再優化設計，再改造，好的設計就像建築打地基，代碼結構初期沒有詳細的設計就投入開發，后面很容易就遇到需要將前面翻新從來的噩耗，所以將設計修改（即使是自己的小修改）都應該歸入設計不合理，需要反思的地方。代碼編程，設計先行。
專注，互聯網公司一般是大而寬敞的空間，這給團隊交流帶來了很好的推動力，但是帶來的是一個專注度的問題，一個線上問題來了，推到開發程序員的手邊，客服說是十萬火急的事情，然后開發就拋下手邊的開發到一半的模塊，然后投入線上問題的修復，2個小時之后，問題修復，回來自己的代碼，又需要很長的時間去重新思考設計，重新融入編碼的氛圍。
一個真正好的程序員，肯定不是在編碼上出色，他是將技術和業務深度結合，編碼計划合理，設計規范的good coder.致所有正在加班的你，將眼睛閉上，思考自己是怎樣的一種處境，怎么讓自己提升而不是成為01世界里面的廉價勞動力。