it人士的職業壽命_IT從業人員應如何做好職業規劃

　　對于在IT是否可以做一輩子技術“牛人”的問題，我想很多it人士都想知道答案。以下是第一范文網小編分享給大家的關于it人士的職業壽命以及IT從業人員應如何做好職業規劃，供大家閱讀!

　　35歲是眾多IT人的一道坎兒嗎?職業顧問專家分析說，。

　　職業顧問樂富認為，從個人角度看，很多人因為IT行業收入高、熱門、找工作方便等理由，茫然地選擇了這份工作。但工作以后，發現這個職業遠非自己想像得那么美好，需要整天對著機器編程、糾錯;如果選擇這份職業的人的個性偏好、天生才干不適合從事這份工作，那么他一定會比別人付出更多的時間和精力，他會懷疑自己的選擇，直至否定自己。

　　IT行業的技術更新非常快，這便逼迫這一行業的人不斷補充新知識、學習新技術。一些人，特別是女性，在35歲期間正面臨著人生的眾多轉折，從單身到結婚，或有了寶寶，家庭牽扯了她們很大的精力與時間，以至于無法投入更多時間學習新知識、新技術。在這個快速發展的年代里，你原地踏步，而別人快速前進，便意味著你被拋棄。

　　因此，那些原本便不適合從事這個職業的人，他們最容易在30歲前后產生“疲態”，就像800米賽跑，前面一圈還可咬著牙緊追，后面一圈看看實在是與第一名差距太大，人的內心便開始打架，猶豫、彷徨，最終自己就停下腳步了。

　　如何跨過年齡坎兒?樂富認為：一要了解、分析自己的職業興趣，看看自己是否適合從事技術工作，是否能夠終生學習，是否對探索問題、發現問題、解決問題保持長久的興趣。二要依自己的職業興趣、個性偏好與職業滿足感來選擇職業，而不是隨大流、看報酬。第三，投資這個職業之前，最好能與業內人士交流、探索，或到工作場所實地看看，以確保最初選擇(所學專業、第一份職業)的正確性。

　　其實，35歲的職場人具備了心智成熟、處事老道、經驗豐富、專業精湛等特點。職業顧問可銳認為，從技術研究咨詢顧問管理工作的角度，35歲應該是人生的又一次上升期。當然，是否能夠達到這樣一個結果，關鍵就看你在這個階段前后是否已經做好這個準備，給自己一個清楚的定位。

　　在這樣一個好時段，很多IT人卻沒有能夠好好把握。樂富指出，目前IT人普遍存在以下問題：重技術輕管理，重戰術輕戰略;關注與機器“對話”，缺乏與人相處、交流、溝通與協調的技術(藝術);性格內向，閱讀或興趣面較窄;重思考輕行動。基于這些特點，大多數IT人缺乏在職業生命的中后期(32～40歲)“尋隙卡位”的思路，即沒有“投資職業，終生經營”的意識。這樣，他們中的98%便難以上升到管理階段。

　　對于在IT是否可以做一輩子技術“牛人”的問題，幾乎所有的職業顧問都持肯定態度，但一個基本條件是，你必須一直緊跟技術發展的腳步。這種緊跟說難不難，說容易也不容易。我們知道，IT技術的發展不是突變的，它在一年內的相差不會很大，但如果回過頭來看幾年前的情況，你就會嚇一跳，原來，距離在不知不覺中被拉大了。因此，如果每年你都能跟著技術進步的話，你的壓力就會很小，因為你時刻都是走在技術的前端，但如果你一旦不小心慢了下來，再要趕上就會很吃力了。

　　樂富認為，那些對技術真正有興趣，而且樂意不斷學新技術的人，一定可以在IT行業做一輩子的技術“牛人”。一位在加拿大從事技術開發工作的IT人說：在他的公司里，有不少年齡超過40歲的工程師還樂此不疲地學習新技術，他們從事這份工作很單純，因為喜歡編程，然后讓同事“抓錯”，他也喜歡“抓”同事的設計錯誤。以這樣的心態，這些技術工程師工作得很開心。

　　和朋友聊天，談起技術工作者的職業壽命問題。大致上是覺得現在很多行業的新技術處于爆發狀態，軟件行業來看，07、20xx年談SOA還很前衛，然后云計算、分布式火了幾年，20xx年起移動開發又成為了大熱門，13、20xx年大數據技術開始被熱炒。技術人員會擔心“學無止境”，老了后如何跟得上這狂熱的節奏啊?

　　不光是軟件行業，很多行業都日新月異，新的技術被引入，新的方法被創造。大部分職業都在不斷的學習過程中，而且似乎這種學習是沒有止境的。有不少人都存在這樣的擔心，如果失去了學習的能力，職業的發展是否就此停滯了。不過這種擔心在工科行業中表現得更突出一些。

