これでエラーはすでに修正されました。ストアにはエラーを含まないバージョンがあります。 ユーザーのおかげで問題を非常に迅速に発見し、リリース後数時間以内に、アップデートの配布を停止し、修正を迅速に公開しました。
恥ずかしがり屋ではなく、この状況から学んだ経験を皆さんと共有することにしました。 おそらくこれはあなたが良くなるのに役立ちます。 いつものように、理由は技術的要因と人々の間の不快感の組み合わせでした。 詳細-カットの下。
最初のアクション。 プロローグ。 すべてが完璧にフィット
まず、このバージョンの一般的な新機能について。 Navigatorインターフェースと対話することでドライバーが道路から気を散らさないようにするために、手を使用せずに彼の主要なシナリオを実装することにしました。 これを行うには、音声アクティベーションをアプリケーションに統合する必要がありました。これにより、Yandexコマンドで音声インターフェイスを呼び出すことができます。 また、音声でナビゲーターからの質問を確認または拒否できるようにするため。 たとえば、ルートを再構築するとき。
Yandexには独自のSpeechKit認識技術があり、Navigatorで既に使用されています。 しかし、以前は、アプリケーションはボタンをクリックした後にのみコマンドを理解することができました（たとえば、ルートを作成したり、組織の地図や住所を検索したり）。 新しいバージョンには、音声のアクティブ化と確認に必要な機能があります。
Navigatorは、音声認識バージョンが使用された最大かつ最も深刻なアプリケーションでした。 当然、彼との統合の過程で、ライブラリ自体が開発および改善されました。 そして、もちろん、これはライブラリのデバッグバージョンを使用した多くの反復で発生しました。 これが混乱の始まりです。
2番目のアクション。 混乱があります
目的の結果に近づいたとき、SpeechKitの最終バージョンでNaviを収集し（チーム内でアプリケーションを呼び出すため）、リリースの確認を開始しました。 テストは順調に進み、開始する準備が整いました。
最終テストが終了するとき、ライブラリの最新バージョンが大量のログを書き込んでいることがわかり、何かが疑われました。 誤ってデバッグバージョンを再度使用したことが判明しました。 あまり時間はありませんでしたが、ライブラリのリリースバージョンがデバッグバージョンとあまり変わらないことを望み、詳細なテストをせずにNavigatorをビルドしようとしました。 悲しいかな、アプリケーションは落ち始めました。
3番目のアクション。 すべてがうまくいかず、急いでいます
ルート確認コマンドの認識を担当するライブラリでクラッシュが発生しました。 その中で、音声処理は並列で実行され、並列コードと速度の記述の便宜のために、異なるプラットフォーム依存の実装を持つプリミティブ関数の小さなセットが使用されます。 ライブラリによって作成された、またはライブラリが初期化された各スレッドでは、一部のデータ（メモリプールなど）が関連付けられているため、それらを初期化する必要があります。 この初期化が実行されなかったスレッドからライブラリにアクセスしようとすると、クラッシュが発生したため、単一のスレッドからライブラリを操作する必要がありました。 残念ながら、この条件はエラーのために満たされない場合がありました。
エラーを修正するのは比較的簡単でしたが、新しいバージョンでテストする時間が残っていなかったため、デバッグにロールバックして開始することにしました。
4番目のアクション。 ファカップ・ハービンジャー
予定された打ち上げ時刻までに残っている時間はほとんどありませんでした。 次のリリースはすでに準備ができていて、私はそれを引っ張りたくありませんでした。 同時に、非バイアスバージョンでアプリケーションをテストするために多くの労力を費やしました。その結果、認識が機能することが明らかになり、唯一の欠点はすべてが少し遅くなることです。 リリースバージョンの修正は簡単なものでしたが、Naviへの追加により、新しいテストプロセスと、新しいバグを検出する可能性があるため、不明な期間による期限の変更が約束されました。
しかし、デバッグバージョンには独自の特性がありました。 私たちは彼女がエラーのログを書いたことを知っていましたが、これは彼女のもう一つの小さな利点でした。彼女は最初の起動で失敗に関する情報を収集することができたからです。 しかし、ログがすべてではありません。 最大の品質を達成するには、大量のテストデータが不可欠です。 たとえば、サウンドのログを取得するには、ライブラリがコマンドを認識できなかった時期を理解する必要があります。
このような録音の別の可能性は、当社の従業員がナビゲーターの特別なアセンブリで移動し、音声技術を訓練するために実際の条件でテスト環境を収集できるように行われました。 したがって、デバッグバージョンでは、サウンドはsdカードに記録されていました。 このロジックは、define'amiによってコードに組み込まれ、リリースアセンブリでは無効化されました。 ストーリー内で無効にする必要がありましたが、いいえ-このマクロが定義されたヘッダーファイルはスキップされました。
5番目のアクション。 ファカプ
当然のことながら、この機能は計画されていないため、テスト計画ではデバイス上のサウンドの録音とそのストレージについては説明していませんでした。 アプリケーションがバックグラウンドから呼び出されるたびにファイルが書き換えられるため、テスト中にアプリケーションのサイズにわずかな変化が見られることはありませんでしたが、サンプルが目立った値に成長することはありませんでした。
しかし、移動の過程で、ナビゲーターセッションが十分に長い時間停止しないと、サンプルがいくつかのギグに成長する可能性があります。 そして、ユーザーは起動後数時間でこれに気付きました。 この時点で、プロダクションが内部テスト専用に使用される予定の誤ったコードを取得したことが明らかになりました。
アクション6。 結果と後悔
結果はすでに新聞に掲載されています： www.vedomosti.ru/newspaper/articles/2015/09/08/608063-tainii-navigator-yandeksa
個別の小さなエラーと仮定の結果として、深刻な問題が発生しました。これにより、一部の人々は、ナビゲーターやYandex全体に対する信頼を失いました。 私たち全員と私は、この問題の影響を受けたすべての人々に個人的に謝罪します。
私たち自身が状況を詳細に分析し、同様のことが二度と起こらないように必要な行動計画を書きます。 これは、航空のように血ではなく、人々の信頼と評判を失う痛みを伴う最終規則が書かれた場合に当てはまります。 ここでは計画を述べません。誰もが状況から結論を引き出すことができると思います。