この記事は、ラクス Advent Calendar（その2） の2日目です。昨日は、 @soachr の アラサーの私がようやくアウトプットすることに肯定的になった理由 でした。
はじめに
新しいプログラミング言語を覚えるためのコードや、何かを実験するための検証用コードなど、仕事・プライベートを問わず、本番用ではないちょっとしたコードを書くことは多いですよね。こういったコード、どうしてますか？
書き捨てにするのが一番ラクだけど、使いまわしたいコードが行方不明になりがち。ちゃんとしたプロジェクト名をつけてGitリポジトリで管理すると、今度は雑なコードや途中のコードをコミットしづらくなってしまう。ちょうどその中間ぐらいを目指して、sandboxリポジトリに行き着きました。
sandboxリポジトリ
トピックごとに 〇〇-sandbox という名前の使い捨てリポジトリを作ります。ここでの「sandbox」は、セキュリティ界隈で隔離された環境を指す sandbox ではなく、自由に試せる砂場の方の sandbox です。ローカルに残っているのを見てみたら、gitlab-ci-sandbox とか postgres-sandbox とか mattermost-sandbox とか react-sandbox とか java-sandbox とかとか、過去にいろいろ作っているようです。
実際には、このリポジトリの下にサブディレクトリを切って、その下に作業途中のファイルなどを雑にコミットしています。日をあけて違うことを試したり、違うバージョンで検証したりするときに、複数プロジェクトを配置できるようにしておいた方が便利だからです。
ちなみに postgres-sandbox の下を覗いてみましたが、普通に docker compose up できない状態でコミットコメントが WIP だけのものとか混ざってました。いい感じに雑いです 
postgres-sandbox/
├── README.md
├── alter-column-int-to-bigint
│ ├── docker-compose.yml
│ └── init.sql
├── citus
│ ├── ads.csv
│ ├── campaigns.csv
│ ├── companies.csv
│ ├── docker-compose.yml
│ └── init.sql
├── ...
所感
- メリット
- 「どうせsandboxだし…」と気軽にWIPのまま一時コミットできる。最悪別ブランチにつっこんでおく手もある
- 過去のコードをコピペで再利用しやすい。最近は、docker-compose.yml の再利用率が異常に高い気がする
- デメリット
- あまりに雑なコードばかりだと再利用しようにも再利用できないので、書き捨てにするのと実はさほど変わらない可能性がある。ほどほどが大事、ほどほどが
sandboxリポジトリ、お試しあれ！
蛇足
社内のとあるエンジニアが軽いノリで作った初の「カレンダー2」。裏番組的な感じなのか今まで以上にゆるふわで、完走できる気がしないです。そして、カレンダー1, 2の初日をダブルでかざるエンジニア。ぶっ飛んでますね。せっかくなので続いておきました。
🇯🇵 🇪🇸