Web 開発者の責任 (翻訳) ― 2009年05月06日 19時31分

John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。

Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。

ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。

ブラウザを支援する解決策は 2 段階からなります。第 1 に、ブラウザのバグを見つけるたびに、個別のブラウザへバグ報告を登録しましょう。第 2 に、自分のサイトを主なブラウザの最新のビルドで積極的にテストしましょう。

Web 開発者の圧倒的多数は、一度もブラウザベンダにバグ報告を登録したことがないばかりか、ブラウザのナイトリー版を使ったことさえありません。これは恥じるべきことです。考えてみれば、ブラウザの何が異常かを評価するのに、ブラウザでの開発に日々を費やす人ほどその資格がある人というのはほとんどいないのです。

ブラウザのバグを登録せず、ナイトリーでのテストもしないプロの開発者を見たとき、私は特に驚きました。ほとんどの開発者の主な仕事のひとつに、クロスブラウザの問題を取り繕うことがあります。よって、バグの数を減らす (そして仕事を劇的に単純化する) ことは最優先事項になります。

私は個人的に全主要ブラウザベンダにバグ報告を登録してきて、良い報告を生み出すいくつかの特徴に気づきました。

良いバグ報告の登録方法

良いバグ報告を生み出す 3 つのポイントは、分類、テストケース、そして単純化です。正しく分類され、単純化されたテストケースが提供されたバグは、どんなものでもブラウザの開発者によるレビューが保証されます。

バグを登録する場所から始めましょう。

バグ報告を登録する

大抵、バグ報告を登録するときは、実際の提出フォームへたどり着く前に、いくつかの深い層を通り抜けなければいけません。最も利用すべきフォームの直接の URL を以下に示します。

バグを登録するときは、登録対象のブラウザの最新のナイトリー (後で説明します) でもテストしておきましょう。これは、ブラウザの開発者が最初に尋ねることのひとつです。もしそのブラウザの現在の開発版でも依然としてバグが存在し、いまだ修正されていないことを示せたのなら、ブラウザの開発者たちはずっと簡単に取り組み始められるでしょう。

注: 多くのバグ報告ページは、報告を提出する前にアカウントの作成を求めてきます。これは迷惑ですが負担は 1 回きりです。

バグを分類する

バグを適切に分類することは重要な第一歩です。しばしば、(レイアウトや DOM といった) 特定のモジュールのオーナーは、新しく来た提出をすべて監視しています。バグを適切な分類に割り当てることは、そのバグを修正するのにもっとも適した人物の眼前へ、直ちにバグを持ち込むことになります。

バグの分類はブラウザ次第です。(Opera や Internet Explorer のような) いくつかのブラウザがバグの登録に簡易的な分類を用意している一方で、他のブラウザ (WebKit/Safari や Mozilla/Firefox) は機能が存在する特定のモジュールを示すために複雑な分類を使います。

Mozilla/Firefox: コンポーネントを選択してください。最も一般的なのは DOM、Layout、JavaScript Engine などです。

WebKit/Safari: コンポーネントを選択してください。最も一般的なのは HTML DOM、Layout and Rendering、JavaScriptCore などです。

Google Chrome: Chrome に対して登録すべきか判断するのには注意が必要です。最初に Safari の最新リリースと最新の WebKit ナイトリーとの両方でバグをテストしてください。もしバグが Chrome のみに存在するのならそこに登録し、そうでなければ WebKit/Safari にバグを登録しましょう。しかし、もうひとつ問題があります。Chrome の JavaScript エンジン (V8) にのみ存在するバグは、(どさくさにまぎれて行方不明にならないよう) Chrome ではなく V8 のバグトラッカーに登録されるべきです。

また、Chrome は明示的な分類手段を提供していません。すべてのバグは開発者によりレビューされ、それから分類されます (このプロセスを制御することはできません)。

複数のプラットフォーム (OS X と Windows、Windows と Linux など) でのテストも手早く行うべきです。バグが複数のプラットフォームに存在することを特定すれば、ブラウザの開発者がバグの原因の発見に必要とする時間を削減するのに劇的に役立ちます。

テストケースを提供する

