总结
本次项目，我首次正式担任组长。这是我第 4 次参加大项目。
以下总结将包含我作为前端组长，以及个体成员的总结报告。
熟练使用基于腾讯文档的成员信息汇总表
一种简单有效的成员基础信息管理手段，经过这 4 次项目，以及熟练地掌握用腾讯文档来管理团队信息的工作方式。其本质就是表格版本的群公告。
熟练使用 apifox 实现前后端接口评审
熟练使用 apifox 的 LLMs 大模型文档能力，快速生成前端做接口请求的工具。实现有效的提效。
该方案经过逐步迭代，迭代情况如下：
08mes
- 初步接触 apifox 工具，整个前端团队和后端团队开始接触该工具。前端开始使用 apifox 的接口类型生成工具。开始约束接口类型。
09oa
- 初步落实基于 apifox 前后端接口评审。
10wms
- 充分使用 apifox 提供的评论和状态变更功能，使接口联调过程逐步细粒化。
- 前端开始汇报前后端接口评审的进度，并尝试将人员直接下放整合到各个后端小组内。
- 前端开始尝试使用 AI 工具，批量生成接口。
11comm
- 前端提出完整完善的接口联调规范，统一解决接口联调出现的普遍问题。
- 前端开始定期的，周期性的反馈接口评审的进度。
- 前端很早的时候就下放到各个后端组内，延长接口评审的窗口期。
- 前端总结出完善的，基于 apifox 的接口批量生成方案。
多次项目产出的框架性、复用性沉淀
在历次项目内，针对高频出现的业务场景，我不断总结经验，提炼出多个可高度复用的工具包。均已经发布到 npm 项目内。
基于 useAxios 组合式 api 的接口请求方案
将这些项目常用的接口请求范式，统一封装成一个第三方工具库 @ruan-cat/utils 内，便于下一次项目直接复用。
基于 vercel 的项目部署方案
锤炼出基于 vercel 平台的部署工具 @ruan-cat/vercel-deploy-tool 。实现项目在开发阶段就能够产出生产环境页面，及时暴露生产环境阶段可能的隐患。
基于 vitepress 的技术文档生成方案
从 10wms 项目开始，沉淀出工具 @ruan-cat/vitepress-preset-config ，便于快速搭建项目内的组件库文档。
本次项目产出的新技术沉淀
反复验证针对 pnpm 安装依赖失败的处理方案
从 10wms 开始，项目组成员就多次出现 pnpm 安装依赖失败，项目启动报缺少依赖的故障。在本次项目内，该处理方案得到反复验证，均可以有效处置。
熟练使用基于文件目录生成路由的方案
从 09oa 开始，就积极使用 unplugin-vue-router 插件实现基于文件目录结构，生成结构化路由的技术方案。现在已经能够免于配置冗长的 router 路由对象了。
没有做到有意义的接口联调
接口评审不等于接口联调。尽管接口评审有方案，有文档，有平台，有联系方式，但是由于前端成员普遍的基础知识极度欠缺，前端没办法实现有意义的接口联调。
- 在这 4 轮项目内，前端普遍没办法完成静态页面。
- 前端普遍不会做 promise 异步请求，并从异步请求内获取数据，渲染到页面内。
- 前端普遍不知道要在 onMounted 生命周期内做异步接口请求。
老生常谈的时间问题
从 08wms 项目开始，前端组成员总是数量不足的，且有效投入时间不够。这导致很多内容没办法得到产出，没有得到有效的结果。
成为组长带来的全新挑战
TODO: 等待补全
任务进度监控
难易度细粒度划分
冗杂云效工单的维护
大量会议与沟通
组员水平仍旧参差不齐
完全失能
只要是大二的成员，就是完全失能的。只要是刚刚开始学习 javascript 基础的，学习前端 3 大件的，在本项目就是完全失能的。这一类成员完全没办法参与本项目。
尽管我进入到其他后端组内，见到过有水准高的大二学生，但是凤毛麟角，不具有参考意义。
这一类成员不适合大项目，是阿伟学长放水进来的。很遗憾我们不是真实的企业，没办法辞退对方。
这一类成员最耗费我的时间，而且在他们身上投入时间，往往没有任何回报。他们也没办法达到我的任务期望。
有能力，但不多
普遍是大三、大四成员。他们经历过 1~2 个完整或部分的前端项目。能够按照要求开发页面。
这一类成员适合大项目，可惜人数不够多。
这一类成员听话，并主动的沟通。为他们投入时间，是值得的。是满足 28 定律的。
他们能够有效的给出反馈，给出报错日志，是开发的骨干力量。
有想法，但不听话
有些成员有能力，但不按照要求来开发，导致出现不必要的时间损耗，最终导致没有任何有意义的成果产出。
他们有能力，但是不按照规范，导致没办法协作，产出能用的东西。
这一类成员适合自己单干，做出小 demo。
在他们身上投入的精力，主要是沟通和提醒。沟通起来其实很卡手，并不是很顺畅。
完全胜任，但不想做
有少数成员，完全能够胜任下达的要求，并且埋怨布置的任务过于简单枯燥。很遗憾，在本次项目中，我没办法大胆的使用更加激进的技术，做出更加精彩的作品出来。
这一类成员就是被牺牲掉的成员。他们的时间事实上被浪费在低水准的重复内。
这一类成员其实不适合大项目了，大项目没办法给他们足够的成长。
这一类成员完全不需要我操心，是完美的成员。0 沟通成本，100%无回滚，无任何报错的代码。
无需沟通，心有灵犀。
本项目后续维护策略
本项目后续将由我本人，和每一个后端沟通，由我来对接接口。很遗憾，不太能指望其他前端能够将接口真正的落实到页面内。
未来的项目策略
享受组长权利，但不承担组长责任。
针对未来的第五次大项目：
- 拓展业务视野：了解业务，拓展视野。增加简历谈资。
- 无需保持手感：不需要考虑自己的编程手感问题，时刻保持最佳产出状态，不再以维护手感的目标参加项目。
- 不承担前端团队责任：不再考虑带领前端团队。不考虑与能力不足的成员协作，避免投入过多无法兑现成有效成果的时间。
- 主动承担前后端接口联调沟通责任：主动进入各个后端组，承担接口评审的责任。并确保接口满足业务需求。
- 独立完成项目：独立组建 F2 组，并独立使用一揽子工具实现项目开发。
- 参加例行的组长会议：以独立前端组的身份，参加组长会议，并对项目接口对接进度负责。
- 不承担传统前端组长责任：这些责任包括：
- 技术培训。
- 代码整合。
- 进度管控。
- 任务划分。
- 考勤记录。
- 答疑解惑。
- 仅对后端成员负责：不再考虑为任何前端成员负责，只对后端产出的接口负责。
- 获得普遍的管理员权限：加入各个后端小组群，并成为管理员。便于加快接口联调。
- 以只读身份加入前端组：保持最低限度的沟通，以通知，通告的身份，加入前端 f1 组。
- 不增加任何成员：前端 F2 组作为独立组，不考虑增加任何成员，避免削弱 f1 组。
贡献者
ruan-cat