我的2024年度总结：工作的第一年

type

status

date

slug

summary

工作经历

聊聊我的工作经历吧。刚进公司那会儿，我基本上是个彻头彻尾的新手，除了前端和一些基础知识外，其他都是两眼一抹黑。或者说，我根本不知道自己要做什么，更别提怎么做了。毕竟，企业环境和个人使用场景差别还是挺大的。

第一个需求

记得刚来的第一周，我接手的第一个任务是优化大屏低代码平台中图表组件的功能。那个过程真是艰难啊，一方面是因为对代码不熟悉，虽然低代码组件相对独立，阅读起来还算勉强；另一方面是对 ECharts 的掌握，虽然之前用过，但差不多都忘光了，实际操作起来也挺费劲的。大部分时间都花在了阅读代码和调试上，但最终还是在一周内按时完成了任务。

在代码上线到 dev 环境之前，其他前端同事一起对我写的代码进行了 Code Review，并提出了一些宝贵的改进建议，让我受益匪浅。当时因为懂得不多，我的目标就是尽可能完成需求，这也导致了很多问题，尤其是代码的影响范围过大，可能会波及到其他组件，引发未知问题。所以，我学到了要尽可能缩小代码的影响范围，让它只在自己的组件内起作用。经过优化后，代码成功上线到 dev 环境。这也促成了我后来发表的几篇文章：

🚛

ECharts — 饼图相关功能点（内环、外环、环形间隔、环形文字、轮播动画）

🎉

🧸

ECharts — 通过ColorPicker控制ECharts图表的渐变色

正式上线后，我对图表的优化内容进行了演示，大家都很喜欢新特性和功能，我也感到非常有成就感和动力。^_^

git

在这个过程中，我还学会了更多 git 相关的操作。除了基本的 git 操作，还需要了解上线流程、发版、tag 等内容，以及最重要的合并问题。每个需求最好都有一个专门的分支，因为上线不仅仅是将 dev 环境的全部内容上线，而是需要根据需求和排期来决定。

这样，后续只需要将分支合并到特定的 release 分支，然后进行测试，最后发版就可以了。如果忘记了这种流程，通常只能 cherry-pick 过去，再继续后续流程。

由于公司主要做 SaaS 和私有化部署（大部分），这就要求我更加熟悉 git 流程，因为有时候不仅仅是 dev 环境，还有对应私有化环境的 dev 需要测试，其中的内容有的可能一样，有的可能定制化，这就更需要清晰了解各个分支以及分支的合并流程。

lint 库

后续的工作中，我也慢慢接触到了各种各样的需求，包括业务功能等。在编码过程中，我使用了 eslint + prettier，但我个人不太喜欢这套工具，复杂的配置和众多依赖让它看起来臃肿。当时前端统一工具链很火，其中之一的 Biome 集成了 eslint + prettier，以极少的配置完成这一系列工作。所以有空时，我也对这一块内容进行了研究。

我们还有一个 lint 库，专门供其他项目使用，所以当时只需要研究这个库，再对其他项目进行统一升级即可。而且 Biome 在之前的项目中也有实际使用过，所以本身也有使用体验。当时和其他前端讨论后，后续就专门做了研究，并统一更新成了 Biome。详细内容可以看看这篇文章，包括了规范化、格式化等前端基建内容：

🔨

在 Monorepo 中对代码进行规范(husky + lint-staged)

而且到目前为止，Biome 在 v1.9 也可以对 css 进行格式化了，这是非常大的一步。

低代码

再到后面，我开始研究低代码这一块的内容，当时真的是非常入迷，基本上就是做完需求后，就研究低代码这一块的内容。因为这一块内容比较复杂，而且需要一个统一性的归纳、理解，所以并没有第一时间直接去看项目上的实现。

当时在掘金买了个有关低代码的小册，一步一步了解了相关内容，并跟着它一步一步实现了自己的第一份低代码项目：

Editor

https://turbo-web-alpha.vercel.app/

当时做完这个项目，真的挺有成就感的，而且基本上对低代码的结构和使用上有了个大概的了解。我也将其中一些比较好的实现和其他前端小伙伴进行讨论，看看能不能加入到我们自己的低代码平台当中。

在这之后，也和其他前端小伙伴们讨论，打算研发一个自己低代码的引擎；当时我们使用的是 ali 的 lowcode-engine，但因为有比较多的限制，有时候很难进一步使用；所以打算自研一个，于是就开启了一个新的项目：dunhuang，专门用于实现低代码这一块的内容。

但我个人很喜欢 ali 那一套的规范化内容，对整个低代码的物料、schema 等内容进行标准化，实现不同平台之间的互通。

所以在后续实现的过程中也是这么来做的，一个专门用于底层规范的 core，在往上扩展出如 dashboard（大屏）、form（表单）等不同的使用方式，再到最上层的框架选择，如 React、Vue 等来进行最终的渲染。来打通框架之间的界限，达到一个互通的能力。

上面说的可能很简短，但实际做起来，差不多到今年的4月份才完成了第一版；而接下来最为困难的是将其融入到自身的系统当中去，并将 ali 的给去除，这一步花了很长时间，因为改动非常大，涉及的范围也很广（虽然是跟着 ali 的规范走的，但多多少少还是有不一样的）；而且除了迁移，还包括老版本的兼容等内容，那时候还专门写了个适配器，来兼容不同版本的物料更新，以及 schema 的更新等。

最终在7月份的时候，终于发起了第一次上线，当时上完线后，遇到了很多问题，大部分都是因为老版本的问题，因为逻辑上的冲突和不一致，导致最终的显示效果出现了问题，那时候一直在那修问题，一直研究到早上5点多，最终还是没办法，进行了回滚。也在那天大家聚在一起，讨论了这次的上线事故问题，自己也进行了反省和总结。后面再次的测试和调整也算是最终成功上线了。

到此为止，也算是真正的第一版成功融入系统并发版成功。虽然很艰难，但在后续的优化、功能需求、使用上更加自如。

在此中间间隔了一段时间（4-5月），我回到学校进行答辩，并为毕业做准备，同时也放松心情

也推荐一下自己的毕业设计的软件：CheatSheet（一个跨平台显示应用快捷键的软件）

CheatSheet

JinSooo • Updated Dec 2, 2024

到后面，正式毕业了，慢慢稳定下来了，也不再局限于接触业务需求了，开始慢慢向上去理解公司的一些业务内容，同时除了业务上的需求，也开始慢慢接触客户，辅助帮忙解决一些问题。慢慢的也开始独立的去对接一些客户，帮助了解我们的平台，辅助解决一些问题，同时也会根据客户的一些使用和相关问题，提一些优化点和需求点等内容，因为最终的使用还是在客户上，用户使用得好，才能说明产品的好。

到现在也算是独立的处理过几个客户相关的业务了（有时候可能还需其他成员辅助一下）。