再現可能なテストケースは、どんな形式であれ何もないよりは優れています。問題が封入された Web ページは一般的に良い取っ掛かりとなります。もし Web ページをバグ報告に直接添付できるのなら、さらに良いでしょう (ブラウザの開発者がそのチケットに取り組むのには、しばらく時間がかかるかもしれません。指定された URL にテストケースがもはや存在しなければ、開発者は単にチケットを閉じてほかの作業へ移るでしょう)。

そうはいっても、悪いテストケースというべきものもあります。最悪なのは「http://example.com の Web サイトを見たら、ブラウザ X では動かなかったので、修正してください」といった類のものです。これは、失敗の正確な理由を見つけだすため、誰かに膨大な時間をとらせることになり、バグをキューのより後ろへと押し出すでしょう。

最良のテストケースは単純さを提供する類のものです。

単純さを提供する

単純なテストケースを提供することは、間違いなくバグ報告を作成する上で一番難しく、かついらだつ部分です。しかしこれは、大概報告に気づき修正してもらう上での重点でもあります。最も資質のある開発者でさえ、十分良いテストケースを作成するのに 30 分もかからないでしょう。

このようなテストケースを作成する手順は単純です。バグがあるページを持ってきて、バグの再現に影響しないものをすべて切り取ってしまうのです。これは、スタイルシート、画像、JavaScript ファイル、JavaScript ライブラリ、そして HTML を含みます。

たとえば、しばらく前に私が Dromaeo テストスイートを走らせていたとき、WebKit がある地点に到達すると常にクラッシュすることに気づきました。私はまず、不必要な HTML、CSS、画像などテストを切り取ることから始めました。最終的に私は単独のテストにたどり着きました。文字列の分割です。それから私は、外部依存が必要なくなるように、可能な限りテストスイートを剥ぎ取っていきました。

最終結果に注目してください:

var str = "", ret, fn = [];

for ( var i = 0; i < 16384; i++ )
  str += "a";

for ( var i = 16384; i <= 131072; i *= 2 ) (function(i){
  fn.push(function(){
    ret = str.split("");
  });

  str += str;
})();

window.onload = function(){
  setInterval(function(){
    if ( fn.length )
      fn.shift()();
  }, 13);
};

残ったものは、依然としてクラッシュを起こすにもかかわらず、これ以上ないほど単純です。この単純化に基づいてこの問題の理由はすばやく特定され、たった 2 週間後には解決されていました。

私のバグに取り組んでいますか?

これは興味深い点です。しかし、Mozilla/Firefox、WebKit/Safari、Chrome では (これらはすべて比較的開かれたプロジェクトなので) 判断しやすい点です。これら各ブラウザでバグの状態を判断する最良の方法を以下に示します。

Mozilla/Firefox: バグは、最初に選択したコンポーネント分類のデフォルトの窓口係に割り当てられるところから始まります。これはまだ何も意味せず、単純に人々の目をチケットにひきつけるだけです。人々はそのチケットに自分自身を CC し始めます (これはその人がそのバグの進行に興味を持つという意味です)。しかしながら、決定的な瞬間は、誰かがそのバグを自分自身に割り当てたときで、事実上その人がそのバグの状態に責任を持ち始めます。ほとんどの貢献者はそのバグにつけられるコメントが自動的にメールされるよう設定しているので、そのバグの状態に関して何かしら疑問があれば、遠慮せずコメントを投稿できます。しかし、そういったことは適度なペースで行ってください (日ごとに、あるいは週ごとにでさえ、更新状況を尋ねることは貢献者をいらだたせるでしょう)。

WebKit/Safari: WebKit は Mozilla/Firefox ととてもよく似た設定を使います。そのバグを管理し完了まで後押ししてくれる誰かをただ受け入れましょう。しかしながら、黄金のチケットはそのバグが「rdar へ行く」時です。Radar は Apple の内部的な (非公開の) バグトラッカーです。バグがそこへ移動したということは、事実上 (そのバグを「所有する」人によってでなくても、別の Apple の従業員によって) そのバグのある時点での完了が保証されるということです。Apple は依然として WebKit の更新の裏での大きな立役者なので、バグが rdar に移されるのは期待すべきことです。とはいっても、rdar は非公開で Apple の従業員向けなので、バグが完全に修正されるか、またそれはいつかを知るという恩恵はもはや得られません。そうなれば後は待つのみです。

