業務アプリで malloc() のアルゴリズムを実装する羽目になるとは思わなかった話
釣りタイトルだけど嘘は言ってない。
DBから連続的な番号をN個取る処理は考え方としては malloc() と同じだと気付いて Twitter でアレコレ考えたのをまとめた。
要点だけ言うと、
- 連続的な番号をN個取得し、それを ID として貸し出す処理は(考え方としては)malloc() と同じ
- チーム開発で高度な技術を使ったら負け(誇張あり)
- 飲酒は程々にしましょう
あるシステムで連番をN個(1,2,3とか4,5とか)取得する要件があって、これ malloc() を実装しろって言ってるのと一緒や、って気付いてしまった…
— tyru (@_tyru_) 2016年9月6日
ちなみに連番は予約番号といって、貸し出した連番はは他の人は使えないので本当に malloc() と要件は同じ。
— tyru (@_tyru_) 2016年9月6日
一つ分の領域(番号)を貸し出すだけなら業務アプリにありふれた処理だし色々実装が簡単になるのに、2つ以上になると複雑になるの面白いな。まぁ足りなくなったら prefix つける(sbrk(1)ぽい)とか色々安易な逃げ道はある訳だけど
— tyru (@_tyru_) 2016年9月6日
領域が足りなくなったら prefix つける、の他にどんな実装が考えられるだろうか?
— tyru (@_tyru_) 2016年9月6日
しかしこれ設計段階の今気付いて良かった…型を数値から文字列に変えるとかするなら色々影響出そうだしなぁ
— tyru (@_tyru_) 2016年9月6日
とりあえず malloc() によくありがちな free した領域を list に突っ込む、は DB が対象なのでやりにくい… 永続化すると検索する分計算時間増えたりテーブル定義変更とかしないといけないけどそれは避けたい
— tyru (@_tyru_) 2016年9月6日
まぁそこまで考えるか、って話だけど。あれは最適化のためのテクニックだし、とりあえず要件満たす分にはもっとシンプルでいいんだよな(最初言った文字列にする案とか)
— tyru (@_tyru_) 2016年9月6日
テーブル定義を全く変えず、数値のまま実装するなら、せめてサイズによって領域を区切った方がいいと思う(ハッシュみたいな感じ)。そうでないと3つ分の番号が必要なのに2つしか空いてなくて再検索…とかが頻発すると計算時間どんどん増えていく。それも運用開始後随分経ってから発覚する設計ミス。
— tyru (@_tyru_) 2016年9月6日
まぁそもそも肝心の「それ本当に必要なの?」っていう所の理由を聞いてないから、もっと要件聞かないとダメだな。これは情報連携とかじゃなく俺が悪い。
— tyru (@_tyru_) 2016年9月6日
言い訳としては、そんなに仕様確認する時間もなかったってのもあるけど!!1
— tyru (@_tyru_) 2016年9月6日
要件ちゃんと聞かないと独り善がりな実装して「一方ロシアは」状態に陥る。正直高度な技術使ったらチーム開発では負け、と自分は思ってる。もちろん必要に応じてそれができるだけの能力を持っておくに越したことはないけど。大抵それが必要とされる事はない。
— tyru (@_tyru_) 2016年9月6日
ナイーブな実装こそが正義(は言い過ぎか)
— tyru (@_tyru_) 2016年9月6日
ただそうやって適当な落とし所を早すぎる段階で探る癖が付いてしまうとそれも思考停止だと思う。拘りを無くしても負け。難しい。
— tyru (@_tyru_) 2016年9月6日
つまりこれって、「あともう一歩」っていうのを考えなくなったら終わりだよ、って事なんだよな。その観点が仕様面か実装面かの違いはあるけど。思考停止だけはしないっていうのはいつも思ってる事で、エンジニアは考える事が仕事なんだから、思考停止は職務放棄と同義。
— tyru (@_tyru_) 2016年9月6日
そう、正にこれと言ってる事は同じなんだよな。 https://t.co/pAywcYCb9p これめっちゃ共感したのよ。独り善がりになりがちだった自戒も込めてなんだけど。
— tyru (@_tyru_) 2016年9月6日
とりあえずこれの結論としては、テーブル定義の型を変えられるなら文字列型でも配列でも何でも返せるので、修正は容易(今なら大丈夫だろうし影響範囲もそんなでかくないはず)。
— tyru (@_tyru_) 2016年9月6日