書評：JavaScript Good Parts

どうもひろきのだいちです。
水野さん。ありがとう。こんないい本を訳してくれて。そしてくれて。

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

この本はJavaScriptの世界を一段押し上げるためのものです。きっとJＧPとか略されたり、蝶本といわれたりとしてこれからJavaScriptの世界でスタンダードとなる概念を構築するための本になるんだろうなと。その意味では仕事でJavaScriptを読む人間に必携の本となるだろうし、この本を「読む」だけではなくて「理解」することが必須となる本となるだろう。

しかし、これはPerlの世界で言うところ「Perl Best Practices」的な書籍ではないということも理解してほしい。

というのもまだ、JavaScriptの世界はPerlほど成熟していないからだ。

この本は「use strict」「use warnings」のための諸概念を切り出すという段階を担っているものであり、
JSLintはその外部実装といったほうがいいのだろうか。

これが荒唐無稽な著者の挑戦でないことは彼がすでに「JSONの規格化」に成功していることからも伺える。

次の段階を考えてみよう。
良いものと悪いものの線引きはできた。

ではその次は悪いものの使いどころと悪い性質の避け方だ。
Perlには「no strict」「no warnings」が用意されていて、悪い面をライブラリユーザに見せずに清潔なプログラミングを可能にしている。

newの使いどころ

newの何がわるいの？

PLAIN TEXT
JAVASCRIPT:
  1. function hoge(){
  2.     this.fuga = "x";
  3. }
  4. new hoge(); //{fuga:"x"}

newはjavascriptのクラスシステムの根幹を担うところであり、使わないという選択肢はなかなか難しい。
すべての機能をmethod chainの中に隠蔽してしまうという方法論もあるにはあるが、DOMありきのプログラミングモデルならまだしも、それ以上のものを考える場合には必要最低限の機能である。

なにが悪いのかといえば次のようなケースである。

PLAIN TEXT
JAVASCRIPT:
  1. function hoge(){
  2.     this.fuga = "x";
  3. }
  4. hoge(); // undefined, window.fuga="x"

hogeはコンストラクタなのに、new演算子を伴わないで呼び出された場合にfunctionにbindされているthisかあるいはトップレベルオブジェクトに対して汚染をしてしまうケースがある。

これは確かに致命的だ。

ひとつはコーディングルールの中にClass名をHogeのように先頭をcapitalizeするという方法論だ。
もうひとつはコンストラクタ中でチェックルーチンを入れるという方法論。

PLAIN TEXT
JAVASCRIPT:
  1. function Hoge(){
  2.     if(this===self)throw('Error');
  3.     this.fuga = "x";
  4. }
  5. Hoge(); // error :Error

あるいは、

PLAIN TEXT
JAVASCRIPT:
  1. function Hoge(){
  2.         if(this.constructor!==Hoge)throw('Error');
  3.     this.fuga = "x";
  4. }
  5. var x ={};Hoge.apply(x);

こういった機能の柔軟性を封じるやり方もできる。

本書に出てくるnewをFunctionオブジェクトのmethodとして実装するやり方もエレガントだけど、
もうすでにnewがあるんだからライブラリ作成者なりが注意しておくか、レビューをしっかりすれば問題ナッシングだと思う。

withの使いどころ

JavaScriptからは関数のスコープで定義されるActivation Objectに直接アクセスすることができない。
これはここらへんを読んでもらうとして。

たとえば、Globalオブジェクトをできる限り汚染しないようにして、ネームスペース的機能を提供しようとした場合に

PLAIN TEXT
JAVASCRIPT:
  1. window['core'] = {};
  2. (function(){with(this){
  3.     this.fuga = 'text';
  4. }}).apply(window['core']);
  5.  
  6. (function(){with(this){
  7.     print(fuga);
  8. }}).apply(window['core']);

これは適切なnamespace機能さえjavascriptに用意されていれば済む話だが、withが強力な機能を提供する場面でのひとつだ。

eval/new Functionの使いどころ

evalはあらゆる言語で悪者だ。
パフォーマンスを下げてしまうし危険を伴うと紹介されることがおおい。
これに関しておおむね同意した上でもなお、evalを利用することが適切な場面が存在する。

これは皮肉なことにむしろパフォーマンスの分野で。

Webクライアントの技術において、パフォーマンスとはユーザエクスペリエンスのために存在する。つまりユーザがある動作（クリックなど）を行ってから何らかのアクションが発生するまでの時間を最適化したいというニーズが最も多い。

なので、

