giftee Tech Blog

ギフティの開発を支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信しています。

Ruby Kaigi 2019 Day2 参加レポート!

giftee の大谷です。前回に引き続いて Ruby Kaigi 2019 の Day2 の様子やセッションの内容を振り返ります!この日も興味深いセッションが沢山ありましたが、個人的に気になった Day2 Opening Keynote から、簡単な内容の紹介と感想を書きたいと思います。(Stripe の Sorbet はすごくワクワクしました)

All bugfixes are incompatibilities (@nagachika)

セッションの概要

  • CRuby のいわゆる stable version のメンテナーの方々が、日々何を考えてどのようにメンテナンスされているかというお話でした。

stable branch における bugfix の流れ

ざっくりとは以下のような流れで bugfix がなされ、1 つの stable version につき 1 名のメンテナーの方が付くそうです。

  1. trunk(いわゆる develop)のブランチに機能追加や bugfix のコミットが積まれていく。
  2. それらのコミットを見て、「bugfix のコミットだけ」stable brunch に取り込んで(backport して)いく。

この「コミットを見て stable brunch に取り込んでいく」作業ですが、ここの判断がメンテナーに任されているため難しいようです。

苦労すること

それ以外にも以下のようなことで苦労されているようでした。

  • コミットが常にキレイに分かれているとは限らない
  • bugfix が別のバグを生むこともよくある
    • 場合によってはパーサーの修正を迫られることもある(魔境)

bugfix によって意図しない挙動を他の部分で引き起こすようなケースの場合は、既存のアプリケーションへのインパクトの大きさによって bugfix するか考えているので、実際はほとんど使ってない機能のバグは(修正による副作用が大きければ)あえて直さないという判断をすることもあるそうです。

感想

普段あまり意識せずに使っている Ruby のバージョンを日々守ってくれているメンテナーの方々の苦労が実感できました(1 時間強のセッションでしたのでメンテナーの方々が日々実践されていることから比べると本当に垣間見えた、というレベルだとは思いますが…)。

また、Keynote Session としてこういった安定版のメンテナンスに関わる話が聞けたのが良かったと思いました。ついつい機能拡張のような華々しい話に興味が向きがちですが、今回のセッションを通して、我々が安心して Ruby が使えるのは粛々とメンテナンスをしてくれている方々のお陰だと強く実感しました。

そして、今回のセッションのタイトルにもありますが、Rubykaigi 全体を通して「Ruby は後方互換性を非常に重視している」のかなぁと思いました。「新機能の追加によって既存の機能に影響がある場合、後方互換性を切ってまで新機能を追加することは積極的にはしない」といった発言も見受けられました。この方向性に関しては 3 日目の"Ruby Committers vs the World"でも質問に上がりましたのでここでの言及は避けますが、Ruby という言語の人口と影響力を表しているのかなと思いました。