受老司机编辑世杰的邀请，分享一些我对于工程师持续学习的建议。
一. 成长经历
我是莲叔。2010 年本科毕业进入中科院读研，12 年开始创业，16 年结束创业进入 uc。整体技术栈是后台为主-》客户端为主。
二. 近年学习经历
本质上，学习的目的就是要实现能力的扩展。我从 12 年开始主要就是在做 ios 开发，其中能力拓展主要来自于两个方面：
1. 工作中遇到的挑战:
12 年学习了 python 的后台开发
17 年学习了 Weex/JS以及一些大前端的技术
18 年学习了视频播放编辑的相关技术
2. 自己主动寻求的能力拓展
15 年初学习了Swift
15 年底学习了Haskell 和函数式编程。
18 年学习了机器学习和深度学习
从效果上来说，为了应对工作中的挑战毫无疑问是更扎实的，但如果找到合适的方法，自己主动寻求的学习也能获得不错的效果。
三. 如何学习
工作中的学习
如果学习的目的是为了应对工作中的挑战，首先要恭喜你，大概率你这次学习会是有效果、有一定成果的，因为有明确的目标。那如何最大程度发挥这类学习的收益呢？ 这里提一个关键词：
体系。
应对挑战的学习最忌讳的就是浅尝辄止，如果简单以完成任务去学习，那往往最后的效果是很一般的。要以不仅要完成任务，还要完成的很好，整个过程能够给别人一种，你“终结”了这个问题。什么叫终结呢？ 就是你在解决一个问题的过程已经做得十分体系，换一个人肯定不会做得更好。
举个栗子，你们的产品视频打开比较慢，你负责来优化打开的速度。那大概可能会有以下的几个阶段：
1 原先用 avplayer，换成 ijk 试试
2 实现预加载一部分数据，省去数据下载的耗时
做完了这两步，往往体验就能有了不少的提升，但如果在这就停了，那其实反观这个过程，我们什么都没学到。那继续深入尝试一下：
首先可以，分析预加载的命中率，尝试提升命中率
3 比如尝试预测用户的点击位置。来优先预加载用户最可能点击的 item
这里，你可能可以学习到一些基本的机器学习知识。
4 比如尝试精细化预加载数据的大小，那就需要计算一个视频需要下多少数据可以开播？对于 mp4 文件来说，这个大小就是 MOOV 块和头两帧的数据，MOOV 的大小和视频时长有关，而视频每帧的大小则和视频的码率以及编码方式有关。所以如何计算这个大小，也有不少的知识需要准备
这里，你会学到基本的视频编解码以及常见的封装格式的知识
除了命中率，很多耗时往往也出现在播放器创建和渲染的等待，那是不是可以
5 实现播放器预创建+后台预渲染，这样在用户点击播放，直接把渲染好的 layer swap 到前台，进一步提升速度。
这里，你可以学到播放器解码完后的数据是怎么画到屏幕的这个流程，
除了在细节上尝试做得更加极致，另外的方向是把整个过程做得更体系。落到这个问题，我们要回答：这次优化完后，下次如果又变慢了，我们能知道是哪里导致的吗？
6 尝试分析每一次开播的全链路的耗时，创建播放器->layout 播放器 view->下载->解封装->解码->渲染，并建立相应的各阶段耗时监控。这样未来的耗时可以通过报表直观的看到是哪个环节出了问题。
这里，你一方面对于整个播放器的内部逻辑会有相应的了解，另一方面也能收获如何“终结”一个事情的能力。
自我驱动的学习
业余时间的学习往往都来自于三个动机：
- 兴趣使然；
- 工作焦虑，希望寻求业余的成长环节焦虑
- 谋求转行
无论是哪一种，业余时间的学习都比应对工作挑战的学习要难得多。核心原因在于缺乏明确的目标和节奏。漫无目的的看书 or 练习收到的成效往往很一般。另外自我驱动的学习还比较容易遇到一个问题：容易因为一些阶段性的成果而自满。
这里有两个建议： 1 以终为始，项目驱动
项目驱动的意思是你最好以一个具体的项目作为目标来驱动你的学习，而以终为始的意思是，你最好在你还没有开始学习的时候，就先想好你的具体目标。然后再围绕自己的目标去有针对性的展开学习。
比如我当时学习 Haskell 的时候，就立了第一个小目标：写一个 schema 解释器。所以我在之后一直围绕这个目标，重点学 State monad 和 IO， 以及 parser combinator，适当减少了一些 applicative 方向的应用的学习。一定要明白，业余时间的学习是不可能很体系很全的，但至少可以通过几个明确的项目来让自己具备一战的能力。
2 找到大牛聚集的社区，看大牛们都在做什么样的项目
拿机器学习和函数式编程来说，知乎是个不错的地方，很多相关的专业人才都活跃在知乎，通过 fo 他们的问题和回答，可以很容易发现差距，并根据相关的情况制定下一个阶段的目标。
四. 职业规划
职业规划是一个几乎所有人都会面临的问题，但俗一点来看，更多的人遇到的命题更多的是 “XX 很火，我该不该转行”
具体来看，比如近几年都说 iOS 找不到工作了，要不要转后台/AI/区块链/管理。这里我给的意见是：不该。
这并不代表我们要两耳不闻窗外事，而是大多数人对于一个职业所付出的耐心实在太低，在 iOS 上遇到的瓶颈，在其他行业一样会遇到。往往我们认为一个领域没什么事情好干的时候，其实并不是真的没事儿干，而是自己思考不足。这种感觉就像很多人到了 XX 城市的城中村里吃了份蛋炒饭，完了就说 XX 城市很垃圾，脏乱差，但如果真正去 XX 城市最高的大厦里吃着烤鹅肝喝着酒看着城市的日落，我们还会觉得脏乱差吗？
可以试一下这样的一个思维训练：
- 我现在在做的事情，换一个大佬来，能做的比我更好吗？
- 如果可以，那最可能是在哪方面做的比我好？
- 如果知道哪方面，那现在的我可以去做的更好吗？
如果想不出答案，就多和别人，和主管，和大牛同事讨论这几个问题，往往都能发现即便在 iOS 的日常业务有也蕴含着无限的可能性。
另外一个问题是转管理，其实互联网和传统行业不一样，程序员都是 highly motivated 的人，换句话说其实是不用怎么管理的。所以程序员转管理一般是伪命题，你可以当 leader，当 leader 的职责可不是管理，管理顶多占 20%，更多的是抢业务，技术专项的规划与执行、业务的赋能。这一些的基础都是需要丰富的一线作战经验，所以更多的时候不是转不转的问题，而是你到没到的问题。
综上，在职业规划上，我给的建议是：
- 不要轻易转行，优先尝试在自己优势领域开花，成长
- 35 岁以前不要思考要不要转管理