20年前和现在-为什么程序员越来越累
内卷
万物都可内卷。20年前很缺IT人员，只有会写ASP，JSP，就能入行，如果你掌握EJB，那就是非常不得了了。工作到25岁就能当项目经理，28岁就能成为副总也是常态。就没有看到过30岁的程序员。以我刚开始上班的那个公司说，25岁是副总，另外一个年级也大点，29岁的副总。 现在则不一样，每年的毕业生数以百万计，25岁大家刚研究生毕业，工作3年天赋+运气加持，也最多是个小组领导。现在40岁的程序员也常见，我的前辈47了还在写代码，而我今天43了，也仍然还在写代码，我虽有心带领后浪，但实际上也知道会被后浪拍死在沙滩上。
20年前，清华北大去的是中科院，研究院，或者某事业单位。现在，在各个软件公司，都有清华北大的影子，2011年在网易的时候，就发现身边都是清华北大学生，当时感觉很奇怪，现在倒是也能想得通，毕竟科研单位只有家里不差钱，才能安心搞研究。
20年前，能精通一本技术手册就已经是属于资深人员，比如Oracle官方文档或者是JavaEE规范，或者Weblogic官方文档
现在，程序员要看很多手册，涉及开发，运维，数据库，安全。 这些手册随着产品变化迭代也很快，学不过来。
20年前，能运用一个开源就很牛逼，现在不仅仅要知道开源，还要能自己手写开源，或者贡献知名开源，才能在面试中获得巨大优势
现在互联网招的人多，薪水高，但总的人数有限，顶级大学的学生抢985饭碗，985抢其他学生饭碗，其他学生抢前辈饭碗。竞争非常激烈。本来解决就业还得靠中小企业，但在计算机行业，大公司利于技术力量，提供了很多同类产品，让小公司无法生存。比如小公司提供一个办公平台，但巨无霸互联网公司能提供云办公平台。
技术宽度
20年前： 掌握精通JavaSE就行，如果掌握JavaEE 那就很资深了。 现在，Java,JavaEE，Javascript和vue系列.Spring系列,SringCoud系列，Apache系列，Hadoop系列，MQ系列，Docker和K8s系列，程序员不得不全面学开发技能，维技能，数据库和大数据，相当累.你还可能需要掌握Python，对Go要了解！
20年前，技术都很成熟，安装运行不费劲，各种问题都考虑妥当了。 现在很多技术高速发展，搭建过程烧脑，文档不齐，产品自身有坑，或者文档随时过时。这些新技术为了适应大数据有很多取舍，不注意随时掉坑，比如ClickHouse虽然快，但不能支持高并发，耗费CPU过大，只有使用了才知道这些坑（虽然官网也指出，但并没有给出具体参考数据，远不如20年前商业产品使用轻松），
现在，很多技术都是只需搭建一次就行，比如SpringCoud consul，搭建好开发很轻松，几乎感觉不到Cloud的存在，但搭建起来非常费劲，因此学习这些技术占用大量时间。然而开发却几乎没有额外负担，其实一个团队大部分人都不需要学习Cloud。
20年前，程序员不怎么关心运维的事情，也不怎么关心数据存储的事情。 现在，你是程序员，必需精通docker，k8s，或者你要精通虚拟机调优。这也是运维做的事情。比如redis集群搭建，一主多从搭建，本质上还是运维的事情，现在也成为开发者必修课，因为从变主，数据未同步时候的处理，这块还是开发需要考虑。还有很多大数据技术，在未完全成熟情况下，开发也需要参与设计大数据存储和查询。
自媒体时代，知识越来越普及，触手可及的知识，大部分都是用不上，但得学习。所谓的面试造火箭，工作拧螺丝。
算法20年前还不是所有面试必问，现在已经是无论你是学生，还是工作几年的，还是资深架构师，算法都要问，现在卖的最火的书就是跟算法有关，研究最多的就是算法，非常像大学，为了考过英语4&6级，放弃学习专业课，大部分时间都背单词和句子。现在很多大学生刷算法，对Java基础反而掌握并不是那么好，对面向对象技能也不重视。比如，一个简单问题，站长博客如果建模，车和轮子是啥关系，简单的说是一对多关系，但实际上，这个还忽略了一个隐藏对象”底盘“，应该是车有一个底盘，底盘有4个轮子，面向对象一个最重要技能是找出隐藏对象。如果有这些技能，无论是开发企业应用，还是互联网系统，项目组的人都会轻松很多。精通算法并不能让项目开发轻松(除非你的职位就是算法工程师）
技术深度，越来越要求程序员掌握的更深的技术
20年前，HashMap和HashTable区别，集合框架都有哪些常用类 现在，HashMap如何实现的，描述JDK8前后的实现方式区别，优缺点。
20年前，会学习JVM为什么有client和server俩种模式 现在 ，需要了解java字节码是什么，一段Java代码的字节码是什么，虚拟机可能会这段代码对其做什么优化，以及会在哪些阶段做哪些优化？
20年前，会被问到冒泡排序怎么做。 现在，会被问到3亿条数据，如果在有限内存里完成排序
20年前，请问如何编写一个Socket程序接受客户端的发送的字符串 现在，请手写一个RPC服务器。并描述RPC服务器的关键难点。
20年前，Servlet生命周期，只要看一个图就能了解Servlet生命周期，了解后对编程帮助不大 现在，了解Spring Boot 启动后，干了些什么事情，需要看一本300页的书才能了解，了解后对编程帮助同样不大
经过20年的变化，没变的是工作主要内容还是增删改查，大部分难点已经靠框架解决了。 20年的变化，唯一难度降低是的的是面向对象分析，无论是我在工作，还是面试的时候，问到面向对象的问题，都不会得到满意回答（PS:我觉得缺少面向对象分析能力，就好比只学好了数理化，但没有学好语文的那种状态）
敏捷
20年前，用俩周对车进行建模，得出:一个车关联一个底盘，底盘关联4个轮子，车本身还有个可选备胎，因此系统有3个对象，剩下还有一个月完成车系统的详细设计
现在，用1小时对车进行建模，一个车包含四个轮子，系统有俩个对象，设计完毕后，剩下俩周内交付车系统。至于以后发现没有底盘不行，那是下个迭代的事情。
20年前，对商品定价进行分析，会发现有一个定价域，涉及10几张表，设计俩周，评审俩周。 现在，商品多一个定价字段即可，不会给你俩周时间进行定价设计
敏捷先驱们是干外包出身，提出了（所谓的宣言）一个对自己最有利的方法论，这个方法论取悦了项目的各个参与方。但是，这个方法论由于外包原因，局限于战术方法，不经过思考论证，先做了再说。后果是，反复修改，谁做的快，谁能得到重用，然后做砸了留下了很多坑， 别人还填不了这个坑，还得用此人，只能再给这人配备更多的人员。
我个人不太喜欢scrum，尤其不喜欢研发过程中使用scrum，俩周都要出成果，真的我沮丧。我经常几天都做不出（或者想不透）一个功能。有时候一个功能做出来了，由于不利于单元测试，还需要修改。这也让我无可汇报，进度落后别人，感觉不爽。
敏捷里反复修改的有个前提是单元测试，国内并不存在”单元测试“。 而且单元测试并不像敏捷宣称那样简单，否则，同期就会同步出来一堆应该具备的配套工具，比如mock，TestContainers，dbunit等等，但事实这些工具都是后来逐步开发出来。来填JUnit的坑。我在JD的时候，拦住过研发部门试图给交易部门提供的一个国外大学研发的工具-可以通过业务代码自动生成单元测试以确保覆盖100%。但那玩意不成熟，实际操作坑多。
我自己的开源Beetl和BeetlSQL都有一些单元测试，但一涉及到业务系统，我对单元测试就无能为力了，因为太快变化的业务和难以编写单元测试以及难以完成的覆盖率要求。
过度的架构
过度设计和架构20年前也存在，但是当时没有好的工具和基础设施，以及当时业务系统多是单库。放飞的想法飞不到那里去，出错了易矫正。 现在的过度设计和架构，则很难调整。犹如南辕北辙成语提到一样，越是有好工具，错的越离谱。
以前过度设计主要是业务模型过度抽象和软件过度分模块。比如，以前所有业务对象都有父对象，父对象有个唯一属性是id。再比如，每个对象都有一个extAttribute，试图把未来未考虑到独享属性放到这里，这种无聊的过度设计无伤大雅。
现在过度设计在于过度考虑到大数据，微服务，中台架构，这些架构几乎不可能再调整，
如果系统刚开始，并没有足够多数据，业务也没有成熟，可以考虑单体和单数据库，如果一上来就开始用微服务架构，尤其是微服务推荐的一服务一个库，那会让系统非常复杂，比如分库分表，事务处理等。团队没有足够人手和开发周期，会让程序员非常累。
单体系统到系统拆分，影响不大，如果渐进到微服务或者service-mesh，影响也不大，但如果一服务一数据库，影响就很大。凡是涉及到有状态，或者数据持久化，技术难度就上了一个数量级，架构师和程序员都累
对于中台架构来说，中台是解决之前太多零散，同功能的小系统，用中台形成复用。 中台的前提有俩个，很多零散的同功能系统，以及总结出共性的东西。 如果没有这俩个，就不要搞中台，中台火热几年后，现在不是也开始去中台化，中台化制约了创新。比如电商公司开展买电影票的业务，那还需在库存中台，商品中台增加若干属性，这些中台又不能轻易增加属性，又是一番扯皮后，商品中台会妥协的在已有的200多个属性里再增加几个电影票属性。
总结一下，搞开发20年了，以前的加班真的是在加班，现在反而没有加班了,真开心