爱华网对于在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、08年谈SOA还很前卫，然后云计算、分布式火了几年，10年起移动开发又成为了大热门，13、14年大数据技术开始被热炒。技术人员会担心“学无止境”，老了后如何跟得上这狂热的节奏啊?
不光是软件行业，很多行业都日新月异，新的技术被引入，新的方法被创造。大部分职业都在不断的学习过程中，而且似乎这种学习是没有止境的。有不少人都存在这样的担心，如果失去了学习的能力，职业的发展是否就此停滞了。不过这种担心在工科行业中表现得更突出一些。
拿写程序来说，程序框架的发展是很快的，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年了，如果写在简历上的话，都能算资深软件人了。对很多方面有一些想法，想写一本书。会在公众账号上发一些样张，欢迎大家督促成书。感谢!有兴趣的朋友欢迎交流，欢迎关注我的公众好“语新童话”
