工作之余的思考

一直都是在写一些比较低级的前端知识，很少听下来思考一些问题，现在思考增加一些软实力：
实习的时候发现一个问题：就是学生思维还是存在，主动性不够好，我总是把一些项目完成以后到达截止日期才上报给领导，在这之前就做一些自己的事情。我应该是尽早和我的领导汇报。
2、所在的项目是有使用服务端返回一个html 结构，然后我们可以通过谷歌的控制台里面访问我们的参数，甚至使用谷歌控制台来修改我们的参数，因为这些已经相当于页面上的一个巨大的html 这样我们就可以，输出访问里面的一些变量。来判断是否达到预期，就像某天一个后台给出一个页面是可以展示的，可是当时我的脑子就蒙住了，怎么找到的是不是傻？直到我的导师使用谷歌调试台把传进来的参数使用数组的各种方法，通过那个页面的蛛丝马迹字段找到了我想要的那个页面数据结构，可是当时我呢？这些方法我是应该想到的啊？所以好好使用调试台，不仅仅用于打断点，可以判断变量，遇见一个问题的时候：不要慌乱，首先想到我可以检查一下network里面是否有请求发出，我页面一开始加载是否有请求回来？如果是404很可能是请求的资源不存在，一般入口文件不外乎index .js\index.cssindex.html打包回来,最多的就是在index.html中我们的js和css 一般都会是一个内联在html页面中的，所以网络分析结束以后，某个页面的一些数据可能不对，那么就可以看见这个也页面里面的script标签里面的变量我们是可以访问的，你的代码你肯定熟悉，你既然传递过这个变量那么你就打印出这个变量吧，然后分析是否是预期结果。
因为和移动端打交道多，涉及到webview，那应该如何实现自己调试得到回调函数的执行呢，参考自定义事件你只能自己dispatch这个事件，然后自己设定的这个事件监听就会得到执行。
3、对于性能的一些分析network里面有一些录制功能我们可以在里面看见资源加载的时候花费的时间。断点就不在介绍了，自己总结的一些杂谈。
然后就是在函数抽象的时候可能一开始还是不够抽象，首先可以分析这个函数是要做什么，那么另一个函数是不是也有这部分功能，那么我把相似的地方抽成一个函数，不同的地方做一些判断处理，那么相似的地方如果参数不同，但是都根据是否有参数来判断，那么我完全可以把参数的传递设计成一个true或者false，就是在调用的时候进项判断，传递参数，这样就可以使得我们的函数只有单一的功能。
然后一直理不清客户端前端因为页面内嵌在webview里面所以就有前端定义的sslocal被客户端捕捉到，然后客户端取得里面的参数给后台发送URL请求，所以客户端是通过发送的URL请求来判断是否感受到了jsbridge,否则就有两种情况：前端未发出， 客户端未捕获，所以就可以通过断点来判断是哪里的问题。
最后一个技巧node就是好，使用node其服务，使用ip:端口实现他人访问自己页面，模拟开发机。
租后一个好用的就是chrome://inspect
连接手机手机里面是谷歌浏览器，断点调试没在讲的，超级爽啊。
最后最后就是代码容错和一些常见使用//： 可以承接HTTP：或者HTTPS：协议这个就有点像完美的兼容手法。表示是谁就匹配谁。
最后最后接受一个新工程以后一定要仔细看代码，不知道的就问问前辈为什么写成这个样子，看看packege.json 里面的配置，设置了解到输出到那个文件。可能需要看webpack.config.js知道入口文件。最后文件编辑的样子。看network里面请求资源的顺序，然后进行分析，前端跳转react和vue都会是#在拼接路径。
一些代码如果很长很多，最好的方式是找到调用的入口。然后从调用的地方开始走查相关函数，避免自己懵逼脸。被一大丢容错代码失去兴趣，头脑不清醒。