入职离职，离职入职，循环往复，生生不息。天下无不散之筵席，我也到了要和当下公司说再见的时候了。
其实有时候挺羡慕有些同事一毕业之后就一直在一家公司工作很久，首先说明这家公司的业务比较稳定，其次个人在这家公司能够得到较为长足的发展，最直接的是工资可以稳步提升，技能也会越来越扎实，这其实对我们程序员来说还是比较难得的，反正我个人从实习到现在工作近三年的时间，已经换了很多份工作了，其中有些是公司的原因，也有些是个人的原因，兜兜转转，走来走去其实现在想来不是很好，尤其是在工作前几年经验不是很丰富的情况下，频繁跳槽不会带来工资上的多少提升，唯一的好处可能是：如果你非常善于学习的话，可以有更丰富的项目经验，以及通过不同的同事来学习到每个人所特有的一些长处，或是为人处事方面的，或是专业技能方面的。
自2020年10月份笔者入职现公司到今天离职，感觉时间还是过的很快的。对个人职业生涯发展和人际关系相处方面有了很多新的认识。这一次离职更多的是个人的原因——笔者打算回家发展，理由也很简单，家里工作可以和另一半长期相处，并且以后也有很大机会在老家买房，当然在外工作也可以攒钱老家买房，速度可能还会快些。只是笔者觉得老家买房老家住，而不是老家买房外面租房住，这样会好一些。并且早在2020年夏天的时候，笔者就已经打探了老家的相关工作岗位，作为一个三线城市来说，虽然不多，但却也足以容纳一个在外漂泊多年又想要返乡的的灵魂了。工资待遇上，因为笔者打听的是 web 前端开发相关的岗位，这里只说前端相关的待遇，平均工资待遇大概是二线城市平均水平的 60%。一线城市平均水平的 50% 的样子。个人还是可以接受的，并且最重要的是可以和心爱的人一起朝夕相处，工资相比之下只能算是一个小问题了。
说会在公司工作的 2021 年度吧。如前所述，笔者主要学习到了工作技能和人际关系相处两个方面。
工作技能方面，2021 年来说，web 前端最流行的开发技术还是 vue 和 react。国内的中小型公司 vue.js 的使用量更大，特别是 vue3 开始流行以来。目前来看 vue3 + TypeScript 的技术栈是未来2年国内前端发展的主要方向。react 相关则还是 react hooks 及相关生态系统。殊途同归，其实熟悉了 vue3 也就容易上手 react hooks ，就笔者个人来说，更偏爱 vue3 ,相比于 jsx 的 render 函数式语法，笔者更钟爱在业务需求中写模板语法，也许有先入为主的原因。在工作中笔者 vue 和 react 都写过，也都维护过相关的项目，总的来说还是觉得在业务尤其是网页中写模板语法比 jsx 会更直观一些。当然 jsx 更加灵活，并且相比于 vue 中还是不断新生的各类语法糖来说，react 和 jsx 的这套技术栈组合更加拥抱原生 JS 语法，几乎没有什么新增的语法糖，这其实是 react 系框架技术的优势所在。
也因此，笔者在 21 年主要学习了 vue3 和 TypeScript 的相关知识，并且已经运用到了新的项目中，效果还是很不错的，特别是 vue3 解决了之前 vue2 的一些“顽疾”，比如说一直让人比较头疼的响应式对象检测问题了：
这和 vue2 的响应式实现原理 Object.defineProperty 的局限性有关，彼时 ES6 的新特性 Proxy 还没有完全普及，特别是在 IE 浏览器下的支持度很不好。如今微软已经放弃了 IE 系浏览器转而全面拥抱基于 Chromium 的新 edge 浏览器，ES6 语法新特性已在主流浏览器中普及，而 vue3 的响应式原理基于 Proxy 正当时。那么现在就无需再当心响应式的 vue 对象/数组新增或删除属性不会被检测到的问题了。再比如 vue3 的合成型API（Composition API）代码风格，可以更加方便的写出 hooks 风格的代码，hooks 风格代码除了有更简洁、更低的代码耦合度的优点外，还可以更加方便的做代码功能复用和 Tree Shaking.在过去，vue2 及 react 老版本在做代码复用时常常利用混入（mixin）,当然 react 还可以利用高阶组件来实现。但是这些实现都不是很优雅，特别是 混入 的做法，就笔者实际开发项目来说，如果大量使用混入会使项目代码逻辑结构更加不清晰，也会越来越不容易维护，而使用 hooks 风格的代码可以较好的解决此类问题（前提是需要扎实的 JS 基础和良好的 hooks 函数封装经验）。Mixins Considered Harmful – React Bloghttps://zh-hans.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html
关于 mixins 做法的问题，这里有一篇文章做了详尽的解释。这也是现在 vue3/react hooks 大行其道的原因之一。
21年，笔者除了学习了 vue3 相关知识外，另一个比较重要的是学习了 uniApp 的相关开发。作为一个跨端开发框架来说，uniApp 实用吗？很实用！好用吗？个人觉得很一般，但确确实实是能够解决项目中的很多问题。首先 uniApp 的最大有点在于降低了开发成本。一套代码可以在经过相关配置之后运行在 web，小程序（各大平台），App（安卓和 iOS）上。现在国内很多面向广大用户的产品都要求自己的软件不仅要有网页版的，还要有小程序，甚至还要有 App，如果按照传统模式开发，至少需要 3 个团队，web 开发团队，App开发团队（还需细分成 安卓和 ios），小程序开发团队。当然，一般小程序开发可以被 web 开发团队兼任，但是 App 开发，即使不使用原生开发技术，利用 RN， flutter，weex 等跨端框架，同样需要另外招人。那么 uniApp 可以把这三拨人减为一拨人，确实有很大作用。但是事实远没有那么简单。首先是项目具体需求方面，如果是一个要求较为简单的产品，譬如一个小型的管理系统，一个小型的在线商店，那么使用 uniApp 开发问题不大。而如果是一个较大型的项目，使用 uniApp 开发需要解决的问题就很多：
1. uniApp 和其他框架结合使用产生 bug 的问题：这里问题有很多不仅少见而且比较难排查解决，如这篇文章介绍的 在 uniApp 项目中使用 echarts tooltip 无法解析 html 标签的问题及解决_似水流年的博客-CSDN博客前言如题，最近笔者所在项目组正在开发一个需要有 web，h5及App版本的项目。那么在技术选型的时候我们自然是想到了目前国内比较火的 uniApp 了，根据其官网介绍是一次开发到处使用啊，而且uni本身也是基于 vue 生态开发的，对我们之前一直使用 vue 全家桶开发的前端人员来说也是比较容易过渡（仔细一想目前如果是要开发一个同时带有 web h5和 app 的项目，除了 uni 的话，可能就是React Native(主要是开发App)， weex（类似RN但是用的更少），最有前景的 Flutterhttps://blog.csdn.net/a715167986/article/details/113559444
2. 实际开发中各种小 bug 较多，有很多淤积问题一直没有得到有效解决。虽然 uniApp 在国内使用者较多，但是比之 RN flutter 等同类解决方案来说，uni 一方面没有英文文档（外国人几乎没法使用，中文文档水平也不很高），另一方面社区维护力量较弱，所以很多小问题一直存在却无人解决。
3. App 开发相关体验较差。使用 uni 开发小程序体验尚可，但是开发相关 App 就不是那么容易的了。当然这里也不能全算 uniApp 的问题，毕竟本身 App 需要的相关经验就很多。比如说安卓App的离线通知功能在国内由于厂商自定义 ROM 五花八门需要各种适配，而开发 iOS App 需要 Xcode 工具，申请成为苹果开发者等等。而使用 uni 开发需要踩坑的地方就更多了，比如安装包的打包等。
总的来说，uniApp 的出现很好的解决了一些问题，但是也引入了一些新的问题，就程序员的开发体验来说，是比较一般的。具体使用与否还是要取决于具体的业务场景。
21 年，微前端概念的流行。应该说从 2020 年开始，微前端的概念便开始大行其道了。当然了，一般的项目其实是使用不到的。之所以笔者接触到是因为近期笔者参与的公司开发的项目使用到了一个有名的微前端框架 qiankun.js 。这是一个关于设备仪器的管理系统，业务较为庞大，但是私以为实际上也还没达到使用 qiankun 的程度，而之所以还是上了 qiankun 是因为项目开发的时间较长（一年半以上），最初开发是还是 vue2 版本，之后 vue3 开始越来越流行，考虑到新功能可以使用 vue3 写，但是原有业务是 vue2 实现的问题，再加上项目本身的体量于是使用 qiankun 改造。具体做法是将项目拆分成 8 个子应用，以具体模块功能来划分，原有功能使用 vue2 技术栈，新模块全部采用 vue3 技术栈，在这种情况下，新功能的开发技术栈不在受限于原有技术体系，即使是使用 react 开发也没有问题。当然，qiankun 框架的配置还是有很多坑需要踩的。应该说微前端适用于大项目大团队开发，比如 qiankun 的开发公司阿里这一类体量的公司业务，可以同时让多个团队并行开发多个子应用，各个小团队具体的模块实现方法不做限制，最终合并到一个大项目中运行。
关于 21 年的总结内容很多，笔者暂时先更新这些，其他有时间再补。
文章出处登录后可见！
