其實(shí)這行的工資待遇和前景,比起一些風(fēng)吹日曬的苦逼行業(yè)還是要好不少的,很多人說程序員累,加班,掉頭發(fā)但其實(shí)在生存壓力面前這都不算什么,有哪一行是輕松的呢？起碼程序員技術(shù)到位了，工資還是比較可觀的。

不能懷疑別人

糟糕的程序總是說：“我的代碼一定是正確的，我懷疑編譯器有問題”，“我這應(yīng)該沒有問題吧，STL庫(kù)怎么這么難用啊”。我曾經(jīng)見過有程序員這樣使用STL類：map，當(dāng)他發(fā)現(xiàn)這樣放入字符串后卻取不出來，覺得那是STL庫(kù)的BUG，然后自己寫了一個(gè)map！我的天啊！

某些時(shí)候，過早的下結(jié)論是一個(gè)很不好的習(xí)慣，任何事情都有其原因，只有知道了原因，你才能知道是誰(shuí)的問題。一般來說，總是自己出的問題。

不能頑固

當(dāng)你給出一打證據(jù)說明那里有一個(gè)更好的方案，那里有一個(gè)更好的方向的時(shí)候，他們總是會(huì)倔強(qiáng)的認(rèn)為他們自己的做法才是最好的。一個(gè)我親身經(jīng)歷的事例就是，當(dāng)我看到一個(gè)新來的程序員在解決一個(gè)問題的時(shí)候走到了錯(cuò)誤的方向上時(shí)，我提醒他，你可能走錯(cuò)了，應(yīng)該是另外那邊，并且我證明了給他看還有一個(gè)更為簡(jiǎn)單的方法，有。然而，這位程序員卻告訴我，“那是我的方法，我一定要把之走下去，不然我會(huì)非常難受”，于是，在三天后的代碼評(píng)審中，在經(jīng)過頑固地解釋以及一片質(zhì)疑聲中，他不得不采用了我最先告訴他的那個(gè)方法。

這些程序員，從來不會(huì)去想，也不會(huì)去找人討論還有沒有更好的方法，而是堅(jiān)持自己的想法，那怕是條死路都一往直前，不撞南墻永不回頭。

盡量避免過多過常的創(chuàng)建java對(duì)象

盡量避免在經(jīng)常調(diào)用的方法，循環(huán)中new對(duì)象，由于系統(tǒng)不僅要花費(fèi)時(shí)間來創(chuàng)建對(duì)象，而且還要花時(shí)間對(duì)這些對(duì)象進(jìn)行垃圾回收和處理，在我們可以控制的范圍內(nèi)，最大限度的重用對(duì)象，最好能用基本的數(shù)據(jù)類型或數(shù)組來替代對(duì)象。

盡量使用final修飾符

帶有final修飾符的類是不可派生的。在Java核心API中，有許多應(yīng)用final的例子，例如java.lang.String。為String類指定final防止了使用者覆蓋length()方法。另外，如果一個(gè)類是final的，則該類所有方法都是final的。java編譯器會(huì)尋找機(jī)會(huì)內(nèi)聯(lián)(inline)所有的final方法(這和具體的編譯器實(shí)現(xiàn)有關(guān))。此舉能夠使性能平均提高50%。

以上就是動(dòng)力節(jié)點(diǎn)java培訓(xùn)機(jī)構(gòu)的小編針對(duì)“盤點(diǎn)一些Java程序員成長(zhǎng)路線”的內(nèi)容進(jìn)行的回答，希望對(duì)大家有所幫助，如有疑問，請(qǐng)?jiān)诰€咨詢，有專業(yè)老師隨時(shí)為你服務(wù)。