Chrome: Chrome は Mozilla/Firefox ととてもよく似たシステムを使います。そのバグが現在割り当てられている人とのコミュニケーションを持続し、彼らが持つだろう質問には何でも答えるようにしましょう。

最終的にバグが解決されたのなら、おめでとうございます! あなたは Web を万人にとってよりよい場所にするのに役立てたのです。

しかし、いつもそうなるとは限りません。

私のバグが却下されたらどうなりますか?

却下されたバグは次の 2 通りに分類されます:

  1. バグではなかったので却下された。
  2. ブラウザベンダがそのバグに取り組みたくないので却下された。

1 番目はさらに 2 つの小分類に分けられます。

本当にバグでなかったのなら、おめでとうございます! 標準、あるいはそれ以外のブラウザのあいまいさに関する、今まで詳しくは知らなかったことを学べました。今やあなたはよりよい Web 開発者です! ブログへ向かい、発見したあいまいな新しいバグや API に関して書き、それを世界に向けて説明すべきです。

または、バグなのに所有者が不必要にバグを閉じてしまいました。こうなると、バグを再開するために、この状況について議論する必要があります。

2 番目 (ベンダーがバグに取り組みたくない場合) もまた 2 通りに処理されます。

第 1 に、バグの状況について議論しましょう。これはブラウザの開発者に、この問題を修正するために貴重なリソースをささげるべきという情報を与えるのに役立ちます。

または第 2 に、もし彼らが本当にそのバグの修正を嫌がっているのなら、ブログや Twitter アカウント、それに他の Web 開発者があなたの言うことを聞いている場所で厳しく叱責しましょう。もしあなたの立場に同意してくれる人を誰も見つけられなかったのなら、おそらくあなたがおかしいです。しかし、もしそれが、ブラウザベンダが修正を拒んではいるが正当な問題だったのなら、結束しおおっぴらに苦情を申し立てられるほかの人が簡単に見つかるはずです。まさにこれでいいのです。あなたはこの結果を正しく獲得しました。このバグを明るみに出すのに必要なすべての正当な努力をすることにより、すべての宣言でこれに関して不満を言うのに十分な特権を得るのです。

バグを議論する

ここで、あなたはバグが閉じられた時点にいるものとします。このとき、閉じた人にそれは間違いだ、すなわち、このバグは実際に正真正銘のバグである、と納得させる必要があります。

こうしたときに使える最良の論拠のいくつかを、使うべき順番に沿って以下に示します:

  1. そのバグが退行であることを示しましょう。それが以前のリリースでは動いており、変更のせいで動かなくなったことを証明しましょう。#2 と併用するととても効果的です。
  2. 実在の Web サイトが壊れていることを示しましょう。もし実際の利用者が、ポーランドの X 銀行やカナダの Y ショッピングサイトをもはや訪れようとしないことを示せれば、ブラウザはその問題を修正するためにあっさり全力を尽くすでしょう (Opera でない限り。その場合 Opera 側はサイトを強制的に動かすために browser.js を使うかもしれません。しかし、それはまた別の話です)。
  3. そのバグが修正されないことで破られている Web 標準を示しましょう。もしある特定のバグが修正されないことが原因で、W3C DOM 仕様が正しく実装されていないことを示せたなら、ブラウザベンダはそれを修正しなければいけないと感じるでしょう。もしそう感じないなら、これは格好のブログの題材となるでしょう。
  4. そのバグを修正しないことで他のブラウザとの互換性が失われることを示しましょう。もし IE と Safari、Opera のすべてがある特定の機能を実装するか、ある特定のバグを修正したなら、Firefox は (それが仕様と矛盾しない限り) 他の実装に従わなければならないでしょう。これは最も議論しづらいことです。しかし、より多くのブラウザが同行していればいるほど、話はより簡単になります。

もしこれらの段階のいずれも証明できなかったなら、何にせよあなたはただ自分の痒いところを掻いているだけであり、そのバグはほうっておくべきです。

例

