悪いコードとアンチパターンが時々決定する方法

Hi%username%!



今日は、このプロジェクトで悪いコードがどのように役立ったかについてお話したいと思います。



猫の下で誰が気にしてください。



私は護衛プロジェクトを継承しました。 誰が書いたのかわかりませんが、この人は今日までしゃっくりしています。 一番下の行は、ストアで写真レポートを収集し、それらをサーバー上の管理者に送信するためのアプリケーションがあるということです。



すべては単純に思えますが、写真を撮るときにアプリケーションがクラッシュすることについて従業員から絶え間ない苦情がありました。 コードの分析により、カメラアプリケーションのインテントを呼び出すと、Androidはリソース不足のためアプリケーションを強制終了し、結果がアクティビティに返されると、アクティビティに再作成され、作業に必要なデータが含まれていないことがわかりました。 アクティビティのレクリエーションは単に処理されませんでした。 はい、configChanges * sarcasm *があります



ステップ1.レクリエーション処理



2日間の苦しみ、コードの修正、繰り返しの断片の破棄の後、テストを開始しました。 私はそれをタスクキラーエミュレータに投げ込み、カメラを起動し、プロセスを殺しました。 フォットカユ-ビューティー!!! すべてが美しい、写真があります。 [保存]をクリックして... ...広い範囲)アプリケーションがクラッシュしました。



ステップ2.シングルトン-Evil Evil



秋の理由は、現在のレポートにデータがないためです。 アプリケーションには奇跡的なシングルトンがあり、すべてが維持されていることがわかりました! アプリケーションが動作するために必要な絶対的にすべての重要なデータなど。 これは認証トークンであり、40のレポートステータスフィールドと、レポートとユーザーのジオデータおよびいくつかのビットマップコレクションを記述するクラスへのリンクです。 瞬時に、失われる可能性のあるものはすべて失われました。



結果は顧客に説明されました。 リファクタリングは歓迎されますが、あまりお金がありませんでした。 同時に、彼らは涙を流して何かをし、松葉杖を指導するように頼みました。



ステップ3.シングルトンを変更する



頭に浮かんだのは、シングルトンを修正して信頼性を高め、同時にインターフェイスがまったく変わらないようにすることだけでした。 次のことが考えられました-SharedPreferensesに押し込められるものはすべてそこに保存されました。

public String getAuthToken() { return getStingFromPref(AUTH_TOKEN); } ..... //   .
      
      







失礼で愚かですが、プロジェクト全体でコードを変更する必要はなく、Singletonはより安定しました(まだ何もしていないビットマップコレクションがあります)。 シリアル化のみが可能なオブジェクトはすべてシリアル化され、SharedPreferencesに詰め込まれました。



アプリケーションはテストに進み、prodで70%のデバイスでクラッシュが停止しました。 残りの部分では、カメラから結果を送信した後、現在のスタックではなく前のアクティビティが再作成されました。 私にとって、これはまだ謎です。 達人-コメントで説明します。

一番下の行は-アクティビティAは結果でアクティビティBを開始します。 アクティビティBは結果を得るためにインテントカメラを起動します。

カメラの操作中にプロセスが強制終了された場合、アクティビティAは写真を作成することで再作成され、BのアクティビティはonCreateまたはonActivityResultのいずれとも呼ばれませんでした。 (PS Android 4.4)



googleとstackowerflowは答えを出さず、別の方法でもっと悪いコードを書かなければなりませんでした。



再作成できない場合は、殺すことを禁じることができると思い、ステップ4に進みました。



ステップ4.最終。 前景ごみ収集車



Androidがプロセスを強制終了しないようにする方法は? 私の考えは次のとおりです。「OSに、商品の写真を撮るのと同じくらいの時間、私たちにとって重要な計算を実行する重要なフォアグラウンドサービスがあることを伝えたら。 間違いなく機能するでしょう。」



そのため、彼はフォアグラウンドのごみ収集車プロジェクトで生まれました。 彼は0から60までのサイクルを運転し、彼の体で1秒間眠りました。 カメラから結果が出るとすぐに、サービスは殺されました。 アプリケーションはコンパイルされ、テスト用に送信されました。

結果-KitKatはよりスマートになり、プロセスを釘付けにしました。 つまり、何も変わっていません。



別の考えが私に起こったとき、私はすでに必死でした:「そして、あなたが愚かにもシングルトンでアクティビティへのリンクを保持し、フォアグラウンドのごみ収集車から直接startActivityForResultを呼び出したら?」 私はそうしなかったし、うまくいけばもう必要ありません。



アプリケーションがコンパイルされ、テストが行​​われます...そして見よ、プロセスは閉じられなくなりました。



結論の代わりに。 顧客は悪いアプリケーションを持っていると警告され、私はそれを悪化させましたが、それは会社の従業員がこれを待っているので機能します。



最後に。 あなたのキャリアにおける「最悪のコード」について教えてください。 お互いを元気づけましょう。



All Articles