こんばんは〜。
いやー、最近、脳内デバッグが多くて、ずっとモヤモヤしてました。

特に、今週は、箱庭コンダクターという最後の機能設計で、
丸一週間かけていました。

その最後の設計は、あの Runtime Delegation です。
詳細は、別途、技術ブログとしてあげますので、
ここでは省略しますが、

「本当に、こいつ、むずい！」

もう。毎日、ヘトヘトです。

なにがむずかしいの？

実は、この機能、
１月の最初の時点で、
概念レベルでやれる範囲では、
すでに整理はできていました。

でもね。

だめなんです、

「それだけじゃー、よ〜。」

Runtime Delegation は、
箱庭コンダクタの中でも、
PDUの最上位にある機能です。

「こうしたい」という机上の設計だけでは足りなくて、

・どの情報を 
・どの粒度で 
・どのタイミングで 
・誰が持つのか  

その“武器の一覧”が見えないと、
実装できるかどうかの判断ができません。

とくに Runtime Delegation は、
とてもデリケートな機能です。

アトミックにやらなければならないところ、
不変条件をちゃんと成り立たせられるかどうか。

それは、
下位機能が
「具体的にどう作られているか」
が見えないと、読めない。

だから、止まる。設計図は描けているのに、
工具箱の中身が見えない、
そんな感じでした。

いつもハラハラしてる感じ。

むかし、ファイルシステムの開発をしていた頃、
めちゃくちゃ大変でした。
なにが難しいかというと、

・マルチスレッド、
・マルチCPU、
・排他やデッドロックの問題、
・フェイルオーバー→リカバリ後のデータ整合性、
・性能問題などなど。

それらを同時に考えながら、
「最適なコードは何か」
を決める。

若い頃に、そんなことをやっていて、
もうねー、あのハラハラ感に、すごく近いです。

で、
自分なりに答えを作って、
設計的な妥当性は、いったん置いておいて、
プロト実装をやる。

めっちゃ負荷をかけたり、
意地悪なテストをやりまくる。

そこまでやって、
はじめて、
設計の妥当性を、見るんです。

いわゆる、
　実装で殴ってから、設計を見る
ってやつですね。

抽象論はあまり得意じゃない

今でこそ、モデリングとかもやっておりますが。
（いや、大事なんですよ。わかってます。）

でもね、
ちゃんと現場で動くものは、実装なんだと思います。

実装がないのに、
「モデリングしましたー」
って言われると、
「それ、ちゃんと動くんけ？」
って言いたくなる。（福井弁で）

完全に、
工事現場のおっちゃんですわ。

だから、実装に舵を切った。

昔は
「実装しないと、わからないの？」
って、よく言われました。

でも、今だからわかります。
それは、
　・決まったパターンや、
　・単純なシステムの場合は、
っていう条件があるときだけなんですよ。

シングルスレッドで、素直に動くものなら、
　モデリング → 実装は、
きれいにはまる。

でも、
　Runtime Delegation は、
そういう世界じゃない。

机上だけで、
考えきれる気がしなかった。

だから、
下周りから先に作ろうって、
決めました。

半月くらいかけて、
・箱庭PDU-Endpoint、
・箱庭PDU-Bridge、
・箱庭PDU-RPC、
・箱庭コンダクタ。

一通り、実装して、ひたすらデバッグ。

デバッグ地獄も、一週間やりました。

で、
ようやく、
武器が揃ったわけです。

ほらみたことか。

これがすべてです。

(箱庭ラボDev slackでのぼやきです)

もう３１回も書き換えている設計資料がやっと実装レベルから見直して、まとまりました。
この瞬間、ぼくのモヤが晴れました。

いやー、ほんとに見事にすべてのパズルが繋がりました。
これこそが設計の醍醐味ですよ。

来週から実装やりまーす。

おしまい。

音声解説：