開発記
公開後に出た問題が、どれもコードのバグではなかった
アプリを公開したあとに出た問題が6件あって、そのどれもがコードのバグではありませんでした。 設定・メタデータ・出荷物の中身が、想定と食い違っていたのです。テストは全部通っていました。
テストが見ていない層がある
単体テストが見ているのは、書いたコードのふるまいです。ビルドして出てきた成果物の中身は見ていません。
- 開発中のテスト用の値が、出荷するバイナリに混ざっていないか
- 本番用の値が、ちゃんと入っているか
- 本体と拡張で、版番号や言語の設定が揃っているか
- 申告した内容と、実際の設定が一致しているか
どれも「コードは正しいが、出来上がったものが違う」という形で壊れます。壊れていても動きます。 だから気づけません。
一度、手で全部見た
提出の前に、実物と突き合わせる形で一通り監査しました。結果として、確認した範囲では次のものは混ざっていませんでした。
- テスト用の広告ID
- 開発中のローカルアドレス
- 認証のデバッグ用トークン
- スクリーンショット撮影用のモード
デバッグ用のコードが Release で無効になっていることも、プライバシー関連の申告 23件が実装と合っていることも確認しました。それとは別に、直すべきものが3件見つかりました。
この監査に半日かかりました。そして、次のリリースでもう一度同じことをやるのだと気づきました。
手でやったことを、そのままスクリプトにした
手順を思い出しながらやるのは続きません。提出用の成果物に対して1コマンドで回せる検査を書きました。中身は、今回手でやったことをそのまま並べただけです。
1つだけ工夫が要りました。開発中のローカルアドレスを素の文字列で探すと、ネットワーク層のコードに必ず引っかかります。 常に違反が出る検査は、すぐに無視されるようになります。URL の形で見るようにして、誤検出をゼロにしました。
いまは提出前にこれを回して、適合31件・違反0件を確認してから出しています。
検査は、通ったことより「無視されないこと」が大事
誤検出が混じる検査は、回すたびに「これはいつものやつ」と読み飛ばされます。そうなるとあっても無いのと同じです。
項目を増やすより、出た違反が全部本物であることのほうを優先しました。
公開中Resuruマッチングアプリの返信文を、AIが3案とアドバイスで提案します。