写给焦虑，迷茫的前端人的思考
前言
现在好多人说程序员的红利时代已经过去
- 裁员的企业比比皆是
- 简历投出去基本没人理，2,3个月能找到工作就不错了，而且还是降薪
- 有重点学校毕业的也只能找到外包的工作
- 千万别学计算机相关专业，无异于50年加入国军
- 车贷，房贷都要还，降薪我也接受
等等上面现象都是我或听说或看到的，或亲身经历的。
现在行业不景气，也不知道是否有恢复生机的一天，或者也许一直会走下坡路，也触动着你我的神经。
真实经历
去年年底的时候我为我们公司面试员工，通过率变得很低，所以面试难度要相对加大，有一次面试一个女生，她技术我觉得一般，感觉没怎么准备，八股文也没有背熟，所以我给了她一些建议，然后我问了一下她从上一个公司的离职原因，她说是被裁掉了，然后说现在找工作很困难，已经找了很长时间了，上家公司工资16，现在要12,13好多公司都还在压价，她说主要现在有车贷，房贷，还有小孩，所以迫不得已得赶紧找到下一家，所以薪资她一降再降，只希望能快点找到工作，等等，说了很多。
非常同情她的遭遇，但是遇到现在行业不景气，而且技术也一般，所以这就很难受，感觉她的焦虑要比平常人大很多，因为还有车贷，房贷，小孩的原因在里面。说到这里屏幕前的你是否有些焦虑呢？
焦虑由来
如果我们踏入程序员这一行业，那么就意味着终生学习。如果平时喜欢躺平，喜欢摸鱼，那么随着年龄的增大，或者行业不景气，焦虑就会不断找上你。用大多数的人来说，'这个行业就是吃青春饭的'，可能在行情好的时候，有些人感觉不出来，觉得自己没有问题的，能干到40岁，但是行情下滑，失业率加大的时候，可能这个问题又会被放大。但是焦虑一定就是坏事么？
什么是焦虑？
引用百度百科里的解释：
焦虑是人对现实或未来事物的价值特性出现严重恶化趋势所产生的情感反映 。与之相反的情感形式是企盼，即企盼是人对现实或未来事物的价值特性出现明显利好趋势所产生的情感反映。
焦虑是指个人对即将来临的、可能会造成的危险或威胁所产生的紧张、不安、忧虑、烦恼等不愉快的复杂情绪状态。
所以我的意思还是希望大家能够主动拥抱变化，主动改变自己，行动起来，那么问题又来了，我们努力的方向在哪里？努力是有方法的，努力要选择好努力的方向，否则辛苦付出了，收获并不会很大。所以说到这里你是否又开始迷茫了？
你是否有这种迷茫？
在技术的学习中大家应该有过下面这种现象，有的同学感觉付出了很多努力，但是收获很少。尤其进阶阶段，研究源码阶段，精通阶段等等，付出了大量时间，但是收效甚微，有时候我们就会产生这样的想法，我选择的这条道路对么？为什么感觉自己还是很菜？我花这么多时间研究源码干什么？
于是这个时候你开始变得焦虑，迷茫？想想工作1，2年的程序员2周就能学会vue并上手了，而你花了相同的时间看了《javascript高级程序设计》这本书还不到20页, oh my god, 这样下去会不会下一个被裁的就是我
这个时候在我脑子里浮现了一个问题'你说工作7,8年的程序员相对于工作两三年的程序员优势在哪里呢？'
如何选择好以后的道路
针对程序员该如何选择自己的道路，我采访过一些工作比较久的程序员。
我的问题是这样的
'你说工作7,8年的程序员相对于工作2,3年的程序员优势在哪里呢？'
下面是一些回答
有的人觉得优势是经验，包括成本预估、架构策略、性能评估、风险评估等, 但是除了这些也不得不承认其他基本都是劣势
有的人觉得工作5年的程序员应该达到技术的至高点，根据统计学规律，程序员以后主要往两条路发展，一种是系统架构师，一种是业务负责人，要早做规划
还有的人说找准目标，缺啥补啥，当然目前是根据环境动态调整的，先把自己能把控好的事做好，大环境不好就降低目标，也能把更多精力放到其他上面
还有的人给出了更加详细的解答
1、更多关注全局架构的精力超过专注细节的精力
工作早期，接到的任务大多是单点的功能模块和系统，更多关注编码、技术实现问题。
工作7、8年会，会逐渐承担整块的业务，进而会从业务的整体角度来思考系统的架构，目标从“实现某个功能”转变到“支撑某个业务”，把业务当作整体来看，视角逐渐从“语言、框架、数据库”转换到“通信、架构、安全合规、网络、数据”。
2、意识到对技术的表达能力很重要
这不是指为人处事的沟通表达能力，而是对技术的表达能力；
例如更加关注流程图、架构图，不再排斥ppt、文档，会更多思考怎么更加准确、简洁的描述出你的系统架构、业务流程，能够让合作方、上下游更加准确的理解你的思路和设计，更加高效的合作，避免出现理解偏差。
例如编码，早起很喜欢炫技，喜欢各种高大上的编码风格，例如各种函数式语法，工作久了就不再喜欢追求这些，更加看重你的代码是否能够很容易理解，是否足够健壮，能够被测试到，特殊逻辑能否充分注释；
3、不再纠结于单点的性能提升
新人很容易陷入性能崇拜，过分关注有限的性能优化，为了有限的性能提升，直接在db层面写复杂的sql直接处理，导致代码可读性变差。
后来会更加关注有限在符合基础性能的前提下，优先满足业务的诉求，再根据业务的特性、预判一段时间内的发展，适当的在性能和可读性、可复用性上做一定的取舍。
4、更加追求简单的架构、代码
好的代码、架构一定是简洁的，如果一段代码、设计很多人不容易理解，那么这样的设计迟早会出问题。
给你的上下游以简洁、清晰的接口、文档和功能，避免给到用户各种条件选择，避免过度原子化拆分，在可拓展性、易用性方面需要做取舍，
在这里非常感谢以上各位的回答，相信上面的回答能帮助大家或多或少的解决努力方向的问题
just do it
首先说明一点，没有人不迷茫的，大家都第一次做人，怎么会知道接下来每一步该怎么走呢？
有一个人十分崇拜杨绛。高中快毕业的时候，他给杨绛写了一封长信，表达了自己对他的仰慕之情以及自己的一些人生困惑。
杨绛回信了，淡黄色的竖排红格信纸，毛笔字。除了寒暄和一些鼓励晚辈的句子外，杨绛的信里其实只写了一句话，诚恳而不客气：
“你的问题主要在于读书不多而想得太多”。