PLAIN TEXT
JAVASCRIPT:
  1. element.onclick = function(){
  2. 　　for(var i=0,length=BIG_ARRAY.length;i<length;i++){
  3. 　　　//複雑な条件や分岐により重くなる処理
  4. 　　}
  5. }

のようなプログラムがあったときに

PLAIN TEXT
JAVASCRIPT:
  1. dom.ready(function(){
  2.     try{
  3.         window.onclick = new Function([
  4.             '複雑な条件、分岐処理で確定しているものを取り除いたtext'
  5.         ].join(''))
  6.     }catch(e){}
  7. });

のようにしておくことで、DOM構築完了後からimageロードまでの比較的余裕のある時間でスマートな関数を構築しておくことができる。

こういったテクニックは邪道ではあるが、effects.jsなどでも用いられている高速化テクニックの１つであって、JavaScriptというインタラクションのために用いられる言語では重要な要素になりうる。

あくまでもミッションクリティカルな場所でのみ使われるべきではあるが、Templateエンジンなどを実装するためにはevalという邪悪な手段が最適最良のスマートな方法になる。

function文とfunction式

function文とfunction式の違いは、Activationオブジェクトの生成タイミングを理解しておけば間違えることは少ないだろうが、解釈の違いにより問題が起こることは確かにある。

PLAIN TEXT
JAVASCRIPT:
  1. //function 文
  2. function hoge(){
  3.     [sample code];
  4. }
  5. //function 式
  6. var hoge = function(){
  7.     [sample code]
  8. }

これらは同値であると説明される場合が多いが以下のようなケースで違いが発生する。

PLAIN TEXT
JAVASCRIPT:
  1. (function(){
  2.     var x = 0;
  3.     console.log(hoge);// function hoge(){}
  4.     function hoge(){}
  5. })();
  6.  
  7. (function(){
  8.     var x = 0;
  9.     console.log(hoge);//undefined
  10.     var hoge=function(){}
  11. })();

function文は自動的にスコープの先頭に移動して解釈されるが、function式は解釈されない。

これ自体は小さな問題に見えるが、さらにif文内でのfunction文の巻き取りはjsの実装によって異なりポータビリティを損なうというのが本書の指摘するところだ。

たしかにこれらはポータビリティや保守性を下げる場合がおおい。
しかし、function文がデバッグ性にプラスの要素を与える場合が実はある。

PLAIN TEXT
JAVASCRIPT:
  1. Handler = {
  2.     func : (function(){
  3.         function xxx(){}
  4.         return xxx;
  5.     })()
  6. }
  7. console.log(Handler.func);　// xxx
  8.  
  9. Handler = {
  10.     func : (function(){
  11.         var xxx = function(){}
  12.         return xxx;
  13.     })()
  14. }
  15. console.log(Handler.func);　// function

function文によって作られた関数は処理系内部において"公式な名前"を得ることができる。
公式な名前がある関数は、それが他の関数ではなくて自分自身であることを証明することができる。

この仕様を正式なものとしてなにかプログラムを書くことを推奨はしないが、
この要素が煩雑なプログラムの中で問題箇所を適切に見つけることのできる一因になることがあるということは覚えておいて損はないだろう。

functionは式であれ、文であれこの"公式な名前"をつけられるという性質を知っていると
プロファイル等で

PLAIN TEXT
JAVASCRIPT:
  1. $('test').observe('click',function (){
  2.     // 公式な名前の無い関数
  3. });
  4.  
  5. $('test').observe('click',function _anon(){
  6.     // 公式な名前のある関数
  7. });

複数の無名関数の中から、問題の箇所をわずかな変更ですぐに知ることができるかもしれない。
これらはfunction文ではなく、function式であるのでスコープのオブジェクトを汚染することはない。

PLAIN TEXT
JAVASCRIPT:
  1. $('button').observe('click',function _anon2(){
  2.     $w('first last').each(function _anon(e){
  3.         //
  4.     });
  5.     console.log(_anon); //is not defined
  6. });
  7. console.log(_anon2); //is not defined

公式に運用するscript中では無用なものではあるかもしれないが、こういった性質によって見えてくる世界もある。

そんなわけでまとめ

・JavaScript Good Partsは仕事でJavaScriptを書くすべてのエンジニアが必読の書である。
・読んだ後、汚いもの/悪いものがどのように使われるべきか考えてみよう
・きれいな世界と汚い世界を分けることでJavaScriptはもっと輝きを増す。

« 【告知】日本野望の会 忘年会 2008 – [イベント]そろそろWebを再起動しよう »

コメントはまだありません »

コメントはまだありません。

コメントをどうぞ

 

WP-Design: Vlad -- Powered by WordPress -- XHTML 1.0