冥想 2020-06-01 00:00 folder Blog label Blog

时光飞逝，已经从事前端开发工作三年，也该想想下一个三年的自己应该如何。

如何突破自己，选择新的道路，成为了自己要思考的问题。

先来分享一篇最近读到的不错的文章《【第1933期】钉钉前端团队负责人@贵重：技术团队 TL 如何培养人才？》，其中的一段话很值得我们去思考：

简单介绍一下前端的技术专家需要具备哪些能力？我总结为三点，第一点要看是否具备解构业务问题的能力，第二点看是否具备某领域专家的能力，是团队中该领域最懂的那个人，第三点是看技术影响力如何。每家公司有对应的 Job Model，可以对照去看。对于 JD 要去深入挖掘并提炼为几个能力，在同学接下来培养中，帮他丰富和凸显出来。

所以，此时此刻。我会想到我的下一个三年，我需要找到自己擅长且能走远的方向，朝着某个领域深入，并且结合年初定的知识图谱的目标进行扩散，来提升自己，强壮自己。

至于要朝着哪个领域深入，这成为了我现在需要考虑的问题，非常苦恼也非常迷茫。但是又必须要做抉择，但愿我可以少走弯路，如果走了弯路，也会成为自己的经验吧，只不过这下一个“三”年可能变久了罢了。

这会是我接下来的长期探索目标，加油！

也建议看看《前端之未来》中提到的：

软件研发是一项理论和实践并重的技术，实践尤为重要，因为最终我们是要写出健壮运行的代码给用户用的。不管未来如何，在持续学习和实践中强化对编程、技术、业务的理解才是根本。除了学习和实践与业务最相关的技术外，建议按自己的专长和兴趣把重点放在这些领域：

1. 领域驱动设计：强化领域建模和系统设计能力，力争懂业务、成为领域专家
2. 软件架构设计和软件设计哲学：它们会为系统、框架、类库注入灵魂，让代码有生命力
3. 图形技术：在应用、引擎两层都有广阔的场景，最关键的是图形应用在未来的占比一定会越来越高
4. AI ：不必深入到底层，但需要掌握其使用，不妨先从 TensorFlow 开始

编程是一种修行，应用修行的产物，也是我们与世界交流的方式。未来在哪里并不重要，重要的是以空杯心态持续学习和实践，用心写下每行代码。

回到现在，

📔 日本語学習計画

截至目前《新版 中日交流标准日本语 初级上、下》很顺利的进入第 6 个单元，词汇量依然是一座大山，对口语常用词会感到更多的兴趣，明日頑張ります！必ず成功！

📚 建立自己的前端知识体系

先来说说内部组件开发，参与的基本都是一些基于特定业务的定制化功能开发和少量的 BUG 问题修复。需要在这里提醒的是，需要建立内部代码评审，以 PR 形式来进行操作，直接发版可是有很大的风险的噢，很有可能闯大祸的噢，而且会造成大范围的影响，所以要对公共组件库的发版，迭代进行规范化处理。以一种健康的方式来提升组件库

1. 类似特定业务的定制化功能，采用开设分支进行开发，以分支版本进行发布，支持特定业务
2. BUG 修复和通用功能的开发，则以 PR 形式提出，由团队相关成员评审后并入主版本，对主版本进行长期支持
3. 主版本可以有同行分支 Hotfix 和 Feature 以同时来接受 PR ，做到更合理的版本管理

还是那句话，版本管理是个难事情噢

回过头来看看内部的持续集成机制，内部持续集成机制还算是完善，想借机会去学习了解一下实现过程，来扩充自己

再来说说参与可编辑大屏组件开发工作，可编辑类项目其实都有个通点，就是把开发的大部分权限交给产品或者运营去决定，类似拖拽、自定义、可编辑化的特点于一身，细节就不做说明，因为都差不多。可以说对可视化有了一些简单的接触和了解学习，希望未来有更多的机会。

分享一些经验：

1. 关于在 Windows 上使用 nvm 无作用情况，参考解决方法 #58

• Delete folder C:\Program Files\nodejs
• nvm use
• node -v

2. ECharts 关系图开启 draggable 参数后调整鼠标样式 #5588

chart.on('mousemove', params => {
  const { professionId } = params.data
  if (professionId) {
    chart.getZr().setCursorStyle('pointer')
  } else {
    chart.getZr().setCursorStyle('default')
  }
})

🏇 锻炼身体

自进入我司起，之前制定的日常锻炼小目标开始逐渐没有完成，情有可原，在未来的日子里慢慢重新抓起这些小目标，动起来。每天也只花个 10 分钟左右而已，很轻松啦。（好难坚持啊………………）

拓展阅读

《离开阿里巴巴》

作者有说不能转载，但是里面有些内容确实值得我们思考，我小小摘抄一段，如有侵权，请联系我删除，不好意思呀。

Why leave?

我从 Apple 和乔布斯身上理解到了在做同一件事时，不同的目的会导致做出来的东西天差地别。钱很重要，但如果乔布斯做产品的目的是钱而不是用户体验，那么 Apple 不会是今天的这个 Apple. 我认为做技术产品也是一样的道理，「做好」应该是目的。但能遇到适合「做大」的技术产品的场景是很靠运气的，在这样的情况下，绩效和晋升的压力会让人不得不把「做大」变成了目的，这就导致了：

• 简单的事情复杂化，增加使用者的理解成本（ Cognitive Load ）
• 能使用现有的技术，偏要自己再做一套。由于「做大 -> 晋升」是目的，这样的产品有很大的机率在达成了目的后被放弃。
• 做事态度变成「能用就行」，不关心用户体验。
  这样的做事方式不适合我，也违背了我做技术的理念。

What’s next

我还没有一个很确切的计划，但我希望能去一个地方，定义我价值的不仅仅是因为我用了多牛逼的技术，做了一个多大的「平台」，而是我用技术的手段，给用户创造了什么他们觉得有价值的东西，如何改进了用户体验。又或者我用技术解决了哪些效率问题。

Conclusion

离职不是什么苦大仇深的事，我对阿里没有任何的怨念，阿里有很多很好的地方，只不过不属于这篇文章要讨论的范围。无论在哪个地方，我想要的都是和一群有想法的人一起打磨一个有价值的产品，而不是不同职能的团队都只做对自己 KPI 有利的事。每个公司都有其独特的生存法则，但这个生存法则也应该让那些务实和纯粹的人能很好地生存下去。也许这就是我作为一个技术人的理想主义吧。

整篇博客都写的非常的真实和接地气，建议阅读原文，希望对大家有所启发