隙間家具OSS開発で『自分の庭』をつくる 2023.12.04 カヤック・アンドパッド 合同 プロポーザル供養会 @fujiwara 藤原俊一郎

@fujiwara (X(Twitter), GitHub, Bluesky) 面白法人カヤック SREチーム ISUCON 優勝 4回 ISUCON 運営(出題) 4回 最近の趣味: OSS、ランニング (2023/11/05 フルマラソン 3:28:33)

隙間家具OSS 初出 吉祥寺.pm 16 (2018.11) AWS Dev Day 2019でも発表 ("隙間家具 speakerdeck"で検索)

隙間家具OSSとは マネージドサービス、コンポーネントの隙間を埋めて便利にするもの マネージドサービスが時間とともに成長して不要になったら取り外す(ことも念頭に)

Glueではなく隙間家具(単体のソフトウェア)にする理由 Glueなコードはプロジェクト固有の事情に密結合しがち あるプロジェクトのリポジトリの中に置かれる コードの責任分界点が曖昧 他のプロジェクトにコピペ(fork)されがち → 固有の事情(コピペ先の事情)によって改変されてだんだん別物に あるプロジェクトで行われたバグ修正が行き渡らない

単体ソフトウェア/ライブラリとしてOSSにする 各プロジェクトに依存するコードは入らない(入れられない) 一般的なユースケースに対応できるようにインタフェースが整理される プロジェクト固有の事情と一般的な事情を分離して設計と実装をするようになる bugfixはバージョンアップで適用できる ノウハウも統一できる 複数プロジェクトの運用が楽になる

「自分の庭」をつくる

作って使ってメンテしていくこと 「コードはできるだけ書かない方がよい」 それはそう 「できるだけ既存のツールの組み合わせでなんとかしたい」 それでよい運用ができるならもちろんOK 「このツールだけで全部完結させたい」 (趣味なら好きにすればいいけど仕事では)ひとつのツールに拘りすぎないほうがよい 適切な道具を適切に使う、必要なら道具も自分で作るのがプロフェッショナル

https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition

自分で設計したシステムをメンテする経験 システムをシンプルに作ってシンプルに保つ力は経験で得るしかない ひとつのプロダクトを… 1. 設計して 2. 実装して 3. テストして 4. リリースして 5. 導入して / 既存プロダクトと組み合わせて 6. issue対応やバグfixをして 7. (寿命を終えるところまで) 面倒を見る 大きなシステム、ビジネスのメインプロジェクトでこの経験を積むのは難しい

具体例 ecspresso v1 → v2 2020.10 v1 → 2022.12 v2 新機能を足したりPRを受け入れてコー ドを増やしていくと、どうしても設計/ 実装に歪みが溜まる 本来の責務ではないコードを github.com/fujiwara/ecsta に分離・リファクタ

隙間家具OSSは『自分の庭』 小さいのでいくつも作れる (練習になる) なくても何とかなるけどあると便利 (失敗したら使わなければよい) 成功してもいつか取り外すことも念頭に作る (そのための設計を考える) 使い始めたらメンテはしていく (要望の取捨選択も含めて) コードはできれば書かない方がいい でも、鍛えておかないといざという時にうまく書けない