私が異なるブラウザベンダに登録したバグの代表例をいくつか見せたいと思います。

WebKit/Safari

半径 0 の canvas の arc() が例外を投げる: canvas の arc() メソッドの呼び出しが例外を投げていました。私はとても単純なテストケースを提供し、仕様のうち WebKit が一致していない部分を指し示しました。これは投稿されたのと同じ日に解決されました。

多数の生きたオブジェクトに起因する .split("") でのメモリ不足エラー: ホストされた Web ページを単純簡潔にしたものを提供し、約 3 週間後に修正されました。

Mozilla/Firefox

Array.prototype.sort の大幅な速度低下: 単純簡潔な退行を示しました。正確な問題を突き止めるのにとても役立つ大量の Shark プロファイルデータをバグに含めました。これは 1 ヶ月以内に修正されました。

.children を実装すべき: Mozilla が (他の主要なブラウザすべてに存在する) .children メソッドを実装する必要があるか議論しました。十分な議論から、最終的 (約 6 ヵ月後) にそれを含めることになりました。

Internet Explorer 8

querySelectorAll の NodeList の例外: 単純なテストケースを提供し、「時間不足」のため却下されました。

現時点で私たちはこの問題を修正するつもりはありません。報告を理解してはいますが、残念ながら私たちは、顧客と Web 開発者に対する価値を最大化するために、何の作業をするか選択する必要がある段階にいるのです。

つまり、彼らはそれが問題であるということに同意しながら、修正するつもりはないのです。ですので、私は今それについて不満を訴えています。

HTMLElement.prototype.querySelectorAll が存在しない: 後でわかりましたが、これは querySelectorAll が標準準拠のページにのみ存在する (互換モードには存在しない) ことが原因でした。これはまったく奇妙なことですが、私はその決定の背後にある論拠を理解したと思います。いずれはっきりしますが、一度 IE 8 が動き始めれば、これが多くの人々を困惑させるのではないかと私は思っています。私は今や IE 8 についてより多くのことを知っており、IE 8 に対するより良い開発者です。

Google Chrome

for in ループが定義された順序で発生しない: これは互換性の問題でした (他のすべてのブラウザは特定のやり方で振舞います)。私は単純なテストケースを提供しました。このバグは誤って WontFix として閉じられましたが (これは混乱を招きました)、実際には修正されました。私はここで間違いを犯し、V8 に対して登録すべきこのバグを、実際は Chrome に対して登録してしまいました。V8 側でこの問題を扱うバグをここに示します。

setTimeout(..., 0) の発火が早すぎる: これは実際には Chrome チームによる構造の変更に起因するものでした。Mike Belshe (その変更の作者) が何が起きたのかを説明するために私へ個人的にメールを送ってきました。結果として私はより情報を得て、そのことに関するブログを書きました。

Opera

(私の知る限り、Opera はバグ報告に対する公式の公開された場を提供していません。)

ナイトリービルドのテスト方法

ブラウザのナイトリービルドでのテストの詳細に入る前に、私はおそらく最も一般的な質問に答えるべきでしょう。なぜブラウザのナイトリービルドをテストすることに気を遣うべきなのですか? それには 2 つの理由があります。

第 1 に、バグ報告を登録するときは、提出しようとするバグが既に修正されているかどうかを判別する必要があるでしょう。もしそれがナイトリーで既に修正されていたなら、それを提出するか悩む必要はありません。そのバグは次のリリースで修正されるでしょう。しかしながら、もしそのバグが解決されていなかったら、バグの登録を続けるべきです。

第 2 に、ブラウザがリリースされたときにあなたのコードが壊れていないか確かめるために、そのブラウザの最新のナイトリーであなたのサイトまたはライブラリを定期的にテストすべきです。どれくらいの頻度でテストするかはあなたしだいです。しかし、より頻繁にテストすればするほど、あなたのサイトまたはライブラリが、ある時点で大規模な退行に遭遇する可能性は低くなります。自分たちのサイトを壊す新バージョンのブラウザがマーケットに存在することを見つけて喜ぶ開発者はいないといって間違いないと思います。

