minifyや難読化されたコードのデバッグする方法
背景
本番環境用の成果物に不具合が発生した際、その問題を特定するためにはminify化されていないコードを利用する必要がある。 これを再生成するためにビルドし直す必要が出てくる。トラブルシュートにかかる時間を削減するためにどうすればよいか考える。
まとめ
minify
したコードと、そうでないコードを配置する- Charlesを本番の通信環境で非圧縮コードを利用して不具合を再現する
原因
minify
されたコードしかない- 非圧縮コードの生成のための再ビルドに時間がかかる
- 本番環境でしか不具合が発生しない
対策
minify
されたコードと同時に非圧縮のコードを成果物に含めて保存する。- 成果物がすぐに起動、ホスティングできる状態にする
- 本番環境でしか再現しないものは
Charles
を利用してアセットを置き換えデバッグする
対策の動機
- 成果物が圧縮と非圧縮の状態をすぐに置換できることでトラブルシューティングの時間を下げる
- ビルド時間よりもトラブルシューティングの時間を短くするほうが重要になる
- ビルドは並列化できるが、トラブルシューティングのたびにビルドを回すのは時間の無駄になる
Charles
と組み合わせることでデバッグの効率が上がる
導入方法
- 圧縮・非圧縮のコード両方を成果物として含め、ライブラリやGitHub Releaseなどで管理する
Charles
の使い方をまとめておく- トラブルシューティングの方法をまとめる
継続方法(運用)
- ビルドフローに入れる
対策の問題点
- 圧縮・非圧縮コードの両方を生成するため、ビルド時間が増える
展望
- ビルドの並列化