Loading... > @author: 郭瑞峰 > > @createTime: 2023/11/30 > > @updateTime: 2023/12/06 ## ~~前言~~ 唠嗑 俺自己弄自己写博客是为了记录自己的脚步，走成功就留下近道，方便其他兴趣者抄近道提升；走失败了就留下血迹(魂类游戏の特色)，方便其他人看看我是这么寄的。 我曾经给自己规定，一个月最少留下一片技术性的或者经验性值的博客，方便自己自我总结。结果十月底后，咱忙得不可开交~~，都没时间水群~~，写博客的规划就一拖再拖，最后都十二月了，emmmm，不能再拖了。今天就写完。 ~~6号的今儿，加个班，努力写完吧~~。 ## 一、个人方面 ### 角色转变 以前是组员，会追求极致的代码逻辑或写出最优性能的算法。但现在你是组长了，你得学会接纳不完美，比如每次mr的时候不能太过计较组员代码性能或者代码逻辑(个人经验，可能不用于大厂)。 其二，在团队中，平常心非常重要。无论是组长还是组员，大家都是打工人，没有高人一等的态度。 ### 学习方向 学习方向要从原来的**学得深**改为**看得广**。这样方便给组员提供解决问题思路或者功能实现方案。 > 当组员的时候我会专研得很深，甚至会深入专研vue2底层代码甚至去自己手写一个自己的vue2 demo。 > > 当组长后，我很少专研底层代码或者底层架构了，大多都是看其他作者如何解决没见过的业务的问题，亦或者是使用某个依赖出现的模块出现问题以及避免方法。积累新模块使用以及新的业务解决方案。  ## 二、组内安排 ### 统筹和分配 产品给的需求、后端配合人员、bug转交等等，这些都归属于任务类型，要记得如何分配任务以及实时跟踪进度（按天跟踪最好）。  分配任务时候请注意： * 产品需求方面一定要记住划分模块，再记住模块对应的组员，方便后续QA多轮轮测试时候bug指向对应的组员，亦或者编写《XXXX技术规格书》时将其划分给对应组员 * 对每个任务划分好难度，根据组员能力差异给到最优解 ### 学会做自己组的产品(建议) **注意，这个只是建议，不是必须！** 前端组长也要会当产品？是，也不是。比如说在项目立项前期，有些东西必须前端自己规划好，如框架搭建指南、二次封装的公共组件（如搜索表单，公共列表，echarts的各类型图表），这个时候就需要你自己做自己的产品经理，自己写相关的需求文档或者技术规格文档。 可以不写么？如果你能让组员明白你的规划或者明白你的思路，你可以不用写，只需要交代就行。否则还是建议写一下。 ### 提供一定的情绪价值 这个只可意会不可言传的，需要自己把握好度，平衡好自己的情绪以及组员的情绪。  # 三、项目组角色 前端组长还是前端开发，所以说本职前端工作要有，还得担当一些其他任务。 ### 做好项目组副手 虽然是前端组长，虽然入手的是js、ts、node，但你还是要了解一些其他与前端开发或者与项目组相关的东西，这里是我经历过的一些事儿，可以借鉴一下： * 学一些基础的PS平面设计概念，便于和UI统一意见 * `linux` 虚机，需要本地VMware或者公司服务器 * `CI/CD` 流程 * `docker` 配置文件、基础指令 * `nginx` 设置反向代理 * `shell` 脚本编写 * 手写case，方便开发自测 * 了解公司发布流程，准备好补充缺失的文件 * 学会公司文件管理方式，如`SVN`、企业级`Visual Studio` ### 与UI配合 以下是我根据个人经验总结的一些建议： * 组长层面 * 确认公共组件统一样式 * 公共列表样式 * 搜索表单样式 * `Dialog/Modal`对话框 宽度和最大高度以及高度是否固定 * `Description` 统一样式 * 滚动条样式(`Chrome`和`Firefox`) * `Button/Tag` 边框弧度 * `Layout`框架样式，如菜单padding距离、 * 文本/内容超出部分处理方案 * 图片使用格式 `png/svg` * `Notification`通知框出现位置、按钮、存在时间 * 统一图表获取方式，如提供手动图表库或者使用三方图表库 * 参与设计图评审 * 创建编辑操作时注意其标注必填项以及对应选项框是否一致 * 首页/门户页面/欢迎页面/列表 处理文本过长，内容过多的方案 * 交互/大屏 动画效果确认 * 开发层面 * 学会自己切图，如使用国内的'蓝湖'，'即使设计'，亦或者是adobe的XD * 让UI帮忙修图时候尽量让UI用上SVG图片 * SVG是矢量图，可以提供图层信息，方便UI调整 * 如果涉及动画效果之类的(如告警闪烁效果)，可以给UI写个可调整页面，让UI自己寻找合适的感觉 ### 与产品配合 以下是我根据个人经验总结的一些建议： * 组长层面： * 需求评审时 * 建议记录每个具体的模块以及其大概功能点(比如创建，编辑，删除这类操作性的，如果详情里也有的话同步记录)，方便后续分配任务以及自测时写case * 这个算是空话，但还是记下来吧：~~仔细听产品报告，确认功能可行性~~ * 帮产品搭建原型图服务，方便UI和自己组员查阅 * 开发层面 * 功能时间过于耗时并且不是主要功能时，及时告诉产品，协商解决方案 * 集成系统并且无法从三方系统/三方厂商获取数据或者是，必须及时告诉产品 ### 与后端配合 唯一一个跟咱一样是开发的，懂逻辑的童鞋们~~，感觉我可以偷个懒不写建议~~，还是要写一下建议： * 组长层面： * 及时告知后端童鞋配合一起开发的前端童鞋 * 协助后端更新服务器上的容器，或者帮其完善`CI/CD`  # 尾声 如果不嫌弃，请大佬们在评论区教我做人。  最后修改：2024 年 11 月 27 日 © 允许规范转载 赞 0 如果觉得我的文章对你有用，请随意赞赏
1 条评论
文章中的实用建议和操作指南，让读者受益匪浅，值得珍藏。