JetBrains OpenDay 2019

    2020-01-03

    转自 蚂蚁研发效能 公众号文章

    2019 JetBrains OpenDay 主要为 JetBrains 圣彼得堡分部的乔迁庆典，安排了较多的专题介绍，包括产品技术、公司文化等等

    整个系列的视频公开在 Youtube 都是俄文讲述（除 Hadi 的两个），Slides 也是一样，只能借助 Youtb 的字幕翻译来尝试一窥究竟。挑了几个视频来重点笔记一下，借此可以管窥 JetBrains 对 IDE 产品演进的规划、对竞争对手产品的看待，及内部的研发交付体系等等。信息难免会有失真，内容仅供参考；此外夹带了一些个人观点

    Максим Шафиров: Коротко про JetBrains сейчас и потом

    CEO Maxim Shafirov 的 KeyNote，简要介绍 JetBrains，6分钟的讲述重点在后半段，Maxim 上来先拿索引效率来自黑了一下——

    提到成立了 JetBrains Labs 来应对目前的一些技术挑战，点出了几个问题 / 方向：

    • X-Platform Desktop UI
    • Fast & Flexible Build
    • Horizontal Scalable Source Code Manipulation

    众所周知 JetBrains 在 Java GUI 上是已臻化境，但不可否认这也是一个历史包袱、且是逐渐凋零的生态；GC Pauses 可能带来不可避免的卡顿感，以及 Maxim 提到的 IDE 内存开销巨大，所带来的体验 / 成本上的负担一直都是用户抱怨的点。Maxim 也提到了 Electron 可能作为 UI 方案，实际上 JetBrains 几个桌面应用所用到的技术栈非常丰富，JetBrains Toolbox 是用 QT 实现的，最新发布的 Space 使用了 Electron 来打包桌面版 App；可以说这个 X-Platform Desktop UI 的选型上，很可能会带来惊喜

    第二点构建系统上，提到 …build system not flexible enough, do not work adequately in conjunction with the design model that we have… 整个 intellij-community 的代码库太重，可能跟不上产品的创新节奏

    第三点旗帜鲜明的讲述了云端研发场景，即如何解决代码的云端存储和计算，很可能这也会颠覆 JetBrains 桌面产品的商业策略，… ( for source code ) does not fit into one machine, and we can use cloud processing power…

    这三个开放性问题是没有答案的，这也是做工具链研发都在面临的问题

    IDE wars: мы, наши друзья, наши соперники и наши…партнёры (Кирилл Скрыган)

    标题翻译：《IDE大战：我们，我们的朋友，我们的竞争对手和我们的合作伙伴》

    Rider 的 Team Lead Kirill Skrygan 做的一个主题演讲，标题机翻过来别有一番趣味，浓浓的路线斗争的感觉。Skrygan 一上来就表态说他的内容观点会有争议，只代表他个人观点

    首先复述了一下 JetBrains 的历史，从 IntelliJ Renamer 这么一个插件成长至今，以及 IntelliJ 成长过程经历的 IDE 圣战

    创业伊始，给 JBuilder 做插件（IntelliJ CodeSearch, IntelliJ Renamer）
    2000 年左右 Martin Flowler 的《重构》文章刚刚发布，重构的概念慢慢成为一个工程实践
    20 年后 JetBrains 已是一个独角兽企业，具备完整的 IDE 产品线 + SaaS 产品，及一个工业级编程语言 Kotlin

    Skrygan 总结的 IDE 1.0、2.0：

    • 1.0 更多是 flat text editor，主要在编程界面上的能力整合上，工具属性更重一些
    • 2.0 具备 smart knowledge of the structure about the semantics of code，基于对代码语义的理解，实现了如图中的高级重构能力；这也是开发者能切实体会到的相对 1.0 的代差感的部分

    接下来 3.0 的部分，只有一个疑问句 “IDE 3.0?”，Skrygan 讲述了他的观点，提炼出来的关键字：

    • Cloud
    • Artificial Intelligence

    关于 Cloud 的设想是 everything can be calculated in advance in the cloud，即每个人打开的 IDE 都是直接是云端预构建好的；这个观点同 IntelliJ Platform 2020 Roadmap 中关于索引能力增强的规划很接近，即避免每个用户的 IDE 都对 JDK 建本地索引；预构建的 Index chunks 是否可以像制品库一样被分发，这是个很有趣的思路

    在回顾历史的最后一个 Slide，Skrygan 自问 Почему мыl победили?（为什么我们赢了 IDE wars），答案也是非常有阿里味道，“因为相信”

    接下来快进到 2010 年代左右，Skrygan 提出了 Platform <-> Tools 的关联关系，工具 Tools 主要解决特定领域问题，但发展壮大后、也会成为一个平台 Platform，同时带动一定的生态（比如 IntelliJ Platform 和插件生态）。整个结构蔓延开即形成一个网络，拿 ReSharper 举例，它是 Visual Studio 的一个 Plugin，而 VS 这个平台只是 C#、JS 等几个开发语言的工具，同样这些 PL 依赖一些 Runtime 如 .NET 的支持，再之上是操作系统，最顶层又有云平台如 Azure 的存在

    另一点提到的就是平台的稳固性，因此会出现一些跨层级的的合作，比如最上层的 IBM Cloud 跟第二层 Linux 生态的合作（IBM 收购 RedHat 故事）；同样为了扩展生态，也有类似曲线救国的合作路径，比如 Google 跟 Unity 的合作以让 GCP 支持 C#。类似我厂常说的“结网”能力，将 DevOps 产品矩阵进行融合并产生协同效应

    接下来两张图分别是 MicroSoft 同 JetBrains 的领地图，也解释了一下为什么 JetBrains 要投入做 Kotlin，以及为何 Kotlin 要做到跨平台支持（Kotlin/JVM, Kotlin/Native, Kotlin/JS）

    接下来的内容终于紧扣主题，讲述了工业级 IDE 产品里能挑战 JetBrains 的竞品，毫无悬念地点名了 VS 和 VSCode. LSP 协议设计上的优势，能确保编辑器的顺滑体验，但更多是 UX 层面的协议；这个架构下可以实现 Remote Development 是一个非常有竞争力的点，直接把 IDE 从传统的桌面领域切入到云端场景

    JetBrains 的 RD 协议也基于类似的设计，并且在 2020 Roadmap 中也提到基于 RD 协议解耦 “thin client” 和 “primary IDE” 以实现诸如协同编辑等能力的规划。VSCode 基于 LSP 协议实现的 All Language Support 确实会是 JetBrains 产品的一大挑战，但 Skrygan 给了一个观点是 “VSCode is a tool to promote Azure”，感觉有失偏颇。

    Инфраструктурные задачи в компании (Денис Яковлев)

    这个视频中 Yakovlev 主要讲述了一些 Infra 层面的架构体系，诸如网络、构建、发布、系统安全等等

    JetBrains 的产品矩阵有桌面软件（Desktop, 主要是 IDE 全家桶） 及 SaaS 产品（Web Services, 即 TeamCity、UpSource、Hub、YouTrack）

    首先提到的是 Desktop 部分，持续交付自然是基于自己家的 TeamCity，一些数字

    • 20000 Build Configuration (Jobs)
    • 19000 Builds / Day
    • ~1000 VM

    首先整个 CI/CD 系统共有 20k 个的构建任务，每天大概跑 19k 笔（考虑到 Codebase 的庞大，这个 Build 的分量是可想而知的）。整个构建系统大概要 ~1k 台 VM，由于要兼容多平台（Windows / Linux / MacOS），用到 VMWare 虚拟化方案、也在逐步应用 AWS 云服务，使用了 Packer (HashiCorp) 定义多平台的镜像

    这个过程的挑战，主要提到性能、资源利用率、消除瓶颈（可能意指在代码量大时造成的一些特殊问题）

    • Performance
    • Utilization
    • Bottleneck removal

    接下来是 Web Services 部分；从一个桌面软件商的角度来看，流量是相当惊人了

    • CDN（主要是托管 IDE 软件包）
      • ~36 TB / Day
      • ~1.1 PB in May
    • Plugins Market（IDE 插件市场）
      • 182 TB / Month
      • 570 M Requests / Month
    • Billing / License / jetbrains.com / ~100 Small Services

    大部分 Web Services 交付形态是 Docker 镜像，使用 Terraform 编排、部署在 AWS；目前也在向 k8s (Amazon EKS) 迁移；提到这部分的挑战：

    • Common cluster for all
    • Unified process:
      • Deploy
      • Backing Services (logging, monitoring, etc)

    最后提到了一些 IT 基础设施，比如分布式办公带来的一些问题

    Как мы перешли на единый репозиторий (Дмитрий Панов)

    一个跟代码服务相关的主题，主要讲述 IntelliJ 这个巨无霸的大库研发的故事

    IntelliJ IDEA

    • 600+ thousand commits
    • 13+ million lines of code（备注，GitHub 上开源的 IntelliJ CE 版本的代码量相对少一些，~7.5m loc）
    • 3.5G working tree
    • 7.9G .git/objects

    首先讨论了单一大库和分库的区别，由于历史原因，内部有以下 6 个 Repo，且构建一个 IDE 产品依赖多个仓库源码组合；同时 IntelliJ CE（图中顶部）、Android Tools（倒数第二层）、Plugins（底部）三个库是开源的，而第二层私有仓库还包含了 IntelliJ ULT 的商业化代码；因此问题来了，内部开发者的本地代码该如何组织，以及代码提交流程怎么设定

    最淳朴的想法是，开发者本地及 CI 任务的代码结构都基于目录隔离（如下左图）；但造成的较多问题

    如一次全局重构涉及了 6 个库的整体改动，可能要被迫拆成 6 笔提交（ commit split ）；而 CI 机一侧的代码工作空间，由于 6 个库的入库顺序差异、导致构建的时刻不一定都拉取齐全（右侧 TC 图中，两个打叉的提交没有 Pull 下来），可能导致构建失败 ( broken CI )

    IntelliJ 采用了一个单一大库和分库共存的策略，内部开发者日常编码、提交、构建的库是单一库：

    针对这个大库的原子提交会基于目录被自动化拆成向几个子库的提交（右图剪刀示意）
    同时由于子库中有几个库是开源的，可能有社区开发者针对单库的提交；这些提交也生成一个大库的提交（左图）
    这个过程用到了 Google copybara 来做用户无感的代码迁移

    最后一个彩蛋，从2分钟的 OpenDay 集锦视频里，看这个迎宾区的名字，是不是联想到了 KotlinConf 2019 发布的 Space 这个产品了

    图中的红色线是来宾自己贴上去的，可以看到大部分都带有求职意向的（上图最左侧 Goal 中的 Find Your Job），并且形成了一个很有趣的热点分布。OpenDay 也是招纳贤才的一个不错窗口

    现场图片，转自 https://medium.com/@promeetups/jetbrains-open-day-2019-573a4d0636f8