　　拿寫程序來說，程序框架的發展是很快的，API的數量呈爆發式的增長。這是這些表象的快速發展，形成了技術爆發的感覺。似乎永遠在學，而永遠也學不完。

　　難道一個J2SE的程序高手，在MapReduce的時代就沒有價值了嗎?

　　面試的時候也常常遇到一面試者談起想換工作的原因是，寫SSH框架寫太多了，覺得膩了，想寫寫MapReduce，覺得比較火爆。他們的想法對嗎?難道MapReduce寫膩了，或者說新的火爆的框架出現了，再學習再換么?

　　我的感覺是所有的技術的發展都是成體系發展的，技術的基石在一定程度上是很穩定的。例如整個物理學的大廈都是基于幾個簡單的定理的，現代數學、化學都是建立在古典理論基礎之上的;就算文學、美學等人文學科也是這樣。

　　站在程序角度來說，對各種框架的熟練運用還是表象。無論是傳統的J2SE，還是SSH三大框架，或者EJB，以至于現在火爆的Activity和MapReduce,都是這樣。所謂的學習，大部分是對API的使用方法的學習。

　　寫程序的體系，或者說基石存在么?又是什么呢?

　　我認為基石就在我們學習程序的第一課——面向對象。什么是面向對象，不同的理解就能寫出不同的程序，這種理解是我們程序的靈魂，各種API變得只是工具。

　　舉幾個例子吧，寫了3年的SSH，對如何拆類拆包有理解么?寫了3年MapReduce的程序自己寫了幾次父類、定義了幾個接口?寫了3年Activity，怎么看設計模式了?或者說程序的擴展性怎么體現的?其實以上幾個問題無論用什么框架都回答不了，但是無論專注寫哪個框架都會對以上幾點的理解加深。所以證明了程序理念和框架無關的，框架只是外在的表現。

　　當然不得不承認，有些框架寫多了確實會限制思維，比如SSH框架就封裝的比較徹底了，大部分寫SSH程序的程序員都不需要太考慮繼承的問題。但這不并不是問題的本質，如果能認清其關鍵，還是能有意識的規避這些思維限制的。

　　另外一個例子是，如果看過一些源碼的話，不管是傳統框架的源碼還是大數據、分布式、移動客戶端的源碼，都是很面向對象的。各種接口、父類、抽象類。說明了再華麗的框架其實本身都還是建立在面向對象的基礎之上的。

　　因此我建議，如果一個程序員在對程序理解的能力沒有提升的情況下，頻繁換框架并不是一件好事，最后只能浮于對API的掌握熟悉程度上。

　　說起我對面向對象寫起來的感覺，我覺得接口、抽象類、默認實現類、父類、業務子類，就像是畫素描，一層層的細化。開始只有一個框架，逐步實現，把抽象逐步實例化業務化。寫程序變得像是一次藝術創作的過程。我比較喜歡MINA的源碼，接口和抽象類的結構很清晰，就像是大師的速寫，寥寥數筆就把框子輪廓畫了出來。以后的實現類都是對細節的刻畫。

　　這樣的感覺很好，其實也多少能回答一個問題，程序員是不是碼農?我覺得不是，因為程序員其實是藝術家，程序員創造程序結構的過程和作畫很像。而不單單是對API的堆砌。這有些偏題了，對碼農的看法在以后的章節再說了。

　　有了程序感覺后，無論做什么類型的程序架構設計都很容易上手的。對于API的簡單了解后就能設計結構合理、擴展性強、可維護、易讀的程序了。這也是高級程序員和初級程序員在價值上的區別。回想周圍，有經驗的程序員往往簡單的學習了幾天就能開始做很頂層的設計了。而初級的程序員即使對一個框架做了很久，仍然不能達到設計的水平。就是這個道理。

　　但是有了程序感覺后，是不是就萬能呢?當然也不一定，但是只要面向對象還是主流的話，總還是可以依賴的。如果有新的編程理念成為主流的化，那可能就會比較大的一次觀念轉變了。就好像很多人還是容易寫出很結構化的程序一樣，這種理念的轉變不容易。

　　對于其他行業的同志，我雖然不了解，不過我相信也是一樣的，找到屬于自己的體系和基石。所謂一法通百法通，就能真正理解自己到底在學習什么，要學習的東西也更容易上手。

　　突然發現做軟件相關工作7年了，如果寫在簡歷上的話，都能算資深軟件人了。對很多方面有一些想法，想寫一本書。會在公眾賬號上發一些樣張，歡迎大家督促成書。感謝!有興趣的朋友歡迎交流，歡迎關注我的公眾好“語新童話”