JavaScriptの対象——柔軟性と危険

12418 ワード

JavaScriptのオブジェクトよりも単純で柔軟なデータ構造はありません.弱ダイナミックタイプの言語として、JavaScriptは対象の属性に対して何の制約もありません.その結果、使う時にはとてもさわやかで、どの属性を直接つければいいですか?しかし、このコードは運行中です.
JavaScriptという柔軟性の最大の問題も制約がないです.例えば、一つのネットショップシステムは二つの部分があります.一部は注文の対象ができます.もう一つは注文の対象を取って展示します.私たちのフロントプログラマは当然その部分を後ろに展示します.例えば、注文書の中の商品の価格をページに展示すると、order.product.price.sumが落ちます.しかし、注文書のどの部分のコードを作成した兄弟は必ずしも信頼できないです.注文書の中に贈り物があります.価格がないということです.priceフィールドは全くありません.フロントエンドはやはりorder.product.price.sumです.もっと怖いのは、今多くのシステムがnodeを導入して、前後の端を境界線に分離して後ろに移動しました.今回はnodeでorder.product.price.sumを呼び出します.
この例はlowだと思いますか?注文データの中の商品には必ずpriceフィールドがあると思います.価格がなくても後進の兄があなたに伝えてくれます.それに、人のバックエンドはjavaを使っています.強静タイプの言語で、各属性はとっくに定義されています.どうやってなくしますか?また、オンラインに行く前にそんなに長い時間をテストしなければならないのに、どうしてオンラインでこんな問題が発生しますか?
今はJSONはネットワーク間を横断する標準的なデータ構造です.たとえあなた達のシステムのバックエンドはjavaで書いても、フロントエンドがこの書き込みバックエンドインターフェースを呼び出す時に得られたのはJSONです.ところでこのJSONは何から転じたのですか?きっと何かの対象になりますか?大変です.バックエンドのお兄さんは早くJavaの融通がきかないJSONを発見したかもしれません.それに、バックエンドが真面目にクラブを使っても、もしあなた達のネットショップのシステムが大きくて、いくつかの店の種類の注文があります.これらの注文は同じクラスから来たのではないでしょうか?
いずれにしても、私たちはこのような全文書を持っていません.時にはドキュメントがあっても、後端の兄は親切に教えてくれます.コードを基準にしてください.
オンラインの前にこのようなフィールドが欠けているバグを全部測定したいなら、QA兄弟とは言いにくいと思います.バックエンドのデータは彼らが計算したのではないです.オンラインが長くないといけないので、急に足りないものがあります.
人はいつもあてにならないので、コードから何とかしなければなりません.
最も直接的な方法は慎重にステップすることです.リスクのある属性を呼び出すたびに、親ノードが存在するかどうかを判断します.これは、慎重さがどの程度かを判断するために、データソースの信頼度を推定する必要があります.前の商品の総価格の例では、一つの注文に商品がないということはないでしょう.コードはこのようにできます.

var showPrice
if(order.product.price)
  showPrice = order.product.price

実際の状況は往々にして複雑です.例えば、今取りたいデータは注文書の中の一つの製品のメーカーの連絡先の中の電話番号の中の一番目の電話番号です.

var temp, temp1, temp2, temp3, phone;
if ((temp = order.product) != null) {
  if ((temp1 = temp.seller) != null) {
    if ((temp2 = temp1.contact) != null) {
      if ((temp3 = temp2.phone) != null) {
        phone = temp3[0];
      }
    }
  }
}

こんな下手!JSがこのように書くなら、後ほどJavaを書いてもいいです.
ありません.ヾ(¯∇￣๑)
私はcoffeescriptを使います.実は私たちが今やっているプロジェクトはcoffeeの上に構築されていませんが、coffeeを使って、どう使うかは別の話題です.とにかくcoffeeを使っています.このコードはこのようです.

phone = order.product?.seller?.contact?.phone?[0]

