前回は信頼の土台の話でした。今日は、開発の現場の話です。この連載で何度か書いてきた「うまくいったように見えるもの」の話でもあります。
開かない PDF
STIL.HUB には、Mac のフォルダを iPhone から辿って、ファイルを Mac 側で開く機能があります(ブラウズと呼んでいます)。手元でファイル名を押すと、Mac の画面でそれが開く。
実機で試していたとき、PDF が開きませんでした。何度押しても、Mac の画面は無反応。ところが、相棒(Companion)のログを見ると、記録は全部こうなっています。
「開く要求を実行 → ok」
ok。でも、開いていない。ログと画面が、まっすぐ食い違っていました。
「ok」の正体
まず疑ったのは、自分のコードの ok でした。調べると、嫌なものが出てきました。ファイルを開く処理は、OS に「これを開いてください」と依頼して、依頼の結果を見ずに ok と記録していたのです。返事を確認しない伝言係が、「伝えました」とだけ報告していた。ok は「開いた」ではなく、「言った」の意味でしかありませんでした。
では、依頼はどこへ消えたのか。
十四日間の、居眠り
Mac の中を見ていくと、犯人がいました。PDF を開く役の標準アプリが、十四日間、起動しっぱなしになっていて、応答できない状態で固まっていたのです。ウィンドウの一覧を調べると、そのアプリが持っていたのは、高さ 39 ピクセルの、潰れたウィンドウの残骸が四枚だけ。OS は「開いてほしい」という依頼を受理して、この居眠り中のアプリに渡し、依頼はそこで闇に消えていました。
アプリを再起動すると、PDF は、何事もなかったように開きました。十四日ぶりに起こされた居眠りが、直接の犯人でした。
でも、反省は「ok」の側に
犯人は見つかりました。でも、直すべきは Mac の再起動ではありません。居眠りは、また起きるからです。私が直せるのは、こちら側 ── ok の作りのほうでした。
ファイルを開く処理を、結果が返ってくる形の API に切り替えました。開けたら開けた、失敗したら失敗と、理由つきで返ってくる。そして、その失敗を、Mac の中のログに沈めず、iPhone の画面まで運んで表示するようにしました。押した人が見ているのは手元の画面なので、知らせはそこに届かないと意味がありません。
沈黙の成功は、検証にならない
いちばんの反省は、この機能を作ったとき、「開くことを確認した」と記録していたことです。あの確認で見ていたのは、無条件の ok でした。つまり、何も検証していなかった。うまくいったように見えるものと、うまくいったことが証明されているものは、別物です。
レシートのときに、実機で出たバグをテストにすると書きました。今回の学びは、その手前にあります。結果を返してくれる API を選べるときは、必ず選ぶ。 返事を見ない伝言係を、仕組みの中に置かない。「ok」は、開いたの証明にならないのです。
次回
こんどは、OS に頼もうとして、頼み方ごと変えた話です。Mac の音声入力を手元から起こそうとして失敗し、最後は「iPhone で話して、Mac で打つ」に辿り着きました。
STIL.HUB は App Store で公開しています。