ナイトリーに対するバグの登録は、他のバグの登録と同じです。単純化されたテストケースを提供し、退行が起きたことを強調するようにしましょう。もしあなたが十分な頻度でテストしていれば、開発者は行動に取り掛かるに違いないでしょう。

最新のナイトリーを入手する

ブラウザベンダはブラウザの最新版を入手するためのさまざまな方法を提供しています。その上、いくつかのブラウザは他のものよりも頻繁にリリースしています (たとえば、Chrome は 1 日に何回も、Firefox は 1 日に 1 回、Opera は 2 週間かそこらに 1 回更新します)。

Mozilla/Firefox

Mozilla は Firefox のナイトリーリリースを提供しています。これは、Firefox のプロファイルを使って Firefox の既存のコピーと同時にインストールし使えます。一度ナイトリーリリースをダウンロードすれば、毎日自動的に更新されるでしょう。

ダウンロード: Firefox ナイトリーリリース

WebKit/Safari

WebKit ナイトリーを OS X でインストールするのは簡単です。これはプロファイルの詳細なしに完全に並行して存在できます。しかしながら、これらは自動的には更新されません。私は WebKit ナイトリーが (OS X で) 確実に最新であり続けるよう、NightShift を使っています。

Windows でナイトリーをインストールすることはより面倒ですが (いくつかのスクリプトの実行とファイルのコピーを伴います)、動きはします。

ダウンロード: WebKit/Safari ナイトリーリリース

Internet Explorer

Internet Explorer のインストールは「一大事」です。それは以前にインストールされたブラウザのコピーを完全に吹き飛ばしてしまいます。このため、あなたのシステムにインストールされた Internet Explorer の複数のコピーを保持するために、いくつかのトリックを使うべきでしょう。IE 6 (とそれより古いもの) を扱えるインストーラや、IE 7 を考慮に入れた別のものがあります。一度これらのスタンドアローン版をすべてインストールすれば、安心して IE 8 をダウンロードしインストールできます。

IE 8 は各ベータリリースから自動的に更新されていましたが、もうそうしてはいないようです。もし Micirosoft IE Beta Connect プログラムにサインアップすれば、テスト用の最近のビルドを入手できます。重ねて言いますが、これらすべてのビルドは現在の古い版を上書きします。

ダウンロード: IE 8 ベータ、IE 8 ウィークリービルド

Google Chrome

Google は 1 日に複数のビルド (各リビジョンにつきひとつ) を提供しています。これらのビルドはお互いに並行して存在できますが、自動的には更新されません。一人のユーザーがそのために使える自動更新アプリケーションをビルドしました。

ダウンロード: Google Chrome ナイトリービルド

Opera

Opera の複数のバージョンは並行してインストールでき、自動的に更新されます。Opera はナイトリービルドを提供していませんが (2 週間かそこらに 1 回出ます)、比較的最近のブラウザの実例を供給するでしょう。

ダウンロード: Opera デスクトップチームブログ (ビルドはここに投稿されます)

Web 開発の今後に積極的な役割を担うことの重要性は、決して誇張ではありません。他の開発者が先にバグを登録してくれることを期待する、あるいはブラウザベンダがすべての退行の可能性に気づくことを期待するという受身の立場から、積極的に熱心でいることへの移行は、信じられないほど多くの力をあなたにもたらします。Web コミュニティとブラウザの間のコミュニケーションを改善するためにあなたがする最小限の作業は、Web 全体の質を改善するのに大きく役立ちます。

あなたのおかげで修正されたすべてのバグを、名誉の印として身に着けるべきです。あなたは、Web をよりよい場所にするための役割を果たしたのです。

訳文は以上です。

バグ報告は基本的に英語で行いますが、個人的な経験からいうと、テストケースがしっかりしていれば英語が適当でもわかってくれます。英語を書くのは慣れていなくてもコードを書くのは慣れているでしょうから、それを通せばいいのです。

なお、Firefox に関しては、日本語でバグ登録ができる場として Bugzilla-jp が存在し、その案内としてはじめてのバグジラがあります。Opera へのバグ報告や IE へのフィードバックも日本語のものを受け付けてくれるようです。

by nanto_vi [Web 関連技術] [コメント(0)｜トラックバック(1)]