程序员技术发展瓶颈该如何突破！

在知乎看到一个问题，相当有代表意义，即技术人员本身的技术发展瓶颈的突破问题。

具体问题如下，通常情况下，技术人员在某一领域工作3-5年后，会成为团队内或者公司里的核心技术骨干，这个时候他们也会面临几个问题：

技术学习的困惑：当达到一个瓶颈时，可以学习的参考系越来越少，首先是因为高端技术人才呈现倒金字塔形态，身边缺少能引领你的人生导师；其次，业内的技术交流，大多数在做科普以及刷存在感，到达一定阶段后对个人提升作用越来越小（甚至用一天时间参加技术大会效果还不如用一天的时间在咖啡馆看书学习）；再次，国内的文化导致技术人专家逐渐转向管理岗位，技术缺少积累，特别容易出现断层和继承。

技术深度与广度的选择的困惑：技术深度的进一步提升，可以逐步做到业界大牛，专业技能越来越强，广度的延伸也更容易变成全栈技术人才，两者各有利弊，个人时间和精力有限，如何抉择？

技术方向的困惑：大型互联网公司的技术框架基本都在最初选型时确立，与当时的业务规划、业界当时的技术趋势、个人的过往经验积累相关，成熟规模大的业务从稳定性考虑，一般技术选型落后新技术2、3年，对于技术人员来说，从实际工作考虑需要使用老技术，但是业界的趋势又是在朝着新技术的方向发展。

这种困惑相信很多技术人员和技术管理人员都存在，包括我自己，当然这种困惑本身也是符合学习曲线规律的，即任何一个技术学习和实践，越是到后面学习的时间越长，本身能力提升越慢。但是往往真能够坚持和专注，能够耐得住寂寞等到量变到质变的那一刻，就是一种一览众山小的新境界。

对于上面提到的三个困惑点，自己简单思考如下：

其一，技术学习的困惑，任何新技术或知识点的学习，在当前互联网和信息如此发达的情况下，只要你有兴趣就一定能够找到相关的学习资料进行自我学习，兴趣往往是第一个驱动点。但是问题的关键点还是在于学习后的新技术如何深入，新技术如何去实践？没有真正的实践总结，没有真实的大型项目实战驱动，你将发现理论终归是理论，理论要转化为你的实战经验是相当困难的。

如果一个新技术的学习没有实战机会，那么你自己也很难真正保持长久的兴趣，能够做到熟悉或知道已经不错了，而要真正做到精通或理解就很难。大量技术的深入学习往往都是在实践中真正遇到了复杂的问题，在问题驱动下的学习和深入，这些错综复杂的问题往往涉及庞大的知识面，而且各个知识点之间相互影响。我们如果有实践机会能够不断的解决这类问题，不断优化和持续改进，技术自然深入。

举一个简单的例子来说，对于海量数据处理下的高并发互联网架构，这类架构知识有不少书籍都在系统的讲，往往也有很多技术专家的实践分享。我们学习这些理论往往看起来简单，也容易理解，但是即使你学习了这些知识，如果没有相应的大型互联网系统架构设计场景给你实践，那理论终究是理论，这些理论本身你也很难真正的深入学习。正是由于这个原因，技术学习的困惑不是简单的兴趣问题，而是是否有大型项目实践机会和锻炼的问题，但是往往大部分的公司都无法真正提供这种大型项目的机会，你要完全通过自己学习和模拟试验来深入掌握这些技术就变成了空话。

其二，技术学习的深度和广度问题，对于这个问题简单回答就是对于技术管理型人员重点是更广的知识面和综合能力提升，即广度更加重要而不是落入某一个深度细节。对于专业技术型人员，则是技术深度更加重要，因为技术的深度往往才真正为你创造更大的价值。

技术管理型人员需要更加关注整个知识体系的构建，其中包括重要的软技能。这类人员的重点是总体规划和设计，能够对问题进行分解。对于分解后的技术问题和细节则可以转交到细分岗位的专业人员去做。要做到这点我们仍然需要有大量的技术积累，因为这是你和专业技术人员沟通的桥梁和通用词汇。

对于专业技术人员，技术的深度往往更加重要，深度才是最终创造价值。前面已经谈到过，技术深度的提升越到后面越慢，学习的周期和时间成本越大。也正是由于这个原因，能够超这个技术金字塔顶尖上去发展的人越少，自然你个人的核心价值体现越大。个人的精力是有限的，要想做到全栈技术人才的人相当少，即使是全栈技术人才更常见的情况往往是在自己最擅长的专业技术上能够打到95分以上，而围绕核心专业技术的相关技术能够打到80分以上。

理解了这点，我们就更加清楚技术人员应该更加注意技术深度的积累，能够长期专注在一个专业技术方向上，这个目标选择定了，你会发现对于广度知识的选择就不是漫无目的和随意的，任何广度知识的选择都是这些广度知识是为了支撑你在深度上进行突破。当我们技术深入到瓶颈期后，如果自己反思和回溯，都会发现是知识广度上出现了问题，需要暂时停顿下来先补充广度。但是广度的补充不是最终目标，最终还得回到深度钻研上来。

最后一点，技术方向的选择。对于这点个人最大的一个感受就是当你真正在某一个技术领域发展到一定阶段的时候，一定不会是像自己还是新人那样狂热的追求新技术和热点。即专家更多要考虑的是业务和问题驱动技术，用最适用的架构在当前解决最重要的问题并保留一定的扩展性，而对于大部分技术思维人员往往考虑的是技术驱动业务，只是对技术感兴趣而不是对业务和问题域感兴趣。

技术发展趋势和迭代的快速，你任何当前选择的技术或框架都可能在2-3年后就过时，但是如果当前的技术能够很好的支撑业务就是最好的技术。如果有不能更好支撑的地方我们就要考虑基于当前遇到的性能或扩展性问题我们究竟应该引入什么新的技术来解决，并做好方案选择和评估。

所以最后一个问题个人认为不是技术方向的问题，对于任何新技术都应该有敏锐的嗅觉去了解，但是并不是每个技术都要真正在项目里面使用。项目不是新技术的试验地，本身也不存在技术驱动的技术方向选择问题。而只存在业务和问题域驱动的技术架构优化。业务和问题驱动IT和技术，是从单纯技术思维开始转变的一个重点。

最后 ，分享一套针对Java程序员学习进阶的最新互联网架构思维导图，希望对你有帮助！

这套架构思维导图是几位架构师花费几个月时间整理出来的，为此录制了一些架构视频资料免费提供！

欢迎工作一到五年的Java工程师朋友们加入Java架构开发：760940986

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

（1）常用源码框架

（2）互联网分布式架构

（3）团队协作开发

（4）架构基础

（5）微服务专题

（6）性能调优专题

（7）并发编程