互联网的寒冬是否只是以讹传讹？

很多互联网公司都在裁员，这个是事实，但不只是互联网公司在裁员，很多行业也都在裁员；与其说是互联网行业的寒冬（是不是寒冬，下面再谈我的看法），不如说很多行业的行情都不太景气，比如房地产。

回到互联网公司裁员的问题上，我分析主要有这几个原因：

• 互联网风口越来越少，前几年的网约车、P2P、共享单车、直播，18年基本上没啥新的风口；记得三四年前O2O抄的火热的时候，满大街都是地推团队，“扫码送饮料”、“关注送小礼品”；
• 依靠风口飞起来的这些公司，前期发展太快，现在因为风口已过，所以也开始精简，轻装前行；
• 人口红利消费的差不多了；很多细分行业都已经被占满了；创业不再那么容易；
• 一些公司没有盈利收入，单纯的靠融资，而投资者没有往年那么疯狂，这样导致很多公司会裁员甚至倒闭。

人经常出现两个谬误：

一、以特例反驳普遍，比如，我有个朋友，中了500W彩票，我认为买彩票是一个可以赚钱的行业，但事实是，中彩票的概率趋向于零，多少人跳楼了。

二、以普遍覆盖特例，认为是常识，比如，大多数学历低的人，普遍成就都不高，但是刻板印象的认为学历低的人都很水，这就是以偏概全，很多成功人士，都无关乎出身。

以一个朋友拿到了还不错的offer，认为整个行业没有关系，这就是典型的以偏概全。

---

一、互联网寒冬

判断互联网寒冬，首先是看行业总产值，再看新闻和报道，最后看身边。第一者我刚才查了一下，只能查到17年的，自然是欣欣向荣的。但是新闻和报道，可以看到近期上热搜的互联网公司：

有赞996，不怕离职

网易裁员

美团裁员

第四范式拒绝校招offer

标杆都在裁员能力，剩下的公司想来也差不多：

二、寒冬不可怕，只是优胜劣汰

以前互联网是个蓝海，随便搞一搞，都能赚到钱，现在大行情不景气，随着风投的撤资，导致公司开始精细过日子了，对，没错，只是精细的过日子了，并不是说死在沙滩上了。

就像08年一样，制造业和房地产业的泡沫突然就没了，导致了大量的裁员和失业，但是像万科这样的大头，只是瘦身，不是病了。

那最惨的是哪些人？是那些蹭着红利期，赚着与个人价值不对等收益的人，企业回过来神来，去控制人力成本，这些不对等的人，就变成被裁掉的人。又因为本身价值虚高，又成为市场上找不到工作的那批人。

但如果是有核心竞争力的人，并没有任何的影响，该有的选择同样是有，该要的报酬同样会要。

那么既然互联网行业这么不景气，那为什么有的程序员朋友还能收到多个Offer呢？

我觉得如果非要给出一个合理的解释那么借用网友的一句话：“哪有什么互联网寒冬，只是你穿的少而已”。

工作5年左右的程序员，选择了一家月薪18K的工作。这是在什么城市，三线还是四线，反正不是一二线城市吧？这个待遇似乎是低于市场行情的。所以才会那么抢手，感觉不到跳槽的压力。

每年的年初，金三银四，都是跳槽的高峰期，这个时候也是招聘的高峰期。有竞争力的选手，是可以换一个更好的环境和工作，没有竞争的选手则会谨慎而行，不能盲目跳槽。

那么针对互联网寒冬的传言小编针对Java程序员的成长路线也做了一些系统全面的学习路线规划

设计模式

设计模式是可复用面向对象软件的基础，学习设计模试是每个程序员从菜鸟走向大神的必经之路，巧妙地运用设计模式可以使我们的代码看似复杂实际简洁、复用性更高、更容易被别人理解等好处，同时也是学习软件工程的基础和必然。

并发编程

主要培养编程者深入了解最底层的运作原理，加强编程者逻辑思维，这样才能写出高效、安全、可靠的多线程并发程序。

开发工程化

通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。程序员的战斗，往往不是一个人的战斗，我们如何在一个平台下高效的去重，进行代码review，对功能进行调整，debug，做到在统一的规划下步步为营，混乱的堆代码的过程中找到自己的记录。这一切都依赖于有效的工具。

性能调优

我们不仅仅对项目要运筹帷幄，还要能解决一切性能问题。只有深入学习JVM底层原理，Mysql底层优化以及Tomcat调优，才能达到知其然，知其所以然的效果。除了性能优化之外，也能提供通用的常见思路以及方案选型的考虑点，帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。

源码分析

程序员每天都和代码打交道。经过数年的基础教育和职业培训，大部分程序员都会「写」代码，或者至少会抄代码和改代码。但是，会读代码的并不在多数，会读代码又真正读懂一些大项目的源码的，少之又少。这也造成了很多错误看源码的方式。

那要如何正确的分析源码呢？

我们的目标应该放在最常用的框架上面，下面就介绍两个：一个是Spring，另一个是大家用来觉得一直不怎么出问题的Mybatis。

高性能分布式架构

随着我们的业务量越来越大和越重要，单体的架构模式已经无法对应大规模的应用场景，而且系统中决不能存在单点故障导致整体不可用，所以只有垂直或是水平拆分业务系统，使其形成一个分布式的架构，利用分布式架构来冗余系统消除单点的故障，从而提高整个系统的可用性。同时分布式系统的模块重用度更高，速度更快，扩展性更高是大型的项目必不可少的环节。

微服务架构

关于微服务架构的取舍

在合适的项目，合适的团队，采用微服务架构收益会大于成本。

微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。

需要避免为了“微服务”而“微服务”。

微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

大型电商实战项目

要想立足于互联网公司，且能在互联网浪潮中不被淹没，对于项目的开发实战演练是不必可少的技能，也是对自身能力的一个衡量，有多少的量对等于获得多少的回报。看似简单的一个项目需求图谱，其中的底层原理，实现原理又能知道多少？你搭建一个完整的B2C项目平台到底需要多少知识？这一切都是需要我们考量的。

海量数据搜索引擎专题

大众点评、淘宝、58同城等各行业大型网站在用的实时搜索技术

容器化技术专题

总结的这些架构技术希望对Java开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。同时我经过多年的收藏目前也算收集到了一套完整的学习资料，希望对想成为架构师的朋友有一定的参考和帮助。

作为个体，不要抱怨某个行业的寒冬，因为身不由己，应学会厚积薄发，应掌握安分守己，找准自己的核心竞争力，不断打磨，不断实践，才能临危不惧，活出精彩，最终迎来下一波红利。