IT行业真的在走下坡路吗？现在的环境下一个好的Java程序员需要掌握哪些核心技术

一：时代背景

身处互联网行业的我们一直处在变革的最前端，受到行业发展浪潮的洗礼，不停歇地追赶着技术革新的脚步。特别是近几年来， 互联网架构不断演化，经历了从集中式架构到分布式架构，再到云原生架构的过程 。在这个演变过程中，我们可以深刻感受到一系列的格局变化 —— 软件改变世界，开源改变软件，云吞噬开源。每一次架构模式的升级都会给这个世界的合作模式带来变化。

“云原生”因能解决传统应用升级缓慢、架构臃肿、无法快速迭代等问题而逐渐成为这个时代舞台的主角。身处变革的浪潮中，我们看到云原生的出现改变了互联网架构的航行方向，并给越来越多的企业带来了全新的理念和无限的可能。

在架构的演变过程中，技术体系也在不断革新，过去的技术比较单一，现在我们谈分布式、谈服务化、谈容器调度、谈 Service Mesh、探讨云数据库等。不仅如此，各种前沿的技术都提供了对应的优秀开源解决方案。

那么在当下互联网架构的技术体系中，如何学习和读懂各种新技术，并将它融入自己的技术体系，以更新自己的技能树呢？

二、你知不知道哪些该学，哪些不该学？

Java作为一门语言至今已有20余年历史**，**无论是语言本身，还是相伴的工具和框架都发生了巨大变化。

• JavaEE框架，从百家混战到现在Spring基本一统天下。

• Web开发，从标配的SSH到现在SpirngMVC + MyBatis组合。

• IDE，从当年如火如荼的JBuilder到Eclipse，再到更好用的IDEA

在不断的技术迭代下，如果摸索出一条高效的学习路径，可以大大的减少自己的时间成本与试错成本。过去半年，我不断的盘整自己的思路，想分享我对高效学习Java的看法。但不足之处是都没有非常系统的梳理。因此，今天刚好趁此机会，我把它们整理起来，希望对大家的学习有所帮助。

spring

在Java EE开发中，Spring已经成为和Java核心库一样的基础设施，所以说如果想成为一个优秀的Java程序员，Spring肯定绕不开。另一方面，如果掌握了Spring体系，Java基本上就算入门了，就有能力进行一些实用级的开发了。

但Spring本身也是日渐复杂，衍生项目越来越多，但最最核心的概念依旧是IOC和AOP，掌握了这两个概念，再把Spring MVC学会，再学习其他的衍生项目就会平滑很多。

同时，因为Spring本身就应用了许多优雅的设计理念，所以学习Spring的过程，也是加强Java基础知识学习的过程。因此等你掌握了Spring，原来很多你理解不透彻的Java特性，此时就会恍然大悟，包括接口、抽象类等。

以我的经验，要初步掌握Spring，大概需要1到1个半月的时间。

为了让更多小伙伴们能够快速的掌握spring，我这边也整理了一份关于spring知识点提供给大家复习：

Spring是Java编程的基础设施，但真要进入到实际项目的开发，还有些东西绕不过，包括 MySql，Mybatis，Redis，Servlet等，但如果你经过Spring的洗礼，这些东西相对就简单多了，以我的经验，1个月的时间足够了。

设计模式

设计模式，我认为是初中级程序员，向高级程序员提升的关键点。

在实践中，我见过太多程序员，前期冲劲十足，但后继乏力，最终泯然于众生。我不敢说所有的人如此，但有不少都是吃了设计模式的亏。

在面试设计模式时面试官最爱问的十道题目！

架构

写出一个好程序，有几个维度，从下到上，也是一个程序员逐步升级的过程。

第一阶段，首先要保证基本功扎实，最简单的说，要做到语法熟练、基本框架熟练，成为一个功夫精熟的“码农”。

