开篇

曾经的我，满怀激情地踏入“线上训练营”的门槛，期待在这里找到属于自己的舞台。但现实往往比想象中更为骨感。两年过去了，我参加了两次线上训练营，每一次都带给我不同的收获与反思。

第一次的心得

记得第一次参加的是“datawhale大模型应用开发活动”。头脑风暴时，会议室里一片寂静，仿佛每个人都在等待别人先开口。项目开发时，更是出现了集体“装死”的现象。这次经历让我对“线上与陌生人组队”产生了深深的疑虑。

字节青训营的尝试

这次参加字节青训营，我抱着再试一次的心态。在群里发布学历信息后，竟然引来了同校的学妹和学长一起组队。然而，项目进行得并不顺利。就在提交截止前一周，我愤而解散了队伍，但两个学妹还是坚持要把她们的第一个Go项目完成。在导师的压力下，她们还是努力地完成了基本的购物流程，最终结营成功。但项目却因为种种原因失败了。

队员管理的启示

作为队长，我深刻体会到了如何管理线上组队开发的分工及进度安排。飞书的功能已经非常完善，但对于管理来说，更重要的是管人。需要对组员的能力有充分的了解，对开发进度有合理的预计，对分工要合理。由于在招组员时高估了他们的能力，导致了分工无法合理，为这次活动的失败埋下了伏笔。

会议主持的艺术

作为队长，我还提高了自己主持会议的能力。为了了解组员的情况与开发进度，以及进行问题交流，即时会议是不能被打字聊天所取代的。在会议前就要做好会议议程，按顺序列好，并提前发给组员让他们有个准备。在开会时也要积极活跃气氛，但大部分人只要不点名点到头上，是屁都不讲的。

代码托管的智慧

这次青训营，我第一次琢磨github的组织与仓库内的操作。为了避免误操作，同时还能使用到CI/CD。为了避免main分支被组员误覆盖，我会在仓库里设置main分支只能通过PR的merge被更新。然而，由于我挺忙，就把必须review才能merge关了，让组员查看CI/CD的情况，但CI/CD的配置也没写好，导致代码有问题但还是能被提交。

规范的重要性

良好的规范能有效减少项目的隐藏问题和开发人员沟通成本以及维护成本。然而，这组员不看网上推荐的规范就算了，连队长安排的规范也不看。即所谓的“不报错就是好代码”，队长也没那么多空做code review，真无语！

开发组长的责任

作为开发组长，写好的代码生成工具的使用方式不看，就看官方文档里的，然后一堆乱七八糟的生成文件自己不删或者添加到gitignore。为了避免main分支被组员误覆盖，我会在仓库里设置main分支只能通过PR的merge被更新。由于此次组队，队员都算核心成员，也让队员无需fork，开个新branch就行。

业务实现的反思

至于业务，能咋简单实现就咋简单实现，单元测试没人写，mock没人会弄。一个学习项目，定时任务也不想着堆技术栈，就轮询，好像多学点就浪费时间一样。

后记

两个月的时间，让我从雄心勃勃变成认清现实，已经完全不想参加任何线上组队活动了。去弄开源去了。