1024 分享｜如何打造围绕开源理念的团队工程师文化

Jina AI 是一家商业化开源软件公司，我们专注于打造针对多模态应用的 MLOps 工具，成立两年多来，累计融资 3800 万美金，连续两年登上 CB Insights 全球 AI 初创排行榜前 100。

我们先后发布了包括 Jina、DocArray，CLIP-as-service 等多个开源项目，累计超过 35k GitHub 关注。在这些成绩背后，是我们来自于十几个国家的全球团队，和我们围绕开源理念打造的工程师文化。

分布式

作为?家开源软件公司，我们把分布式开源协同作为我们?程师?化的基?。 

分布式?作的关键在于信任和责任。

• 我们采取全球化招募的策略，不限制?作地点，?作时间可灵活安排。对所有团队成员，?家每周可以有?天居家?作。这背后其实是我们对于团队成员的充分信任和以解决问题为导向的价值观。我们不限制解决?案是哪个级别的?程师提出的，我们只在乎问题有没有解决。只有可以解决问题，我们就会欢迎加?。

• 要实现分布式?作，很重要的是强调?驱?。所以，分布式协作的另?个关键词是责任。我们?励每?名团队成员都承担责任，都成为决策者。我们的每个?团队都有充分的?治权利，从技术选型到维护服务，从撰写?档到吸引 区客户，每个?团队都要对??的项?负责任。同时，我们不会让团队成员为错误买单。因为每个?都会犯错误，初创企业其实就是?个??个错误?过来的，我们强调的是尽量少犯错误，不犯相同的错误，及早发现类似的错误。

开源

开源不是把代码发到  GitHub 就结束了，开源是?种协作?式。

我们内部所有的代码都是全公司可?的，绝?部分代码也都是开源的，整个世界的程序员也都可以看到。所有?都可以去做 Code Review，所有?都可以随时去给任何?个项?去修复 Bug 和提 PR。这样的开源协作?式不仅提?我们内部的交流效率，同时也能充分发挥每个?的主动性。因为这样的?式类似于每个?都在公开的?作，?家?然?然的会对代码质量提?要求。《?活?客》这本书?也提到过这样公开?作的?式?常有利于提升?作效率和按时完成?标。可能有?伙伴会问我分享出去不就让?家都学了我的独?绝技了是，我很赞同的?个观点是，我们这个时代缺少的不是知识，?是专注?和意志?。?别?的注意?能帮助提???的意志?。通过开源这种公开的?作?式，其实每个?的意志?都会提?，也更有可能完成?作。 

• 开源也意味着分享。每个星期的我们都会有公司内?程团队的分享，每个??程团队还会和 区在 Office Hours 等 区活动中分享我们最新的进展和 区?起讨论问题。分享的作?不仅仅在于分享知识，更在于帮助?家形成定期思考和总结的习惯，从?不断的去?我提升和改善产品。 

• 开源的另?个常常被忽视的动作是要经常性地发布新版本。发布新版本不仅仅是为了保持快速的开发节奏，?且可以?舞团队的?志。

协同

协同的核?是标准化、?动化，减少能量耗散，让团队更关注核?代码。

• Code Review 是我们对每个?程师的要求。在 Jina AI，每个?每天都会有固定的时间去 Review 其他成员的代码。我们在内部设?的各种?便搭建 AFR 的的机制，包括 Team Alias，Slack 提醒，合并前强制 CR 等等。 

• 多次 Commit，尽早提 PR。我们对每个新?职的成员都会要求尽早完成?个 PR。我们强调 PR 的 merge 才是?作的结束，我们会要求 PR 要尽量在 2-3 个?作?内合并。尽量避免?型 PR，鼓励多个? PR。因为代码库是对全公司开放的，每个?都可以 CR，也可以参与讨论。这样帮助初级?程师快速成?，同时讨论也能够迫使?去思考代码的实现是否合理。

• 统?的编程?格。我们强制进??动化的代码?格检查。 

• 提?协同效率的?个关键是尽可能?动化?切流程。我们?度依赖 GHA，有?动化的 Release Notes ?成、?档?成、版本发布、代码?格检查等等。 

• ?动化的另?个要求就是尽可能多的写测试。我们?常强调测试的覆盖率，要求项?的覆盖率都要在 75% 以上。充分的测试才能保证我们能够?频次的发布和流程的?动化。

从神经搜索到多模态应?

?程师?化对于科技企业是维持?效率的关键。作为 Jina AI 的核?项?之?， Jina 在过去两年的时间内已经完成了三个主版本的迭代，迭代背后其实就是我们?程师?化在?撑。我们的?程师团队会积极回复 区提问，也会认真的总结反馈，我们的三次迭代都是根据?户反馈进?的?我升级。我们?了 8 个?的时间发布 Jina 1，发布后收到很多反馈说东?好?，但是学习曲线太陡峭，学习成本太?。所以我们很快的做出调整，简化概念，优化设计，在 6 个?后推出 Jina 2， 区反映热烈。Jina 2 推出后，我们内部的?程师留意到开发者在部署到?产环境时的困难，主要是因为我们对于 Kubernetes 不能做到原??持。于是我们?开始了第三次重构，在重写了两万多?代码之后，我们发布了 Jina 3，也迎来了我们 区增?的??个?潮。

截??前，Jina 代码仓库已经累计收获 GitHub 上的 16,370 开发者的收藏。从 Jina 0.0.5到 Jina 3.10.1，我们?共发布了 360 个版本，累计新增代码 88,240 ?，删除 18,309 ?。除了代码的快速迭代之外，我们的?档?平和 区问答的活跃度也得到了 区的普遍认可，工程师在日常工作中会主动参与?档撰写和 区论坛维护。 

在 Jina 3 之前，我们把??定位在神经搜索领域。在开发 Jina 3 的过程中，我们内部的?程师也注意到我们底层?于封装多模态数据的数据结构其实?常通?，完全可以当做?个单独的?具使?，于是?个新的项? DocArray 应运??。随着 Jina3 和 DocArray 的推出，我们的 区?开始衍?出很多 MLOps 相关的应?，包括有 区?伙伴? Jina 去搭建 NLU 平台，我们??也尝试? Jina 和 DocArray 去搭建?些?成 AI 的应?，推出了 Dall·E Flow 和 DiscoArt 这两个开源项?，也获得了?常?的成功，纷纷冲上了 GitHub 的全球 Trending 排?榜。在最近，我们也尝试和? Jina 去搭建了基于 Whisper 模型的语?到?字?成 AI 应?。

从神经搜索到 MLOps 平台的演化背后，我们内部强调快速开源协同的?程?化发挥了?常?的作?。

现场精彩回顾

分享

扫码了解 Jina 团队打造的

多模态 AI 开源工具

更多精彩内容（点击图片阅读）

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92550 人正在系统学习中