在知乎看到一个问题，相当有代表意义，即技术人员本身的技术发展瓶颈的突破问题。具体问题如下。
通常情况下，技术人员在某一领域工作3-5年后，会成为团队内或者公司里的核心技术骨干，这个时候他们也会面临几个问题：
技术学习的困惑： 当达到一个瓶颈时，可以学习的参考系越来越少，首先是因为高端技术人才呈现倒金字塔形态，身边缺少能引领你的人生导师；其次，业内的技术交流，大多数在做科普以及刷存在感，到达一定阶段后对个人提升作用越来越小（甚至用一天时间参加技术大会效果还不如用一天的时间在咖啡馆看书学习）；再次，国内的文化导致技术人专家逐渐转向管理岗位，技术缺少积累，特别容易出现断层和继承。
技术深度与广度的选择的困惑： 技术深度的进一步提升，可以逐步做到业界大牛，专业技能越来越强，广度的延伸也更容易变成全栈技术人才，两者各有利弊，个人时间和精力有限，如何抉择？
技术方向的困惑： 大型互联网公司的技术框架基本都在最初选型时确立，与当时的业务规划、业界当时的技术趋势、个人的过往经验积累相关，成熟规模大的业务从稳定性考虑，一般技术选型落后新技术2、3年，对于技术人员来说，从实际工作考虑需要使用老技术，但是业界的趋势又是在朝着新技术的方向发展。
这种困惑相信很多技术人员和技术管理人员都存在，包括我自己，当然这种困惑本身也是符合学习曲线规律的，即任何一个技术学习和实践，越是到后面学习的时间越长，本身能力提升越慢。但是往往真能够坚持和专注，能够耐得住寂寞等到量变到质变的那一刻，就是一种一览众山小的境界。
因此自己也从这三方面进行简单总结。
任何新技术或知识点的学习，在当前互联网和信息如此发达的情况下，只要你有兴趣就一定能够找到相关的学习资料进行自我学习，兴趣往往是第一个驱动点。
但是问题的关键点还是在于学习后的新技术如何深入，新技术如何去实践？没有真正的实践总结，没有真实的大型项目实战驱动，你将发现理论终归是理论，理论要转化为你的实战经验是相当困难的。
如果一个新技术的学习没有实战机会，那么你自己也很难真正保持长久的兴趣，能够做到熟悉或知道已经不错了，而要真正做到精通或理解就很难。大量技术的深入学习往往都是在实践中真正遇到了复杂的问题，在问题驱动下的学习和深入，这些错综复杂的问题往往涉及庞大的知识面，而且各个知识点之间相互影响。我们如果有实践机会能够不断地解决这类问题，不断优化和持续改进，技术自然深入。
举一个简单的例子来说。
对于海量数据处理下的高并发互联网架构，这类架构知识有不少书籍都在系统地讲，往往也有很大技术专家的实践分享。我们学习这些理论往往看起来简单，也容易理解，但是即使你学习了这些知识，如果没有相应的大型互联网系统架构设计场景给你实践，那理论终究是理论，这些理论本身你也很难真正的深入学习。
正是由于这个原因，技术学习的困惑不是简单的兴趣问题，而是是否有大型项目实践机会和锻炼的问题，但是往往大部分的公司都无法真正提供这种大型项目的机会，你要完全通过自己学习和模拟试验来深入掌握这些技术就变成了空话。
即使没有现场项目实践的机会，自己也要有意识地搭建假设场景进行学习成果的验证，这个步骤相当重要，虽然这些不是现场项目真实业务场景，但是至少你能够把学习到的技术知识点融合跑通，做到在原理上基本跑明白。
注意对于任何一个新技术的学习，刚开始一定要快速的突破入门阶段，并且通过快速的入门树立自己的学习信心，有了信心才能够推动你制定更加详细的迭代学习计划。也正是这个原因，实际在前面学习方法和模式文章中，我专门谈到新领域的学习一开始往往是不求甚解，理解清楚概念模型，并通过自己搭建环境快速验证。
对于知识深度和广度，我在前面谈知识管理的时候专门讲过，即：
知识的广度和深度之间存在依赖和制约关系，知识的深度需要足够的知识广度来支撑，当你发现无法在专业领域深入的时候，务必回溯知识的广度，先在广度上拓展，再来考虑如何将广度的知识抽象和浓缩为深度。 知识广度是为了支撑知识的深度，知识深度是为了创造核心价值。
对于技术学习的深度和广度问题，对于这个问题简单回答就是： 对于技术管理型人员重点是更广的知识面和综合能力提升，即广度更加重要而不是落入某一个深度细节。对于专业技术型人员，则是技术深度更加重要，往往技术的深度才能真正为你创造更大的价值。
技术管理型人员需要更加关注整个知识体系的构建 ，其中包括重要的软技能。这类人员的重点是总体规划和设计，能够对问题进行分解。对于分解后的技术问题和细节则可以转交到细分岗位的专业人员去做。要做到这点我们仍然需要有大量的技术积累，因为这是你和专业技术人员沟通的桥梁和通用词汇。
对于专业技术人员，技术的深度往往更加重要，深度才是最终创造价值。 前面已经谈到过，技术深度的提升越到后面越慢，学习的周期和时间成本越大，这是符合学习曲线等基本原理的。也正是由于这个原因，能够朝这个技术金字塔顶尖上去发展的人越少，自然你个人的核心价值体现越大。个人的精力是有限的，要想做到全栈技术人才的人相当少，即使是全栈技术人才更常见的情况往往是在自己最擅长的专业技术上能够打到95分以上，而围绕核心专业技术的相关技术能够打到80分以上。
理解了这点，我们就更加清楚技术人员应该更加注意技术深度的积累，能够长期专注在一个专业技术方向上，这个目标选择定了，你会发现对于广度知识的选择就不是漫无目的和随意的，任何广度知识的选择都是这些广度知识是为了支撑你在深度上进行突破。当我们技术深入到瓶颈期后，如果自己反思和回溯，都会发现是知识广度上出现了问题，需要暂时停顿下来先补充广度。但是广度的补充不是最终目标，最终还得回到深度钻研上来。
同时问题驱动往往是拓展广度并快速将广度转换为深度的关键方法。 最常见的就是真实现场大项目中出现的各种技术故障或性能类问题，这些问题的分析和解决往往涉及到操作系统，数据库，中间件，代码开发多方面的知识点，在你解决问题的过程中往往可以驱动你对原来欠缺的知识点进行补充。比如当系统经常出现JVM内存溢出模型需要解决的时候，可能会促使你对JVM内存模型进行详细的学习，在学习后快速基于项目实践去解决该问题。
最后一点，是技术方向的选择。对于这点个人最大的感受就是当你真正在某一个技术领域发展到一定阶段的时候，一定不会是像自己还是新人那样狂热的追求新技术和热点。
即专家更多要考虑的是业务和问题驱动技术，用最适用的架构在当前解决最重要的问题并保留一定的扩展性 ，而对于大部分技术思维人员往往考虑的是技术驱动业务，只是对技术感兴趣而不是对业务和问题域感兴趣。
技术发展趋势和迭代的快速，你任何当前选择的技术或框架都可能在2-3年后就过时，但是如果当前的技术能够很好的支撑业务就是最好的技术。如果有不能更好支撑的地方我们就要考虑基于当前遇到的性能或扩展性问题我们究竟应该引入什么新的技术来解决，并做好方案选择和评估。
所以最后一个问题个人认为不是技术方向的问题，对于任何新技术都应该有敏锐的嗅觉去了解，但是并不是每个技术都要真正在项目里面使用。项目不是新技术的试验地，本身也不存在技术驱动的技术方向选择问题，而只存在业务和问题域驱动的技术架构优化 。业务和问题驱动IT和技术，是从单纯技术思维开始转变的一个重点。
当然也有技术人员完全为了个人技术能力提升和职业发展，在企业引入超前的新技术来构建平台或软件系统，对于这点个人一直是持反对意见的，这类人员往往是自己技术练成了跳槽走人，留个企业一堆难以收拾和运维的系统。
任何技术方向选择，技术的职业发展都不能脱离基础的职业道德，这个仍然是底线。对于技术人员来讲，要寻求技术发展和技术能力提升，往往首先要转变的就是思维和意识，这篇文章或许你能够找到一些共鸣点。
热门文章
