[モバイル対応]フロントエンドの要件のブラウザ依存を考慮するためのエンジニアの動き方
初めまして、ソフトウェアエンジニアの ojin です。普段は、主にフロントエンド専任で開発することが多いですが、バックエンド歴も長いため色々と興味が湧いてしまうタイプです。
はい、それではこちらのブラウザ、端末依存についてを書いていこうと思います。ここで書いているのはただの方針に過ぎないので、特に真新しいことはないと思います。間違っていたり、もっといい方法があったら教えてくだされば喜びます。
今やモバイル対応は必須になっていますが、ではどこまで対応すれば良いのでしょうか？そんな悩みを持つ人は多いと思います。そこで自分なりのやり方を書き起こしました。
モバイル対応について
モバイル対応と一口に言ってもどういうことなのか、という話ですが、基本的にここでは以下のことと定義します。
- 対象外
- Nativeアプリ
- 対象内
- 最新版iOSのSafari/Chrome
- 最新版AndroidのChrome
Nativeアプリを入れてしまうと範囲がやたらと広くなり、この記事で言いたいことが書ききれなくなることがありうる、かつ自分がNativeの知識が浅いため省いています。
iOSとAndroidのブラウザは制限したらダメだとしてもどこかで境界線を引きたいと思います。今回はこの一番わかりやすいところで線引きをしています。
モバイル対応を調査する経緯
通常、PRDなどを決める時に、おそらく技術的に実現可能かという話をチームでディスカッションするかと思います。そして技術的に可能だった場合、その技術が利用者の対象環境で使用可能かという調査が必要になります。
調査する必要があるものが生まれたら、それぞれチケット化して担当者をアサインし、優先度を決め調査を始めることと思います。
はじめに
所感
我々プログラマにとって、既にあるものを使い回す能力がある事っていうのは「いわゆる、エンジニアとして優秀」という認識で良いと思います。当然、一から作り出すってすごいことだし、それにはただ尊敬の眼差ししかないのだけれども、自分を含むほとんどのプログラマにとってそれは回り道の中でも相当遠い場所を選んでいるという自覚があるだろうし、物事を解決するということにフォーカスした場合、関心ごとってゴールに近い部分だと思います。その関心ごとをいかに素早く解決できるか、そういった能力が高いエンジニアは重宝されます。
以下の5つのレベルで考えています
- 実はCSSで実現できる
- JavaScript標準で実装されているかどうか (not experimental)
- 著名なnpmパッケージでほぼ同等の機能が実現できそうか
- JavaScriptのexperimental機能
- 別のアーキテクチャで解決する
0. 実はCSSで実現できる
ブラウザ対応表とパフォーマンスだけチェックしたら、CSSの方が明らかに安定しているのでCSSを使いましょう。ただし、CSSは安定はしていますが、複雑なことをしようとすると変更が厳しいことが多いので、レビューはしっかりとしてあげる必要があります。
1. JavaScript標準で実装されているかどうか (not experimental)
もし標準で解決できるのであれば、大分運が良いパターンです。そのまま使えばOKです。ただし、実績の少ない機能に関しては実機で動作が不安定なことがありますので、100％信用はできません。そこが判明するのってこの段階ではないので、ほぼ100%OKという回答を提示するのがよいでしょう。このレベルで済む問題であればブラウザの影響は受けにくいです。
2. 著名なnpmパッケージでほぼ同等の機能が実現できそうか
著名なnpmパッケージで実現が可能であればラッキーですね。グラフィカルな要件の場合、ほとんどはnpmパッケージの恩恵を受けることになると思います。Cなどで記述されたライブラリをJSで使えるようにしてあるケースも多いので、ちょっと使い方には気をつけなければいけないことも多いですが。
さらに拡張が必要になった場合でもIssueをポストしたり、Forkするなどして自分で修正することが可能なので、自由度が高いと思われます。ただし、動作が不安定な可能性は捨てきれません。READMEやDocは普通に嘘が書いてあったりしますし、古い可能性もあります。実装されているコードを読みましょう。ここに関していうと、ほとんどはnpmパッケージのGitHubコードを読めば解決可能です。また、READMEには一応対応ブラウザなどについて明記があるはずで、もしなければ開発者に質問してみるのが良いでしょう。
3. JavaScriptのexperimental機能
can I useでまずはサポート状況を見て、サービスの対応との関係を把握し問題ないか、というのを最初に行います。スマホに対応していない場合、使用することができませんので、情報をウォッチするにとどめましょう。
問題ない、となってから、我々には厳しい戦いが始まるでしょう。今後のサポート、仕様変更を追従してリアルタイムでサービスに修正を加えていく必要が出てきます。experimentalを使う場合、bugzillaなども検索してみてまずは明らかになっているバグがないかどうかを最初に把握しておく必要があります。
また、Chromeの挙動を知るためにC++を読むタイミングもけっこうあるため、もしJavaScriptしか読めないできない、となってくると中々厳しいかもしれません。iOSに関しては、Appleのdevelopr forumを漁るとたいていのことは見つかりますし、WebKit bugzilla、バグが顕在化しているのであれば、チケット化されているか確認する必要もあります。
経験的に、3を選んでしまうと本当に楽しいことになります。コードを書き続けて、試行錯誤をする、といった我々プログラマにとって最高でハッピーな時間を過ごせることでしょう。
ただ、自分の場合どうしても無理な状況になって、UXを壊して無理やり実現するといった荒業が必要になったことがあります。（UXを壊す、というのは要はPDM, Desinerと話し合い、機能の不完全さと要件を満たす代替案の提示を踏まえたMTGによる結果のことです。）我々Web系のプログラマにとって、書けるのはJavaScriptだけになります。もちろんほかのツールを使うこともできますが、基本的にはそこしか触れないので、ブラウザやOS側のバグがあった場合Webだけではハンドリングが非常に困難になり、あらゆる策が沼にはまってしまうのです。解決策は、Apple or Google、あるいは端末依存を引き起こした開発元がバグを修正してくれるのを待つ、あるいは代替案にてハマってしまったバグを回避する、のどちらかでしょう。もちろん、experimentalを捨てる、というのが最も手っ取り早いですが。時期尚早という判断を下し、開発したコードを捨てるのもエンジニアの仕事の一つです。
ただし、今後のことを考えて社内Wikiにはしっかりと調査内容をまとめておき、どのバグがDoneになればこの機能を再度ONにして良いか？ということを具体的に明記しておきましょう。コードを捨てた以上、それにかけた時間が将来的に有意義になっていることが望ましいです。
4. 別のアーキテクチャで解決する
実は、機能を実現するためには、別のアーキテクチャで解決した方が安定することは多いでしょう。例えば、データを表示するために計算量が大きいのであれば、事前にバッチ処理などで計算をした上でそのデータを取得させるようにするなどです。我々フロントエンドの関心ごとでいうと、基本的にはUI/UXの向上になります。
Discussion