Saplingから感じた、エンジニア力

こんにちは、株式会社LabBase（旧POL）でエンジニアをしているミズノです。
この記事は2022年アドベントカレンダー25日目の記事です。
昨日は「KafkaとDeveziumによるMySQLとElasticsearch間のデータ連携」でした。

アドベントカレンダーを毎年続けてますが、25日間埋めるのは簡単ではなく、今年も色々なネタを投稿してくれた皆さんに感謝します。
今年最後の投稿は開発フローと個人的な反省の話です。

開発ではGitを利用するのが一般的かと思いますが、Meta社がOSSで公開したSaplingというコード管理の仕組みを試してみました。

https://sapling-scm.com/

SaplingはGitと互換性のあるコード管理システムです。当初は「Gitのクライアントツールかな？」で使い始めたのですが、Gitのような操作感がありながら、別物でした。いくつか面白い特徴があるので紹介したいと思います。

コマンドが分かりやすい

Saplingでは全体的にコマンドが分かりやすいです。コミットに移動するには「prev」「next」があります。見た目でも何が起きるか理解しやすいと思います。

sl prev
sl prev 2
sl prev --bottom

こんな感じでコミット感の移動が簡単にできるようになっています。このコマンドを見たあたりからもしやあれではと感づかれた方もいると思います。そうです、Sapliingはブランチを切る開発ではありません。もちろんブランチを切ることもできます。（SaplingではBookmarkと呼びます。）
しかしブランチを切る開発は非推奨とされています。

コミットごとのPR自動作成

個人的に一番印象的だったのが、ローカルのコミットごとにPRを自動作成してくれる機能でした。一つのPRの中に、複数の修正コミットを入れてしまった経験は皆さんもあると思います。Saplingでは個別のPRとして簡単に扱えます。なのでこれは機能としてトランクベースの開発を支えているのかもしれません。

Meta社のような巨大な企業では、良い開発体験を生み出すために、Saplingのような内製ツールが生まれたのでしょう。よく考えたらGithub決して使い易くないですからね。（Githubさん期待してます。）

反省文

とSaplingの紹介をしながらエンジニアとして目が曇ってたなと、反省してます。日常的に目の前にあるツールを当たり前のように使うことが増え、狭い視点でしか物事を考えれてなかったなと。

昔とある先生から、

君たちはそのツールの中でものづくりをしてるに過ぎない、
それに気づけてますか？

という厳しい言葉をもらったのを思い出しました。これでは素人システム管理者ではないかと。もうすぐ年末の休み入るので、しっかりコードを書きたいと思います。

来年は玄人管理者になるべく精進します。僕のノートを見るより以下の登さんの熱いReadmeをぜひ読んでください。

https://github.com/dnobori/DN-Win32DiskImagerRenewal

皆さん良いお年を！