如果在公司学不到，那么就业余时间学学。
如果没有业余时间，那还是换一家公司比较好。
绝大多数开发者都是在维护老系统，绝大多数开发者都在写业务代码。但是，并不是新框架才是新技术，对于你不懂的东西，都是新技术/技能。
写业务代码一样可以提升，除非你业务很重很赶，那就没有办法了，毕竟质量和速度是成反比的。如果项目不紧，可以重新审查自己的业务代码，如何才能使代码更优雅，如何才能使每个模块更优雅，……
写 clear code 对于新人来说也是“新技术/新技能”。之前 shit 一样的代码被你写的更利于维护了，那么你也是在进步。之前高耦合的代码被你写的更加灵活了，这也是进步。
学习 rxjs 后，并不是使用了你有用。你学了它的思想，在你目前的业务里面一样可以写出类似的代码，而且你会发现你的代码质量变得比以前更好了。
高级程序员炫耀代码，低级程序员炫耀工具
我的学习方法就是多读书，多交流（不限于线上和线下）
我每天早上 5:30 起床看书，除了技术书籍外还有很多其它书籍。然后就是多交流多分享。
多写多做。
我们都不是计算机科学家，我们只是编程语言的使用者，学编程还得多编码。
我的建议就是：别用框架。
但是不要误解，不是让你放弃这个框架。其实当我们一旦使用了框架，就再也回不去了。如果你学了某个 mvc 框架，比如 react，你不知道如何提升自己了，那就放空自己，下一个项目别用 react，而用 jQuery，或者连 jQuery 都不用，写一个程序。
不是让你真回到之前的 jQuery 式的开发模式，而是使用 “jQuery + React思想” 开发一个程序，这样你才能真正的深入了解这个框架。
只有这样，你才能称之为”你控制了这个框架，而不是框架控制你“。
年龄从来不是问题。
做科研的转编程，应该难度不大。前几天还有一个厨师转编程的向我咨询如何做职业规划的问题。
提到“性趣”，我多说几句“直白”的话，不过，不是为了打击你。
很多人喜欢开车，但是如果他当上了公交车司机、出租车司机……他还会对开车有“兴趣”吗，养家糊口而已。
编程也一样，很多人从小热爱电脑，热爱编程，但是一旦称为了职业，编程就是一份工作而已。如果一帆风顺，那么会一直“有兴趣”。但是难免会有挫折。
有个故事我在线下分享时讲了很多遍了，今天在 React 中文社区再讲一遍。
很所有故事都类似，这个故事的主人公也是“我的一个朋友”。
我的一个曾经的同事，有天他告诉我说，他的一个小学同学开了一个早点铺，每月转一万多甚至更多。他也想回家去试试。
他说，他对编程没有天赋，数学基础太差，还是做点小买卖比较适合他。
我告诉他，其实做小买卖很辛苦的，你只看到了他们赚钱，没有看到他们多累，每天都得凌晨三四点钟起床。……
他说：我能吃苦。
我：…… 如果你能每天早上三四点起来编程，你也早就可以独当一面了。你既然不能三四点起床编程，你就能三四点起床做早点吗？那些三四点起床做早点的是为了养家糊口，而你无忧无虑根本没有动力。
。。。~~。。。
后来他还是回家了。
等我在此联系他时已经半年过去了，他去了南方的一个城市。我和他寒暄了几句。他回家确实做了个小买卖，但是赔了很多钱，不得已又回到了一线城市继续编程。
如果你对科研工作毫无兴趣，那么其实 IT 也很枯燥。所以，当你想转行时，一定要考虑清楚了。考虑最坏的情况：如果你对 IT 不敢兴趣了，怎么办?是继续以 it 养家糊口，还是重回科研？
我两年换了不止两个工作。
既然不适合，那就别勉强自己。
确实大部分 hr 对频繁跳槽，或多或少会“在意”的。如果 hr 因为跳槽而否定一个人，那么这种公司不去也罢。
但是一般 hr 都会看看简历描述，自己甄别一下，如果跳槽是为了”逃避"，或者是一时冲动，或者是没有完美理由，那么这种跳槽可能确实会导致简历被筛掉。但是如果跳槽是为了“进步”，是对自己未来发展目标而做出的理性决策，那么那种跳槽反而称为了一个加分项啊。
把重复的工作交给程序去做，比如业务很相似，功能很相似、文件结构很相似，那么你可以考虑写个自动化脚本来做这些，或者写个脚手架，甚至可以和主管沟通，开发一个基础平台（或者在现有平台上开发一个子模块），用来配置这些重复的工作。
如果公司性质是外包，那么我的建议是换个平台。
对于程序员来讲，最重要的就是技术和时间。我们的时间在一天天减少，技术在一天天增加，我们就是在用时间换技术。当我们的时间减少了，但是技术却没有增加，那么我们就是在虚度时间。
这个确实没有办法，有些 bug 确实修复的时间比较长，只能绕过或者忍。
为什么会有这种担心呢。
而且这本来也不该称之为一个问题，你可以问：“小明只会用 JavaScript 写 hello world，这种迁移是否会影响小明的就业难度”，我肯定回答“会”。
那么你看看这个 https://gitlab.com/kornelski/babel-preset-php
PHP input →
～
define('FOO', max(floatval($c), strlen("foo")));
$bar['x'][][$b] = json_encode(__FILE__);
class Foo extends Bar\Baz {
var $z = "hello" . "world";
function __construct($some = array(7)) {
parent::__construct(func_get_args());
self::${$k} = "{$this->z[10]}";
}
}
→ generated JS
const FOO = Math.max(+c, "foo".length);
bar.x.push({[b]: JSON.stringify(__filename)});
class Foo extends Bar.Baz {
constructor(some = [7]) {
super(arguments);
this.z = "hello" + "world";
this.constructor[k] = `${this.z[10]}`;
}
}
那么 php 会影响 nodejs 的就业难度吗。
看看隔壁 iOS 社区的 objc 和 swift 就知道了。
上一张火的不得了的思维导图：
不知道会不会被压缩，原图链接 http://www.hacke2.cn/images/article/mind-pages/%E5%89%8D%E7%AB%AF.jpg
如果往一个或几个方向深挖，那么就是走技术专家的路线。比如我们最常提到的性能、安全。
推荐你看看知乎上面的这个问题 阿里巴巴p7级是什么级别？阿里的分类是怎样的？
这是一个普遍存在的问题，很多公司老板不重视前端，也不重视用户体验，由于是 2B 的产品更加明显。
由于公司的主要业务都在后端，所以公司普遍会看重后端。但是在这个看脸的时代，前端就是公司产品的脸面啊。很多公司也不看重由于前端改版优化了用户体验而带来的业务提升，况且很多公司也没有相应的数据收集和分析，所以也很难以数据说话。
比如 KPI，很多做法是在前端加一个小红点，某些指标可以轻松达成，但是这个功劳一般会属于 PM。前端的价值又被忽视了。
技术型/产品型公司比较关注产品的迭代，而业务型公司则更关注后端的稳定和高效。
作为开发者，确实无力改变
之前的 js 没有模块机制，然后社区发展出了各种各样的模块机制，比较流行的有 CommonJS 和 AMD。而 esm 则是在语言标准的层面上实现的，其它的都是在库层面。
esm 在编译时就能确定模块的依赖关系，而 cjs 和 AMD只能在运行时确定。
node 采用了 cjs，而浏览器则依赖于 webpack，如果在非 webpack 情况下，出现了 UMD 方式，所以 cjs 和 amd 都不是同构的。虽然通过第三方库可以做到。
而 esm 则可以做到浏览器和服务器的统一。
简单看了看，是整合了第三方的 OAuth 吗
这种一个 sdk 集成杂七杂八的服务，确实很常见，也解决了开发者的很多复杂事情，让开发者更加专注于业务逻辑。比如那些集成分享功能的，集成支付功能的，等等
但是集成了用户系统的，开发者可以会更加抵触吧
没有细看，可能了解的不是很清楚，上面的是我的第一感觉
首先技术为业务服务，没有问题。
对于初起步的公司，产品就是需要快速迭代的，这个可以理解，我自己也经理过。
至于如何平衡，通过你的描述，大概是技术无法积累，所有的时间都花费在了功能的迭代上，很多需要改善的东西，比如流程、重构、测试、……都跟不上，或者没有时间做，以至于自己的技术无法提升。
在职场中，首要的任务就是完成公司安排的任务，然后再提升自己。而不是反过来。
而公司就是花钱来买你的时间和技术，如果在工作中无法提升，那么只能在业余时间进修。
发现今天没有人问具体技术，也没有人贴代码。
昨天有人问了几个 Promise 的执行顺序问题，今天也不知道什么原因删除了。
今天就先回答这些吧。
以后有 JavaScript 或者 react 问题可以随时在社区提问然后 at 我。
再次感谢 react 中文社区，感谢题叶，感谢天羽
大家晚安
感谢的 @justjavac 精彩的回答, 一共有 40+ 个回答, 光是打字就要很多心思了. 
这个帖子接下来锁定, 如果需要大家可以在预告帖继续讨论~ 活动预告, justjavac 的 AMA, 周二周三进行 或者开心的帖子.
也欢迎大家继续参与以后论坛上的线上活动.
