みなさん、開発する時はエディタを使うと思います。
エディタといっても VS Code, JetBrains 系 など色々ありますが、今回の話題は Zed という Rust 製のエディタです。
エディタというと関数の引数や構造体のフィールドのヒントがその場で出てくると思います。今の Zed でも当たり前のように出てくると思います。
実はこれ、僕が作りました！！！！😎
こんにちは、kubell でプロダクト開発をしている tomoikey です。
今回は Rust 製の OSS エディタ Zed に引数ヒントポップアップを実装する PR を送り、最終的にマージされるまでの話を書きます。
PR はこちらです (https://github.com/zed-industries/zed/pull/12909)
そもそものきっかけ
この PR は Zed をインストールした直後の出来事が発端でした。
「あれれ、関数の引数に何を入れたら良いかを示すポップアップがないぞ」と。
VS Code や JetBrains 系では当たり前のように引数のヒントを出してくれますね。非常に便利で、開発する上では絶対に外せない機能だと思います。
そこで気になってよくよく調べてみると、なんとどうやら Zed には引数のヒントを出す機能がまだなかったのです。
同じ疑問を抱える人たちによって #5155 と #4879 の2つの Issue が既に立っていました。
というのも Zed は絶賛開発中！！！の OSS だったので、さまざまな機能が未実装というかなりホットな状態でした。 ですが Rust で作られているというのもあり、非常に軽量でサクサク動作するというのが魅力で、かなりの注目を集めているエディターでした。
そうなると需要は明確で、あとは誰かが実装するだけという状態でした。
その時僕の頭をふとよぎりました。「俺が直してヒーローになってやるぞ...!!」と。
早速実装！！
僕の実装目標は「Zed のローカル環境で Language Server を叩けるようにして、関数の引数ヒントのポップアップがイイカンジに出るようにする」です。
「Language Server のレスポンスを受けてポップオーバーを出すだけ」と言えばそれまでなんですが、実際には表示タイミング・閉じる条件・設定との連携など、UX まわりの設計の決断が思ったよりたくさんありました。
例えば、引数ヒント表示のトリガーに関する UX についてです。
キーボードショートカットで手動的に呼び出せるようにしたり、「(」や「)」を跨いだ時に自動で引数ヒントを出すといったような細かい配慮の部分です。
加えて、関数名の補完を確定した直後に引数ヒントが出すようにするといったような配慮も求められました。
また自動でトリガーする部分に関してはユーザごとに好みが分かれるので設定からいじれるような口を用意する必要がありました。
大まかにやることは明確だったのだが...
なんとなんと総じて96コミット...!!! これがこの PR のマージまでの規模感です。(僕の実装力の問題もありましたが... ^^;)
過去に他の OSS で小さなコントリビューションはしたことがあったものの、これほどの規模の OSS に対しては初めてだったので、コーディングスタイル・エラーハンドリング・テストの書き方・OSS 特有の文化理解など、Zed 固有の作法を一つひとつ学びながら修正を重ねました。
特に記憶に残っているのは「UX 周りの議論」です。
PR を出したのが2024年6月11日で、マージされたのが2024年7月11日。ちょうど1ヶ月です。
正直、動くものを作るだけなら数日でできていました。Claude のようなコーディングエージェントがある現代なら数時間でできると思います。
ですが、一番時間がかかったのがコミュニケーションの部分でした。
レビュー・修正・再レビューを繰り返す中で、精神的に辛くなる場面も所々ありました。
ただ、このサイクルを繰り返す中で「開発は技術そのものより、会話による協調である」という感覚を強く持つようになりました。
1ヶ月にわたるやりとりの末に最終的な承認をもらったときのマージ通知は、飛び跳ねるくらいには嬉しかったです。
弊社のバリューの一つである「Take Ownership」を発揮した瞬間とも言えるでしょう。
最終的には大量のリアクションがついており、晴れて「ヒーロー」になりました😎
パソコンのキーボードを叩くだけで誰でもヒーローになれる時代なんだと。
「やりきってよかったな〜」と喜びの気持ちをひしひしと噛み締めまくりました。
まとめ
Zed は GitHub のスター数が 77,000 を超える大人気の OSS です。そこにコントリビューションするのは、技術的な難しさよりもコミュニケーションが重要だと感じました。
- 明確な意図を持ってスコープを絞り、レビュアーの負荷を下げる
- 動作確認手順を丁寧に書く
- フィードバックにすぐ反応する
- 設計の意図をコメントに言語化して残す
こうした進め方が、最終的にマージされるかどうかを大きく左右します。
コードを書いて PR を出すだけでなく、「PR を通す」コミュニケーションのスキルも OSS コントリビューションには必要だと実感しました。
最後に
kubell ではバックエンドエンジニアを積極的に募集しています。OSS 活動に興味がある方、GraphQL を使った開発に興味がある方、ぜひ一緒に働きましょう！ www.kubell.com
