算是第二次参加线上训练营了。第一次参加的是datawhale大模型应用开发活动，头脑风暴会议就没人发言，到项目开发的时候集体装死，算是让我对"线上与陌生人组队"这一行为有了很差的印象。
这次参加字节青训营也是抱着再试试的感觉，在群里发个学历然后组队，也引来了同校的学妹和学长一起组队。最后大家对项目要写不写的，项目提交截止前一周我愤而解散队伍，但两个学妹还是想把她们的这个第一个Go项目写完，所以在有导师压力的情况下，还是努力的完成了基本的购物流程，结营成功了，但项目很失败。
队员管理
作为队长，能体验到如何管理线上组队开发的分工及进度安排。飞书的功能已经很完善了，具备了群聊/即时会议/团队文档/计划安排文档等功能，对于管理上已经很方便了。但更重要的不是工具，而是管人，需要对组员能力有了解，对开发进度有预计，对分工要合理。由于在招组员时我高估了最低大三最高研三的组员的能力，导致了分工无法合理，算是为这次活动的失败奠定了基础。
关于主持会议。作为队长也提高了我主持会议的能力，为了了解组员情况与开发进度以及进行问题交流，即时会议是不能被打字聊天所取代的。在会议前就要做好会议议程，按顺序列好，并提前发给组员让他们有个准备。在开会时也要积极活跃气氛，以我这两次组队的经验来看，大部分人只要不点名点到头上，是屁都不讲的，顶多打字回复。我不讨论什么计算机专业学生的i人e人，愿意来参加组队就应该积极聊天，我一开始就讲好了大家都是来青训营学习的，都是年龄相差无几的学生，不要太拘束。结果会议还是没人说话。还好有位学长性格比较好，也是正在字节实习的，开会基本上就是我俩在聊，其实没啥意思。而且作为学生我也不是很专业，本来想与组员一起商量，最后没人回复，就变成所有的方案都由我一人敲定。但我敲定!=大家都能实现，最后导致设计好的方案都不执行。。。很开心组员能听我的如“明晚开会”之类的安排，但真开会却不积极参与，就很没意思了了。
关于代码托管
由于这次青训营，我第一次琢磨github的组织与仓库内的操作，为了避免误操作，同时还能使用到CICD。对于学这些东西我觉得是很受益的。
为了避免main分支被组员误覆盖，我会在仓库里设置main分支只能通过PR的merge被更新。由于此次组队，队员都算核心成员，也让队员无需fork，开个新branch就行。为了避免成员写的垃圾代码，设置了需要review以及github workflow的代码质量分析与测试。然而由于我挺忙，就把必须review才能merge关了，让组员查看CICD的情况，但CICD的配置也没写好，导致代码有问题但还是能被提交。
除此之外，组员也总是不懂merge，出现冲突就束手无策，对此我只能说：建议招人的时候招有经验的或者有学习热情的人。。。
哦，github workflow只能在public的仓库里开启，如果介意的可以考虑其他方式。
关于规范
良好的规范能有效减少项目的隐藏问题和开发人员沟通成本以及维护成本。然而这组员不看网上推荐的规范就算了，连队长安排的规范也不看，放在那让看的demo也不会模仿，即所谓的"不报错就是好代码"，队长也没那么多空做code review，真无语！
关于开发
组长写好的代码生成工具(如kitex基于thrift生成代码)的使用方式不看，就看官方文档里的，然后一堆乱七八糟的生成文件自己不删或者添加到gitignore，甚至不知道哪个IDE自动生成的gitignore，把我写的覆盖了不说，他自己都不知道为什么会生成。。。这样就导致把我gitignore里原本写好的config.yaml删掉了，然后数据库密码就成功进入仓库了。。。我也只能呵呵了。 至于业务？能咋简单实现就咋简单实现，单元测试没人写，mock没人会弄。一个学习项目，定时任务也不想着堆技术栈，就轮询，好像多学点就浪费时间一样，那还来啥青训营？
如果在之后的青训营中当队长的，建议如下：
-
首要的是，确定是否真的想做完。像我就是做到一半感觉在浪费时间，结营证书用处不大，电商业务也基本都懂。我本来就想尝试下可观测性组件的配置和使用，以及研究下支付里的事务设计，却一直在改组员的CRUD代码，弄完也是个半成品，电商项目好像作为简历项目是最泛滥(也不能说烂)的一个了？。所以做完没有意义，那么就不要想着组队了。
-
选人：选择与自己技术能力差不多的，减少沟通难度，也避免决策时没人应，讨论时没人懂。然后研三的也不要选了，不是在实习就是弄论文，都不是很看重这个结营。然后尽量选有学习能力的(也算是技术能力好的吧)，不然就会我这边，研三组员说自己的IDE没有爆红，让我帮忙改bug；C9保研选手一个支付宝对接弄了一个月，最后我使劲催，三天弄完；哦还有个go版本都不一致就往上push的。只能说来参加的可能一开始还是有热情，后续就摆烂不想弄了，所以如果真的想做完，就尽量在选人方面多下功夫吧。
-
时间安排：如果真的想圆满做完，就要付出很多时间在上面了，不要想着组员给你分担工作，好人办坏事的情况比比皆是，没有上下级关系的压制或者罚款的威胁，是什么错都能轻易犯得出来。这种情况组长的任务就很艰巨了。
收获
这里还是列举一下自己的收获吧。
- 学会了建立github的组织以及成员的邀请和权限设置。
- 学会了设置项目的权限，比如必须review和只能从pr里merge。
- 加深了对github workflow的使用熟练度。
- 学会了使用飞书知识库，并以相对易懂，开箱即用的文档帮助组员上手。
- 搜集了不少免费的serverless服务，关于DB/Redis/Vercel/VectorDB/LLM都有。
- 学会了怎么在Golang中安排微服务项目的目录组织。go.work确实好用(但是组员的跨服务导包又是那么令人气愤)
- 微服务是怎么进行服务发现和调用的。其实就是中间件管理有哪些正在运行的RPC服务端，然后各个服务内可以通过客户端从中间件获取一个目标服务并调用远程接口。与单体项目的区别在开发中感受的尤为明显，服务内的接口可以尽量只关心自己的逻辑。
- 再次体会了用Air进行热重载的爽。
- 对cloudwego的几个项目有一定的熟悉了。对eino进行了深度的了解，也写了一篇文章：带你用Eino实现Agent与RAG
缺憾
- 可观测性组件是让组员实现的，自己没有上手。不过看到那几个Grafana等页面的出现，还是很满足的。
- 没有真正思考和实现支付业务，以后有机会再想想。
- agent服务写的不够好。
- 没有把数据库mock写好。
- 没有把数据库索引设计好。
- 没有搭建集群并压测，可靠可用性没有实测过。
- 没有试着体验下k8s管理集群。
- 虽然写好了Pinecone的demo，但由于时间问题没有把商品搜索接入向量数据库，搜索效果还是不好。
2个月的时间，让我从雄心勃勃变成认清现实，已经完全不想参加任何线上组队活动了。去弄开源去了。
