浅谈javascript的调试


最近比较吐槽,大家都知道,现在web前端相对几年前来说已经变得很重了,各种js框架,各种面对对象,而且项目多了,就会提取公共模块。

  这些模块的UI展示都一样,不一样的就是后台逻辑,举个例子吧,我们做企业差旅的时候,通常都有一个成本中心的js公共模块,客户在预定机票的时候来填写这个成本中心,而这种成本中心分布在online,offline和app等预定端,这样也是方便后期和客户公司进行月结算。

  我们还知道,项目做大了,复杂化了,SOA化了之后,很多问题就来了,就像web中的一个理论,所有前端的数据都是不可信的,那对方团队的接口数据又何尝不是,以前项目小的时候,不会那么不自信,也只会在Logic error的时候会记录下日志,正常的业务流程一般很少记录,毕竟info日志看着不美观,而且还会消耗服务器带宽,也还会拖累web的性能。

  但是项目大了,当你某天在项目中遇到了奇怪的bug时,你靠着残缺不全的日志,好不容易用肉眼逐行追溯到了接口,但是参数太多,无法准确的还原接口的参数数据,但是你又100%的自信认定肯定就是接口的返回问题,但是又拿不出完整的报文,这时候你又没法找接口提供方,当时那个无奈呀,多想最好每行都有日志该多好啊。

  有了教训后,记流程日志的趋势越来越盛行,最终也酿造了一个年初的大事件,稀里糊涂的说了一大堆,web后端如此,那现在的重前端不也一样要记录日志么?我们知道既然是公共的js模块,那这个模块肯定自己封装了一些方法,肯定是绝对不可以让第三方程序去操作它自己的文本结点,比如下面这样:

http://xxx.com", { "title": title, "message": message }, function () {
                }, "post");
             }
         };
         return result;
     })();

<2>image

  我们的dom中有一个叫做image的对象,所以可以通过动态给它的src赋值来达到请求后台url的目的,同时在url中加上我们需要传递 title和message信息,这种动态给image.src的方式是不需要考虑浏览器兼容性的问题,非常不错。

http://xxx.com", { "title": title, "message": message }, function () {
                }, "post");
             },
             info_image: function (title, message) {
                 //image
                 var img = new Image();
                 img.src = "http://www.baidu.com?title=" + title + "&message=" + message + "&temp=" + (Math.random() * 100000);
             }
         };
         return result;
     })();

以上就是本文的主要内容了,后续我们将继续深入探讨


« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3