残念なことに、私は多少強迫症の人です.その疑問符を見るたびに、コンパイルされたifの山を連想します.私はパソコンのために疲れています.また、この疑問符は漏れやすいので、こっそりと見つけにくいです.つまり、私は自分ではなくなるかもしれないと思っている属性の前に疑問符をつけるだけです.
これらの判断をするには、チェーン上の属性が欠落したら、直接undefinedに戻ります.js自身はこのおもちゃを提供しないで、自分でひとつ包装します.

Object.prototype.getAttr = function(path){
  attrLink = path.split('.');
  var ref = this[attrLink[0]];
  for(var i=1; i < attrLink.length; i++){
    if(ref)
      ref = ref[attrLink[i]];
    else
      return undefined;
  }
  return ref;
}

アクセス属性はこのようになります.

order.getAttr('product.seller.contact.phone.0')

これで安全です.しかし、デバッグする時はむしろ解释器に赤い異常を教えてもらいたいです.誰が定義されていないのか、それとも暇なのか、こっそりミミをもらいたくないのかは不明です.方法はあります.上のコードはrefが空いている時にログを出力すればいいです.最後の問題は、getAttr方法は、Javaのように属性を私有している限り、getterを使用することができます.他の仲間が必ずこの方法で属性を取ることを保証するどころか、自分でも書いてあるかもしれません.直接に注文します.最終的に、このObject.getAttrの方法は実際に開発したことがありません.
前のようなcofeeの中に疑問符を付ける方法は十分だと思います.もし私達自身がこの属性を持っていなければならないと思ったら、後端インターフェースはそれを伝えていないです.しかし、実際にはすべての可能性があります.バックエンドのお兄さんを責めることはできません.この注文データは他のシステムから送られてきたものか、それともとても古いものかもしれません.
どうして騒ぐのですか?私の原則は損失を最小限に抑えることです.つまり異常影響のコード範囲を最小にすることです.これはtry.catchに頼っています.
どこでtryがコードの状況を見て、どのtryを捕まえることができますか?でも、ちょっと法則があります.
スペクトルに頼らないデータは私達が自分で書いたのではなく、外部インターフェースから来たのです.このインターフェースのデータ利用のコードには一定の範囲があります.最低限度の状況はこの区間をtryに渡しました.これはまだ粗すぎる.データの特徴を見てみると、多くの外部データはしばしば反復可能であり、例えば注文リストが表示され、この注文リストには必ず循環があります.循環内部tryについては、これはせいぜい一つの注文書では表示できません.一部のデータは統一的に処理されていますか?例えば、私が作ったnodeプロジェクトはhandlebarsテンプレートを使っています.テンプレートは多くのカスタムhelperを使います.これらのhelperの多くはデータを表示に処理した結果、例えばフォーマット価格などです.これらのhelperには同じコードの入口があります.

helpers =  _.extend(
    require('./helper1'),
    require('./helper2'),
    require('./helper3')
)
// “_” underscore  lodash

つまり、各ファイルのhelpersを一つの大きな対象としてまとめて、

module.exports = _.reduce(helpers, function(memo, f, k){
    memo[k] = function(){
        try {
            return f.apply(this, arguments)
        } catch (e) {
            console.error('handlebars helper error', e)
            return ''
        }
    }
    return memo
}, {})

exportの前でhelper関数を全部一つのtry...catchに包んでください.このように一つのhelperの中にフィールドが欠けているエラーがあると、ちょっとしたものが表示されなくなります.
実は私はすべてのhelperを一つの大きな対象に集中しています.その目的はこれのためではなく、各helperファイルを全部登録して、繰り返して見たら多すぎて、不快です.有名なコードの保守原則があるのではないです.大体「コードの重複は避けなければならない」ということですか?これでいいところが分かります.
完璧に見えます.そうではないです.その後、兄達はまたhelperを書いて、私のこれらhelpersの中に置いていないで、別のファイルの中で単独で登録して行ったので、結果の変なデータは本当に現れて、悲劇は本当に防備に耐えられなく上演しました.
まあ、とにかくいろいろな奇術を使いたいのですが、規則通りにカードを出すことはできません.実際には、すべての同志は、データのフォーマットを規定し、厳格に実行する必要があります.

javascript高速テンプレートレンダリングエンジンmvcを実現します.