第二阶段，从“技”到“术”，从“码农”到“工程师”。这个阶段的关键技术是设计模式。在局部上，不仅追求实现功能，更关注实现的好，关注功能之外的维度，例如健壮性、低耦合、可扩展等指标。对主流框架（例如Spring），不仅会用，更有深刻的理解。

第三阶段，从“术”到“道”。

这个阶段，不仅在局部上追求一个模块的好坏，而且还要从整个系统层面去掌控程序，例如保证整个程序不出现系统腐败，如何安排资源的优先级等。这个时候就不是单一的维度，单一的技术能够保证了。

经常有朋友问我是如何成为一名架构师的，很难用一句话来回答。

我可以路线鲜明教你如何成为一名优秀的软件工程师，但至于如何成为一名架构师，我想除了努力，运气肯定也很重要。但无论如何，有机遇，不是还得有准备嘛？

关于冲击架构师的知识点，我这边也有一份PDF文档：

从基础到进阶都有，知识点已经全部整理好了，大家下载好了取阅就行

如果您觉得这篇文章不错，那么请三连支持一下吧

数据结构

毫无疑问，数据结构对一名程序员来说非常重要，不是有句话说“程序 = 数据结构 + 算法”。从某个角度看，这种说法即使现在依然成立。这也说明数据结构的重要性。

但大部分的数据结构课程，关注的重点都在如何从数学上实现一个数据结构（例如堆栈、链表）。这从研究上来说，没有错。

但在实际开发中，大部分主流语言（例如Java、C#）都已经内置了常用数据结构。而且即使没有内置的，我们也常可以在第三方库中找到现成的实现。而且这些实现，大都经过实践检验，无论是稳定性还是性能都有保证。

也就是说，对大部分程序员来说，在实际开发中，很难有需求从头实现一个数据结构。因此，就完全没必要像科班生那样，从数学源头来学习数据结构，而只需做到下面几点：

1. 熟悉常用数据结构的概念（例如数组、堆栈、链表、Map等）

2. 了解常用数据结构不同实现的差异（例如ArrayList和LinkList的差异）

3. 关注常用数据结构的外围算法（例如如何对List和Map进行查找）

4. 关注数据结构使用中容易出错的地方（例如是否线程是否安全等）

算法

这个要具体问题具体分析了。以我接触的领域来说，大部分普通的业务系统都不会涉及到太复杂的算法，因此就没必要专门在算法上投入时间。

但在一些特殊的领域，如果算法跟不上，可能“寸步难行”，例如图形处理领域，无论是图像的变化还是增强，无一例外都要用到矩阵变换，因此就必然涉及到线性代数的内容，顺藤摸瓜，往纵深学，就必然会牵出更多的东西。

因此，对非科班生（尤其是数学不够好的），对算法学习我是持“劝退”态度的。因为，从职业发展来说，这实在是一条太“曲折”的路线。

一方面，目前的开发越来越趋专业化，算法一般由专门的算法团队负责，普通软件工程师只负责算法转换。

以我为例，虽然是科班出身，也系统的学习过算法，但也常有力有不逮的时候。复杂的算法既实现不了，甚至是理解不了。很多时候，我干脆就不做实现，直接请算法工程师告诉我思路，甚至是伪代码，而我负责转化为正式代码（例如Java）。实践证明，这种做法不仅是可行的，而且也是高效的，正所谓“术业有专攻”。

另一方面，人的精力是有限的，你完全可以把精力投入到自己更擅长的方面，例如设计、产品、架构上，从而取得“差异化”的成功。

关于数据结构与算法，本人认为这也是一个程序员最应该掌握的！

三、最后

最近和朋友交流，发现了一种现象。很多工作多年的一线工程师，职级也不低，工作能力也够强，然而在面试中却总是能被各种“奇怪”的问题问倒。挫折的次数多了，有些朋友甚至都开始自我怀疑，怀疑自己到底是不是“水货”？

而要解决这个问题，只有一个办法：不打无准备之战。

关于这一点，我也收集了很多的面试资料可以提供给大家做复习用！