与 JetBrains 的 Hadi Hariri 聊开发者工具、Kotlin 与工程哲学

Spring 生态的 "Bootiful Podcast" 系列最近请到了 JetBrains 的传奇人物 Hadi Hariri。如果你在开发者社区里待过几年，大概率听过他的演讲——从 Kotlin 推广到 IntelliJ IDEA 插件生态，从团队协作到工具哲学，Hadi 的观点始终围绕一个核心：工具应该替人干活，而不是让人替工具干活。

这次访谈覆盖了他在 JetBrains 十多年的经历，以及对开发者体验、语言设计和 IDE 未来走向的看法。以下是几个值得深挖的点。

工具的"隐形"才是好工具

Hadi 反复强调一个判断标准：最好的开发工具是你几乎感觉不到它在工作的工具。IntelliJ IDEA 的自动补全、实时分析、重构建议——这些功能的价值不在于它们"炫"，而在于它们减少了你离开键盘去查文档、去手动排查错误的次数。

这个理念延伸到 JetBrains 全线产品：Kotlin 的设计初衷就是消除 Java 中那些让开发者反复写样板代码的痛点；Space（JetBrains 的团队协作平台）试图把 CI/CD、代码审查、文档管理整合到一个不需要频繁切换上下文的环境里。

反面例子更说明问题：一个需要你配置半小时才能跑起来的 lint 工具，即使规则再完善，团队也不会坚持用。工具的采纳率取决于它融入工作流的阻力有多大。

Kotlin 的推广不是"推销语言"

Hadi 在社区里最被人熟知的角色是 Kotlin 的 Evangelist（后来 JetBrains 把这个头衔改成了 Developer Advocate，因为"evangelist"听起来太像传教士）。他在访谈中坦言，Kotlin 早期的推广策略并不是说服大家"换语言"，而是找到那些 Java 真正让人痛苦的场景——空指针、冗长的回调、不可读的 builder 模式——然后展示 Kotlin 在同一个项目里如何逐步替换这些部分。

这种"渐进式采纳"的思路直接体现在 Kotlin 的设计上：与 Java 100% 互操作、同一个项目里可以混写两个语言的文件、Kotlin 标准库直接复用 Java 集合类型。这不是偶然，而是刻意的产品决策。

IDE 插件生态：JetBrains 的隐性护城河

访谈还聊到了 IntelliJ 的插件体系。JetBrains 平台上有超过几千个插件，从数据库工具到 AI 辅助编程，覆盖了几乎所有主流技术栈。Hadi 提到一个关键设计决策：IntelliJ Platform SDK 本身就是用 Kotlin 写的，新插件开发者可以直接用 Kotlin 而不是 Java 来写插件。 这降低了入门门槛，也让插件代码更简洁。

如果你还没写过 IntelliJ 插件，下面是一个最小可运行的示例——它会在编辑器右键菜单里加一个 "Say Hello" 动作，弹出通知。

实践：写一个最小的 IntelliJ 插件

先创建项目结构：

mkdir hello-intellij-plugin && cd hello-intellij-plugin

build.gradle.kts：

plugins {
    id("org.jetbrains.intellij") version "1.17.0"
    kotlin("jvm") version "1.9.22"
}

group = "com.example"
version = "1.0"

repositories {
    mavenCentral()
}

intellij {
    version.set("2023.3")
    type.set("IC") // IntelliJ IDEA Community Edition
}

tasks {
    patchPluginXml {
        sinceBuild.set("233")
        untilBuild.set("241.*")
    }
}

src/main/kotlin/com/example/SayHelloAction.kt：

package com.example

import com.intellij.openapi.actionSystem.AnAction
import com.intellij.openapi.actionSystem.AnActionEvent
import com.intellij.openapi.ui.Messages

class SayHelloAction : AnAction("Say Hello") {
    override fun actionPerformed(e: AnActionEvent) {
        val project = e.project ?: return
        Messages.showMessageDialog(
            project,
            "Hello from your first IntelliJ plugin!",
            "Greeting",
            Messages.getInformationIcon()
        )
    }

    override fun update(e: AnActionEvent) {
        e.presentation.isEnabledAndVisible = e.project != null
    }
}

src/main/resources/META-INF/plugin.xml：

<idea-plugin>
    <id>com.example.hello</id>
    <name>Hello Plugin</name>
    <version>1.0</version>
    <description>A minimal demo plugin</description>

    <actions>
        <action id="SayHello" class="com.example.SayHelloAction" text="Say Hello">
            <add-to-group group-id="EditorPopupMenu" anchor="last"/>
        </action>
    </actions>
</idea-plugin>

运行插件沙盒 IDE：

./gradlew runIde

Gradle 会下载一个 Community Edition 的 IntelliJ 实例并加载你的插件。打开任意项目，在编辑器里右键，就能看到 "Say Hello" 菜单项。点击后会弹出对话框。

改造方向：把 Messages.showMessageDialog 替换成真正的代码分析逻辑——比如扫描当前文件里所有 TODO 注释并汇总显示，你就得到了一个有实际用途的插件骨架。

采纳建议与权衡

从这次访谈可以提炼出几条对团队有用的判断框架：

最后一点值得多说几句。Hadi 在多个场合提到，Kotlin 编译器团队花大量精力在优化编译速度和运行时性能上，但语言层面的设计选择始终把"人读起来是否清楚"放在"跑起来是否快"前面。这不是忽视性能——而是认为性能问题应该由工具链（编译器、 profiler、JIT）来解决，不该让每个开发者手动写晦涩的"优化代码"来承担。

这个哲学和 Spring Boot 的立场其实高度一致：框架替你处理 boilerplate 和运行时调优，你只写业务逻辑。两个生态的对话，本质上是在同一套价值观下讨论不同层面的实现路径。