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

2022-10-25
中国香港
本文字数：3025 字
阅读完需：约 10 分钟

10 月 23 号，在 CCF CED 2022 大会上，Jina AI 联合创始人兼 CTO 王楠博士代表 Jina AI 团队分享了《从神经搜索到多模态应用：和全球团队一起打造优秀的开源工具》，与全国线上线下的工程师们交流“工程师文化”。

随着全球数字化转型的飞速进展，工程师文化在国内也开始越来越被重视甚至普及。今年 10 月 23 日在北京举办的 “CCF CED 2022——第二届 1024 中国工程师文化日”大会，围绕“工程师文化驱动组织创新”主题，汇聚了全球数十位的 CTO、大咖、院士为大家带来独特思考视角与案例实践。数千名国内工程师、程序员及软件技术爱好者们共享了这一盛会。

作为一个开源软件公司，Jina AI 打造了以效率提升和分布式开源协同为核心的工程师文化，吸引到来自全球十几个国家的工程师以分布式的形式协同工作。在 Jina AI，工程师文化不是加班文化，更不是内卷文化，而是对效率和好奇心的不断追求。

Jina AI 从成立之始，就是一个推崇工程师文化，拥抱开源的国际化团队。作为践行“工程师文化”的创业公司代表，团队受邀出席了本次大会，并邀请了社区开发者代表一起到现场交流。Jina AI 联合创始人兼 CTO 王楠博士在活动现场特别分享了《从神经搜索到多模态应用：和全球团队一起打造优秀的开源工具》。以下是本次分享的内容，我们希望弘扬工程师精神，不断激发创新，也希望本次分享可以为广大社区开发者带来一些新的灵感，祝大家 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 平台的演化背后，我们内部强调快速开源协同的⼯程⽂化发挥了⾮常⼤的作⽤。

现场精彩回顾