当我们踏入 2023 年之际，回顾 2022 年的所见所闻，让我不禁想起那句“岁月匆匆，时光荏苒”。在这个充满变化与挑战的一年里，我也经历了许多值得回顾和总结的事情。

上半年：

工作：

项目日常迭代
项目改造 微前端、MUI，后续项目被推翻
Vite 在项目中落地
Node 日志服务落地
结构组织变更 业务部门 ⇒ 平台架构

个人成长：

团队内部分享：《孙子兵法》
微前端 qiankun
MUI
Vite学习
Node：最佳规范学习、日志相关学习 winston
复习计划：基础知识、React Fiber深究、React 18 UI Concurrent Mode学习、Webpack、算法学习
书籍：《被讨厌的勇气》

总结：

有新技术的尝试，但是不多，好在有两项落地

微前端、MUI
Vite落地
Node最佳规范学习
Node日志服务落地
复习计划

上半年币圈跌太狠，心态发生变化

技术⇒业务落地能力差

Vite去年规划的落地，但是在落地过程中经常出现Vite因开发环境和生产环境构建工具链不一致产生的问题，即开发环境代码正常运行，生产环境代码运行出错。

个人产生疑虑：

①.怕上线前，某些模块测试不到位，引发线上bug

②.后续应用开发时也会出现开发环境可用，但是生产环境不可用

但其实这些问题都是可以通过自己解决的，还是缺乏冒险者精神。

后续可以落地，也是在组内同事的牵头下才得以完成。

看书方面，自驱力太差

明明安排好的时间，却都在刷短视频，时间管理差，一周只有两三个小时看书

好在读书的时候认真，吸收较多，但是得加多看书的时间

结构组织变更

影响较大，改变不了环境，只能改变自己了

下半年：

工作：

项目日常迭代
开放平台、开放平台后台页开发 DNA改版新规划、微前端落地
六路监控平台改造 作为开发平台应用进行上架

个人成长：

团队内部分享：《印度种姓制度》
新建脚手架 quick-vite-web
微前端 MicroApp、Wujie
CSS原子化 Tailwindcss
MUI组件封装
前端 + 客户端 = 终端认知
复习计划：上半年涉及到的知识重新梳理、React源码、Vue和React实现上的区别
书籍：《骆驼祥子》

总结：

没有后端方面的知识涉猎，前端知识方面也无建树

新建脚手架
微前端
MUI组件封装
复习计划

项目管理方面太弱，需要提前学习相关知识，主动出击承担任务

项目管控方面一直没有过多参与，一直是作为开发者的身份

开发者⇒项目管理者，需要注意的事项，如何处理好人际关系

自身能力的突破，得靠自己一步一步的积累

UI组件封装没有做到位

MUI组件本身更多的是为我们提供原子化的组件，细粒化程度非常高。我们需要像搭积木一样，将这些原子化的组件进行组装。

jsx
//antd 
<Table columns={columns} dataSource={data} />

//mui 
<TableContainer component={Paper}>
      <Table>

        <TableHead>
          <TableRow>
          {columns.map((col)=>(
            <TableCell>
                   ......
              </TableCell>
            ))}
          </TableRow>
        </TableHead>

        <TableBody>
          {data.map((row) => (
            <TableRow>
              <TableCell>
                   ......
              </TableCell>
            </TableRow>
          ))}
        </TableBody>

      </Table>
    </TableContainer>

目标是将这一大串的Table相关组件，封装为

，前期进行封装的时候，也探讨过相关细节。

但是在最后使用的时候，总感觉不得劲，很多情况下需要往组件里面新增属性以应对新需求。

后续应该注意的点：

①.封装的组件，所有的Element都应该加class类名，不准使用style或者sx的方式修改样式

②.规划时，不应该将Table、Form这类组件定义为业务组件，如果有很复杂的Table组件，应该考虑使用基础组件组装的方式进行拼接。

定义为业务组件的劣势在与，UI、内部逻辑处理都会高度耦合，但实际上每套页面都会有自己的复杂度，有自己的相互逻辑，强行结合后，在其它页面进行使用，需要大费周章的修改样式。

和UI设计师也很难定义出一套可以通用的业务组件。

③.无非必要，不新增组件Props。现在我们是通过组装MUI的组件，去达到一个我们理想中的基础组件的效果。但MUI组件颗粒度非常细，譬如我现在分别要在TableContainer、Table上新增Props时，比较好的做法是

jsx
<Table props={{
 TableProps:
 TableContainerProps:
}}>

使用MUI组件需要投入较大的精力，去做好组件的封装，要不然真的非常难，很难组件都需要自己去实现，比如Form、Upload、（Modal、Message Api方式调用）……

还是Antd做的更大更全而且还免费，拿上来可以直接开发项目，不过喜欢自己动手封装组件的话，MUI也是不错的选择。

事情还是得多记多写，不能只停留于看

年初看了几篇神文，但是当时仅仅是看，没有上手操作，一直没能懂文章封神的原因。

年尾再次阅读到，一步一步根据文章操作，才发现真是一步一步娓娓道来，使我眼前一亮，豁然开朗。而且这一两年，我发现自己看文章，仅仅停留于看，很少会上手操作，当时认为的懂，我觉得和实际上的懂，有着很大的差距。可能和近年来刷短视频有关系，短暂的知识碎片，并没有对我的大脑进行输入。

终端认知

此终端，非彼终端。

终端概念是我今年在D2圆桌之夜听到的，那何为终端，前端+客户端，那这和我们的大前端区别于哪里，为什么兴起终端呢？

说白了，我们可以把终端理解成一个岗位，以后没有前端开发工程师，也没有客户端开发工程师，

只有终端开发工程师，终端开发工程师具有处理前端和客户端的能力，那这样就意味着终端开发工程师相较于其他岗位，至少需要有更广的知识面。

那终端开发工程师的优势在哪里？

第一点当然是降本，2022年的互联网冬天比去年更冷，各大互联网巨头都在裁员降本，如果能将终端这条路实践走通，真正意义上的将两个岗位合并成一个岗位，是有利于公司降本。

第二点是提效，原先在会议上讨论这个业务需求是客户端做还是前端做，如果现在你属于一位终端开发工程师，那就不会有这样的争论。至于是选前端技术来做还是客户端技术来做，技术方案都由你这边敲定。原先因为工种不同的薄纱被掀开，你也会真正的站在一个开发者的角度去进行选型，而不是把时间浪费在无意义的争论上，可能因为这块业务没有绩效的增长点，你就会说这一块我们做不了，需要给你们做，你们更适合。

走通终端这条路，一定会遇到很多问题，两端的融合，不是一蹴而就的，是需要人才的积累加上实践的真知，如果走通，将大大提高入行门槛。可能是3年后，也可能是10年后，也可能是30年后

但我相信终端这条路是可以被实践走通的，打破两端壁垒，只是时间问题。

面对可能即将到来的风暴，加强自身的计算机基础会显得格外重要。

目录

上半年：

工作：

个人成长：

总结：

下半年：

工作：

个人成长：

总结：