每年，在这个时候，充满了悲欢离合，也总能看到各种活蹦乱跳的小鲜肉。我们毕业了，我们开始赚钱了，我们踏上了一条不归路……。结束一段旅程，开始填新的坑，或者挖一个坑。我总习惯性的会做一些“反省”、总结的文章，它可以帮助我重新回到 “正轨” 上，指出到下一阶段我所需要的内容。
之前写《演进：在工作的前三年里快速成长（练习篇）》是因为三年是一个重要的门槛，而五年将是另外一个重要的门槛。一个最简单的区分方式，就是看看各个招聘网站的相关要求：1-3年、3-5年、5-10年。当然就国内的情况下而言，很少有10年+的开发岗位。
1~3 年，我们已经成了一个入门级的搬砖工人，变成了一个熟悉的搬砖工人。我们开始承担一些重要的开发角色，如主力开发，但是多数时候还是个人开发者。
3~5 年，我们开始寻求技术之外的突破，并且精力有限不再单打独斗。前三年的经验，让我们有能力区分自己未来适合什么路线：技术、技术管理还是纯管理。但是不论怎样，我们在提升自己技术的同时，还需要指导、带领组织内他人的成长。
5~10 年，我们开始站在更高的层面考虑问题。我们的系统在整个大系统的架构，整个系统架构的未来，行业发展的趋势、架构的演进，blabla。我们开始去证明、追求自我的价值。
10年+，未来太远，我编不下去~。
（PS：对于中小公司来说，可能就不是这样了）
这一切的大前提是，我们不是五年里，重复了一年的经验。
就这么的，五年变成了一个重要的分界线，不管我们怎么看，他就是在那里，不多也不少。踏入下一个门槛之前，我想的分享一下之前四年的一些体会。它还可以在未来，帮我看看，我的路线是不是清晰、正确的。
工作上状态的主要变化是：项目上学的东西越来越少，需要越来越多的贡献。即变成了输出 >> 输入的状态，从短期来看，这是一件好事——我需要不断的去补充新的知识。大抵也是技术的另外一个瓶颈区，好在有 DSL 和 DDD 相关的知识可以探索。
可当我在培养别人的时候，我总会在想着长远一点的，这些人如果一直和工作倒是不错的。
毕业进入一家公司，我们看重的是能从得到什么。比如获得一个 BAT 程序中的头衔，赚取更高的收入，赢得从大牛学习的机会。总之，我们渴望快速的打怪升级。
故事最开始的时候，我们在新手村附近打怪，升级很快。一段时间后，打这些怪，会让我们觉得无聊，便去寻找更大的挑战，获得更多的经验。又一段时间后，我们又需要成长了……。
如果能那么顺利的成长，那便也是极好的。可惜并不可能，一家公司的资源和人力都是有限的。公司内部的矛盾也多数源于此：争夺有限的资源。同样的，对于个人成长也是如此，我们需要成长的资源。而不同公司的制度是不同的：
要么，我们获得多大的资源，我们就可以证明我们有多大的能耐。
要么，我们证明我们有多大的能耐，我们就能获得多少的资源。
多数情况下，获得的基础是多付出，多付出才是多获得的前提。可不是多付出就一定能多获得收入，而是在有用的地方付出。
这么几年下来，对于此的看法发生了一些变化，从应该得到了什么，到我创造了什么价值，我才能得到什么。
这一点可以在不同公司的级别看出一些端倪，如我司的：
Junior Consultant，能把活干好
Senior Consultant，能带别人干活
Lead Consultant，到能找活干
xxx Consultant，我们得有这个坑
那么，按照这样的组织架构，下下一个阶段，应该就是尝试去创造项目机会。这些意味着：引入技术趋势、提升客户影响力、提升组织的能力……。
未来大抵也是如此吧。
工作多年之后，当我们开始去寻找自我价值的时候，我们就想去取得一点成就；当我们想要有所成就的时候，我们得去做更多的事；做更有价值的事，我们就能获得更多的收入和经验。
毕业的时候，我觉得编程就是一项可以赖以生存的能力。可当实际上，它只是一门手艺。每当我们在讨论编程能力的时候，我们讨论的能力基本上是和编程无关的。
我们讨论程序设计的时候，讨论的是：抽象思维、归纳能力、设计能力……。
我们讨论解决 bug 的时候，讨论的是：如何找寻问题、分析问题，然后解决问题、归纳问题。
……
编程只是我们完成上述步骤的技能而已。
综上所述，编程是一个专业知识技能，具有很强的不可迁移性。而在我们日常的工作中，我们还需要一些额外的技能：做 PPT、做技术分享、沟通、时间/精力管理等等。用一个专业的归纳，对能力进行分类就是：
专业知识技能。
可迁移技能。可在不同行业中使用的技能。
自我管理技能。即自我认知和自我约束、调整等能力。
就当前而言，专业知识技能是我们的主要发展目标，也是我们的谈资。但是随着时间的推移，我们需要不断的提升其它能力。
对于当前的我而言，主要的是可迁移技能。作为一个短板，它的短期提升空间更大。
刚毕业的时候，对于每天写业务代码可谓是厌恶。写起来即繁琐，又不会有成就感。在这个时候，最有技术感觉的便是，在启动一个新项目的时候，从零一步步搭建工程。毕竟在多数的公司里，项目上遇到技术挑战，那是是可遇不可求的。
可时间一长，搭建工程这种事情，做起来也觉得无聊了。反而，相对于从头起一个项目，重构、演进一个项目更具有挑战性一些。
而工作时间一久，发现其实最难的部分不是技术，而是将技术抽象到业务中，解决繁琐的业务问题。如果不能跳过问题，那就去解决这个问题。
在最近的几个项目里，我尝试了一些 DSL，也从中看到了一些改进的空间。以这种方式来解决问题，往往要比一个纯技术的问题要复杂。多数时候吧，我们遇到的技术问题，都是别人遇到过的。我们所做的便是从他们的场景里，转移到我们的场景中。
这大概或许就是我下一个阶段的目标。
工作，不是我技术的主要知识来源，而是应用场景。技术提升，多数时候还是依靠于平时的研究。而研究也需要一些明确的 roadmap，套用 @justjavac 的一句话就是：
“精通 one，学习 another，关注 next ”
刚毕业的时候，我陷入了一个误区，那就是什么热闹就学习什么。但是，人的精力是有限的，特别是上了 “年纪” 之后，要处理的事情多了。反而，要集中起精力，倒没有那么容易。但是，一旦集中起精力，但会保持一段时间。
在进行技术选型的时候，我们很容易陷入 HDD（热闹驱动编程）的影响。贸然地决定使用一个新的框架，于是：
在工作上，我已经偏向于使用已有的框架，不再从零尝试新的可能性。
在业余时，我则偏向于不使用已有的框架，从零尝试更多的新可能性。
这种变化的主要来源是，在工作中使用新的框架，会占用额外的业余时间。这一点相当的有趣，特别是当我们熟悉了使用 Angular、React、React Native 之后，我们又要去尝试新的相似的框架，这种学习无异于浪费时间。
我们已经在某一个技术栈花费了一定的时间，积累了大量经验。而在前端这个领域，就当前而言，使用 Angular、React 或者 Vue 来说，总体的区别并不大。但是，我们去得学习一个新的语法，模板，语言，适应一些新的设计特性——在其它框架看来，可能是缺陷。而应该拿这些时间去研究更底层的技术，或者去创建一些自己的框架。
由此带来的变化是，我将这些时间投资到一些新的技术领域里去。如今年我设定的两个领域是Serverless和前端微服务化，这两个领域更多的是技术思想，而不是框架。
当我在思考前后端的未来时，发现了Serverless是一种与微服务极其类似的架构，但是它从某种程度解决了微服务的 DevOps 复杂度的问题。而前端微服务，则要去解决前端应用臃肿的问题。
技术投资，是存活下去的最基本要求。典型的如 Google、Facebook 这样的技术公司，会不断投入资源在研发上，他们会去创建趋势。
作为一个非学院派，我一直是以实践为主导来学习，而不是学习理论来开头。
与看代码相比，直接写相似的轮子，是我最有效的学习方式。在造轮子的过程中，边深入不同的领域，也深入了不同相似框架的代码阅读中。
刚毕业时，造了前端框架 Lettuce 以学习前端 MVC 框架。最近则是：
学习微前端时的微前端框架 Mooa
学习 WebComponents 框架时，造了 Oan
总之，造轮子依旧是我深入学习的方式。
虽然，我不是学院派，但是我习惯性的会写博客来总结学到的知识。
在我工作之前，我已经有一个维护多年的 blog，上面记录着大量的经验，学习相关的笔记。从 2012 至今天，2018.07.08，6 年的时间里已经有 691 篇文章，大部分是与技术相关。
到了今天，最大的变化是，我会以合集的形式来不断深入相关的主题。文章和笔记有一个问题就是不够系统，而电子书和纸质书籍则不一样，他们更加的系统。这一点可以看我在 GitHub 上的一系列电子书，它们大抵就是最好的证明。
从年初整理去年 Serverles 相关的文章，并按照书籍的形式补充了前言等部分的《Serverless 应用开发指南》。到最近的微前端相关的文章，都被放进 https://github.com/phodal/microfrontends 项目里，并取名为《微前端的那些事儿》。然后，我在不断的补充相关的文章，以便其它同行可以了解相关的内容。
在不断加深、沉淀我知识的同时，也可以帮助更多的人了解相关的知识。
最近的几个月里，我沉浸在游戏世界里：塞尔达、超级马里奥……。大抵是，可以视为向下一个 “迭代” 冲刺之前做的休息。
游戏是一种输入即有回报，并且有明确的 Roadmap，即使是自由世界游戏。如 MineCraft 也是有一条明确的主线，我们就需要去挖坑，我们需要箱子来存储东西，我们就需要去盖房子……。
现实也如此，划定出一条 roadmap，然后一步步往下走。
只是生活没有那么简单，每个人的环境是不同的，价值观不同，决定了其所需要的 roadmap 也是不同的。
