只写后台管理的前端要怎么提升自己

jinchanchan

这篇内容的别名是：讲述了一头驴开始研究为什么转动可以带动磨盘，以及如何提升磨盘的工作效率。（自我调侃）

本人写了五年的后台管理。每次面试前就会头疼，因为写的页面除了表单就是表格。抱怨过苦恼过也后悔过，但是站在现在的时间点回想以前，发现有很多事情可以做的更好，于是有了这篇文章。

写优雅的代码
一道面试题
大概两年以前，面试美团的时候，面试官让我写一道代码题，时间单位转换。具体的题目我忘记了。
原题目我没做过，但是我写的业务代码代码里有类似的单位转换，后端返回一个数字，单位是kb，而我要展示成KB，MB等形式。大概写一个工具函数（具体怎么写的忘记了，不过功能比这个复杂点），但是我写在面试时的代码得到了面试官的赞扬，也因此非常顺利的通过了面试。

如何提升代码质量
想提升代码质量，最理想的是靠 code review ，但实际上这玩意在大多数公司根本就不存在。其次就只能多看看大佬们写的代码，但是一来后台管理本来就没太大难度很少有大佬，二来很多时候一个后台管理系统就一两个人负责。
还好现在有了各种 AI 工具，可以非常方便的优化自己的代码了。
还是上面的问题，看了GPT 给的答案，我只能说 NB！（但是也建议大家在使用AI工具时，重点是借鉴思路，直接使用代码需要谨慎~）
我现在每次写大段逻辑之后都习惯拿给 AI 看看，有什么更好的实现方式，或者用什么设计模式。AI 是非常低成本且高效提升代码质量的工具。

关注业务
对于前端业务重要吗？
相比于后端来说，前端一般不会太关注业务。就算出了问题大部分也是后端的问题。
但是就我找工作的经验，业务非常重要！
如果你做的工作很有技术含量，比如你在做低代码，你可以面试时讲一个小时的技术难点。但是你只是一个破写后台管理，你什么都没有的说。这个时候，了解业务就成为了你的亮点。
<顺便吆喝一句，推荐个技术大厂机会；年前捞人较多，门槛较低；前、后端/测试；base上海、南京、西安、东莞等多地）

如何了解业务
1.每次接需求的时候，都要了解需求背景，并主动去理解
我们写一个表格简简单单，把数据展示出来就好，但是表格中的数据是什么意思呢？比如我之前写一个 kafka 管理平台，里面有表格表单，涉及什么 cluster controller topic broker partition…… 我真的完全不了解，很后悔我几年时间也没有耐下心来去了解。
2.每次做完一个需求，都需要了解结果
有些时候，后台管理的团队可能根本没有PM，那你也要和业务方了解，这个功能做了之后，多少人使用，效率提高了吗？数据是怎样的？
3.理解需求，并主动去优化
产品要展示一千条数据，你要考虑要不要分页，不分页会不会卡，要不要上虚拟表格？
产品要做一个可拖拽表单，你要考虑是否需要拖动，是否需要配置。
其实很多时候，产品的思维可能会被局限在竞品的实现方式，而前端可以给TA更多选项。在和产品沟通的时候，你不仅是沟通页面的实现，也更能理解业务。

关注源码
说到源码， Vue，React 这些基本是每次必问，也有太多大佬们的总结我就不多说了。
除此之外，我想大家每次面试应该都会被问，你写了什么亮点的项目，困难的项目，你会说什么？哦，都是表单表格，都用 Element UI 实现的，没什么难度。那估计你面试也就到这里了。
那说什么，后台管理就这些啊？！
如果你用了 Element UI 你可以说写了什么自定义 Element UI 表单组件，Element UI 表单源码是什么原理，怎么通信的？用了 Axios 可以说 Axios 的原理，它的拦截器怎么实现的？用了编辑器 diff 那你知道 diff 算法是什么吗？用了 ECharts 那你知道他底层是用什么绘制的吗？用了 husky ？husky的原理是什么？用了Vite，它为什么快？是怎么打包的？写过插件吗？
可能有人觉得我离谱，事实上上面每一个问题都是我在面试中真实被问到的。当然，如果全部去了解，肯定不现实，每个人的精力有限，不可能每个用到的每个工具每个库都去了解原理，不过只要有一两个你去了解过，就可以在面试中引导面试官来问，要学会表现出你擅长的点。

技术选型
技术栈选 Vue 还是 React？Vue 选 Vue2 还是 Vue3？组件库选 ElementUI 还是 Ant Design？微前端有没有使用过？打包工具用 Vite 还是 Webpack？有那么多表单怎么实现的，有没有什么表单配置化方案，比如Formily？
对于我这种菜鸡，我这种只写简单的表单表格的人，这些都……无所谓……
不过为了应对面试我们还是需要了解下未选择技术栈的缺点，和已选择技术栈的优点（有点本末倒置…但是常规操作啦）
Vue 你可以说简单高效轻量级，面试必会问你为什么，你就开始说 Vue 的响应式系统，依赖收集等。
React 你可以说 JSX、Hooks 很灵活，那你必然要考虑 JSX 怎么编译， Hooks 实现方式等。
总体而言，对于技术选型，依赖于我们对所有可选项的理解，做选择可能很容易，给出合理的理由还是需要花费一些精力的。

前端监控
干了这么多年前端，前端监控我是……一点没做过。
前端监控，简单来说就是我们在前端程序中记录一些信息并上报，一般是错误信息，来方便我们及时发现问题并解决问题。除此之外也会有性能监控，用户行为的监控（埋点）等。之前也听过有些团队分享前端监控，为了出现问题明确责任（方便甩锅）。
对于实现方案，无论使用第三方库还是自己实现，重要的都是理解实现原理。
对于错误监控，可以了解一下 Sentry，原理简单来说就是通过 window.onerror 和 window.addEventListener('unhandledrejection', ...) 去分别捕获同步和异步错误，然后通过错误信息和 sourceMap 来定位到源码。
对于性能监控，我们可以通过 window.performance、PerformanceObserver 等 API 收集页面性能相关的指标，除此之外，还需要关注接口的响应时间。
最后，收集到信息之后，还要考虑数据上报的方案，比如使用 navigator.sendBeacon 还是 Fetch、AJAX？是批量上报，实时上报，还是延迟上报？上报的数据格式等等。

CI/CD
持续集成（Continuous Integration, CI）和 持续部署（Continuous Deployment, CD），主要包括版本控制，代码合并，构建，单测，部署等一系列前端工作流。
场景的工作流有 Jenkins、 Gitlab CI 等。我们可以配置在合并代码时自动打包部署，在提交代码时自动构建并发布包等。
这块我了解不多，但感觉这些工具层面的东西，不太会涉及到原理，基本上就是使用的问题。还是需要自己亲自动手试一下，才能知道细节。比如在 Gitlab CI 中， Pipeline、Stage和Job 分别是什么，怎么配置，如何在不同环境配置不同工作流等。

总结
写了这么多，可能有人会问，如果能回到过去，你会怎么做。
啊，我只能说，说是一回事，做又是另一回事，事实上我并不希望回到过去去卷一遍，菜点没关系，快乐就好，一切都是最好的安排。

转自作者：我不吃饼干（juejin.cn/post/7360528073631318027）