やかんです。機能に引き続きこちらも「言語化」の一環としての日記です。
背景
大学2年時よりお世話になっている方から、開発の依頼をいただきました。本当にありがたい限りです。。
11月から開発を進めているのですが、ちょうど今月はハッカソンにチームで参加したり大学の授業がえぐかったりで稼働率がよくないんですよね。。申し訳ないです。
ハッカソンはチームメンバーがエグすぎて見事特別賞受賞しました
予約はやはりむずい
エンジニアあるある話ですが、やはり予約は実装が難しいですね。
- 予約枠
- スタッフの予約可能枠
- お客さんの予約
の3者が登場します。予約枠は、たとえばヘアサロンの場合だとその枠で稼働できるスタッフの方が十分数存在する場合に「予約可能」となります。そしてそこに予約が入ると、稼働可能なスタッフ数との兼ね合いで「これ以上予約受けられない」となれば、「予約不可能」となるわけです。
これだけでもまあまあ複雑じゃねって思うんですけど、「計算量」とか考え始めるともっと面倒なことになります。「考え始めると」というか、絶対考えないといけない話なのですが。
解析の文脈で登場する「計算量」よりももっと緩い考えです、どれくらい演算が大変かなっていう尺度的な。
例えば、予約枠1つについて、「稼働可能かどうか」を判定すべきスタッフが100人いるとします。
1つの枠について100人ですが、通常、例えばヘアサロンであれば10枠くらいありそうですよね（テキトー）。仮に1日に10枠だとしたら、100人かける10枠で、事実上1000人について「稼働可能か」を判定する必要があります。さらに、これが1週間分の話になってくると、1000かける7で、すごい雑ですが7000回演算する必要があります。
これに加え、「既存で予約が何件入っているか」まで考え始めると、「既存で入っている予約」の数分演算も考慮する必要が生じるので大変面倒なことになるわけです。
じゃあ、どうすればいいか。
予約について、皆様のスマホあるいはパソコンが超高性能であればまあある程度サボってもそれなりに動くとは思うんですけど、現実はそうじゃないです。
多分、予約については「予約枠」と「その予約枠が、予約可能かどうか」を1対1に対応づけるのが解として優秀なんじゃないかなと思っています。
つまり、1つの予約枠について、そこが予約可能かどうかを判定するために先の例だと「スタッフの稼働状況」「既存の予約状況」について演算を回すことで判定を行っていました。
これだと計算が「重い」ので、もう「予約枠」に直接「その予約枠が予約可能かどうか」を情報として持たせてしまおうという考えですね。こうすれば、演算が不要になります。
ただまあ、妥協に妥協を重ねた結果ではありますよねー、僕がNoSQLで実装してるから予約と相性悪いという話もありそうです。ただ、とりあえず「当面正しく動くことが目標」ではあるので、これで行こうと思います。
な感じの日記でした。以上です！引き続き開発を頑張ります。
最後までお読みいただき、ありがとうございます。
