有限状態マシンの故障から回復する方法は？
私の質問は非常に科学的に思えるかもしれませんが、よくある問題だと思います。経験豊富な開発者やプログラマーは、タイトルで言及した問題を回避するためのアドバイスを希望します。ところで、私が以下で説明するのは、iOSプロジェクトで積極的に解決しようとしている真の問題です。 有限状態マシンとは、これを意味します>いくつかのボタン、そのUIに関連するいくつかのセッション状態、およびこのUIが表すものがあるUIがあり、UIに値が部分的に表示されるデータがあり、いくつかの外部トリガーを受信して処理します（センサーからのコールバックで表されます）。状態図を作成して、そのUIとアプリケーションで望ましい、必要なシナリオをより適切にマップしました。ゆっくりとコードを実装するにつれて、アプリはより適切に動作し始めます。ただし、十分な堅牢性があるとは確信がありません。私の疑問は、自分自身の思考と実装プロセスが進行するのを見ることです。私はすべてをカバーしていると確信していましたが、UIでいくつかのブルートテストを行うだけで十分であり、動作にまだギャップがあることにすぐに気付きました..それらにパッチを適用しました。しかしながら、各コンポーネントは、他のコンポーネントからの入力、ユーザーまたは特定の外部ソースからの特定の入力に基づいて動作し、一連のイベント、状態変更などをトリガーします。複数のコンポーネントがあり、それぞれが入力で受信したトリガーのように動作します->トリガーとその送信者が分析->分析に基づいて何か（メッセージ、状態変化）を出力します 問題は、これは完全に自己完結型ではなく、私のコンポーネント（データベース項目、セッション状態、ボタンの状態）...イベントチェーンの範囲外で変更、影響、削除、またはその他の方法で変更される可能性があることです望ましいシナリオ。（電話がクラッシュし、バッテリーが突然空になります）これにより、システムが無効になり、システムが回復できなくなる可能性があります。アップルストアにある競合他社のアプリの多くで、これが見られます（これは問題だと人々は認識していませんが）、顧客は次のように書きます>「3つのドキュメントを追加しました。たとえそれらを見たとしても。」または「毎日ビデオを録画しましたが、あまりにログの多いビデオを録画した後、それらのキャプションをオフにすることはできません。キャプションのボタンはありません」 これらは単なる短縮例であり、顧客はしばしばそれをより詳細に説明します。それらに記載されている説明と動作から、特定のアプリにFSMの内訳があると思います。 究極の問題は、これをどのように回避でき、システムがそれ自体をブロックするのを防ぐ方法ですか？ 編集>私は電話で1つのviewcontrollerのビューのコンテキストで話している、私はアプリケーションの一部を意味します。MVCパターンを理解し、機能ごとに個別のモジュールを用意しています。説明するものはすべて、UIの1つのキャンバスに関連しています。