フロントエンドにおける「表示系バグのデバッグ効率化」を考えるのに役立つツールやTipsまとめ

フロントエンドにおける「表示系バグのデバッグ効率化」を考えるのに役立つツールやTipsまとめ

いなば

いなば

こんにちは、フロントエンドエンジニアのいなばです。

画面の表示系のデバッグって、面倒で大変ですよね。
今回は、フロントエンドの開発での、表示系のデバッグを効率化するために普段使っているツールや手法をご紹介したいと思います。

便利な検証環境/ツールを用意する

Macで開発している場合、IEでの表示確認を都度実機で確認するのはとても面倒です。また、都度FTPアップしないと修正の確認ができないのも、とても不便です。
まずはそれらを解決するツールを2つご紹介します

ModernIE(with VirtualBox)

https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/#downloads

ModernIEは、Microsoftが公式に提供しているIEテスト用の仮想マシンです。 MacでもIEブラウザを動かして検証することができるようになります。

導入の方法については、下記の記事が参考になるかと思います。

参考

「IE 確認用の仮想マシンの構築 (modern.IE)」

http://qiita.com/aoi70/items/ba4012bfd15f327dede9

CSSやJSのブラウザ固有のバグなどは、codepenなどで問題を小さく切り分けて検証すると時間の短縮ができますね。

FTPアップなしでIEで表示確認がしたい

Browsersyncなどで、ローカルサーバーを立ち上げた状態を確認することもできます。

デフォルトの設定では、http://10.0.2.2:3000/でアクセスができるはずです。都度ファイルをFTPアップしなくて良いので、デバッグがとても効率的です。

スクリーンショット 2017-04-25 23.12.18(2)

参考
「Addressing localhost from a virtualbox virtual machine」
http://stackoverflow.com/questions/1261975/addressing-localhost-from-a-virtualbox-virtual-machine

Charles

http://www.charlesproxy.com/

Webデバッギングプロキシアプリケーションです。簡単にいうと、Webページと端末の間に入ってごにょごにょしてくれるツールです。

APIが許可したホストからのリクエストしか受け付けないような場合や、開発環境と本番環境でディレクトリ構成が違う場合(画像などを別サーバーに配置するケースとか)などで、とても重宝します。

使い方については、下記の記事が参考になるかと思います。

参考

Charlesを使ってデバッグを効率化する

http://ceblog.mediba.jp/post/136783741502/charles%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%82%92%E5%8A%B9%E7%8E%87%E5%8C%96%E3%81%99%E3%82%8B

ModernIEでもCharlesでプロキシをかましたい

ニッチかもしれませんが、ModernIEで閲覧しているWebサイトにもCharlesでプロキシをかますことができます。

参考
「Charles と modern.IE で本番環境での動作確認」
http://please-sleep.cou929.nu/js-local-test-charles-and-modernie.html

モバイル端末でもデベロッパーツールを見る

モバイル端末をPCにつなぐことで、デベロッパーツールを見ることができます。
実機で見ただけでは、表示系のバグの原因を特定することは難しいですが、デベロッパーツールで確認しながら検証ができると、想像や予想で進めなくてよくなるのでとてもはかどります。

参考
「【お手軽】iOS Safariで表示したWebサイトをMacOS SafariのWebインスペクタでデバッグする方法」
http://dev.classmethod.jp/tool/ios-safari-web-debug/
「Android の Chrome で開発者ツールを使う方法」
http://qiita.com/hojishi/items/12b726f8b02ef3d713e4

ブラウザごとの差異を見やすくする工夫

ブラウザによって要素の幅や高さがなにか違う……という場面はよくありますよね。
そんなときは、デバッグ用のstyleを一時的に当てて要素の領域を可視化することで、 調査すべき箇所を絞り込みやすくなります。

@mixin debug(){
  body * { outline: 1px dotted rgba(255,0,0,0.2) !important; } /* red */
  body * * { outline: 1px dotted rgba(0,128,0,0.2) !important; } /* green */
  body * * * { outline: 1px dotted rgba(255,165,0,0.2) !important; } /* orange */
  body * * * * { outline: 1px dotted rgba(0,0,255,0.2) !important; } /* blue */
}
// @include debug();

プロジェクトの開始時に都度ファイルをコピーして持ってくるのが面倒なので、先日npmに公開してみました。
https://github.com/i78s/sass-debug-helper

実際に適用すると、ご覧のように要素の領域に点線がつきます。はみ出している要素などが非常に探しやすいです。
ローカル環境のみ、もしくは先ほどのCharlesを使っての確認にとどめ、間違って本番アップしないように注意しましょう。

終わりに

表示系のデバッグは、とても面倒で根気のいる作業です。問題の切り分けと怪しい箇所を絞り込み、再現条件の特定までをいかに早くできるかが効率化のポイントなのかなと思います。

便利なツールがたくさんあるので、うまく組み合わせて活用し、楽にデバッグをしていきましょう。

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。

Webサイト制作の実績・料金を見る

この記事のシェア数

フロントエンドエンジニアのいなばです。 LIGではAngularやVueなどのフレームワークを使った中~大規模のWebアプリケーション開発、フロントエンドエンジニアの育成などを担当しています。 好きなものはカフェインとカプサイシン。 趣味はランニングと一眼レフです。

このメンバーの記事をもっと読む
それいけ!フロントエンド | 213 articles
デザイン力×グローバルな開発体制でDXをトータル支援
お問い合わせ 会社概要DL