## Note
> 哟哟,今天写着Note,昨天学了Node,还看完了Webpack,感觉自己像个geek~
昨天因为mongo只用了解增删查改,之前有用过就没复习。主要是看自己买的书,阿里居玉皓写webpack调优与进阶,终于看完了,有几点我觉得收获比较深：
- webpack的基本概念。什么chunk,bundle,loader,plugin,WDS,万物皆模块这些就是老生常谈了。热模块刷新倒是一个对我来说不太了解的概念,它实际上是WDS对网页有了一个websocket的长连接,然后你编译后通过chunk的hash值来对比是否刷新,比较关键的是它用了HMR技术来实现局部刷新。
- 对于软件工程来说,好的优化方案不是说上来就构建,而是项目达到一定规模后再针对性的去优化。
- 一些优化方案。这里就说一下大体思路吧。
- 去除死代码。其实我觉得common.js之所以要被淘汰是因为他是动态的,无法对语言进行静态分析,而ES6 module则是静态的。同时common.js是只是对之前值的一个copy,而ES module则是映射。而对于webpack来说,打包去除没用到的代码就要用到tree-shaking（个人感觉听起来还是比较好用的）
- 利用缓存,这个就不说了,common.js它会使用之前的缓存,如果你不刷新的话。同时就是如果能使用缓存就使用缓存,如果你想新发布一个东西,同时让所有用户都不使用之前的缓存,可以直接改变你的资源连接,或是利用chunk的hash值进行版本更新。
- 打包范围.什么vendor,exclude,include,代码分片后提取公共部分,noprase,IgnorePrase之类的。
- 资源压缩
然后就再看朴灵写的深入浅出Node.js，目前收获:
- Node的一些运行规则,和Node的背景
- common.JS的一些规范。
- NPM包的详细由来与使用方法
就这么多啦
> 不要想着一蹴而就,要脚踏实地
昨天早上看了会<深入浅出Node.js>,发现自己一旦涉及到操作系统或是C/C++时就看不懂了,还是自己段位不够吧。准备先读iting5的<狼书>，这本好像简单一点。而计算机网络,我觉得还是有一个大体的印象后再去读书会好很多。所以准备看看mooc上的课程。下周之类看完吧。
工作这边就,昨天布置了任务,然后写了几个小时,完成了album的编写吧。不过mongoDB好像连接出了问题。准备今天把这个任务完成。感觉难度并不是很大。
早点写完！不写完就加班！早点下ban
2021 7月9日
> 加油吧，伍勋高
今天一天就在写老师的任务,只是还没有写完,食言了...主要是我爸妈来看我了,不然一定加班了。
下午领了甜点后好像就开始摸鱼了....一直在看掘金。
周末一定要写完呀...
周末
好吧,周末,都再摸鱼。周一一定一定。
好吧,作业好像比我想象中难许多,今天一天就在嗑这个了,主要是数据库操作出了几个比较傻的错误,耽误了很久,然后现在估计只有用户的测试代码没写了。当然还有过敏之类的问题,还有token失效的问题。
今天就完成了作业,感觉完成度还可以。还看了小会node.js。准备还是得把他啃完。
不要因为一时的成功而松懈
昨天主要是看了下hook的知识,个人感觉其实就是组件微小化,颗粒化理念的一种实践,是类组件的一种简洁进化。但好像对于函数组件来说,我们之前没办法管理函数的创建与结束（对应类组件的生命周期）,局部作用域的变量也得不到保存,函数可以说是七秒钟的记忆,所以我们引入hook,也就是我们的钩子来做这些事情。我们的hook实质上感觉是类组件在函数组件上的扩展。因为它更具有简洁性和方便维护以及自由度高的特点,当然react开发团队也做了许多性能上的优化,这是React开发者需要全面拥抱hook的原因。
类组件的复杂之处在于它需要继承,管理类状态.父子通信与爷孙通信的嵌套会导致类组件越来越复杂,状态管理也越来越复杂（当然也有modux与redux等解决方案),伴随而来的还有类中this的各种指向（感觉this的指向是前端开发者绕不开的,this通俗意义上是指向的就是引用它的.而在类中我们需要手动绑定各种this,因为javascript的执行机制会导致this隐式绑定,然后丢失.）同时你在生命周期里进行一些需要手动清理的操作时,会让你的生命周期函数变得越来繁琐。
对于函数式组件来说,则要轻松很多。我们引入useState来管理状态
const [use,useState] = useState('预设值')
一般来说退出函数后,变量会被注销。React会对挂载上去的组件进行追踪,同时组件内部又会有'记忆单元格',所以并不是每次加载都会创建我们的state,而是把state放入我们的记忆单元格上,等要取出来的时候再再去查询,这也是useState中use的由来。值得一提的时候,我们并不要像类中使用繁琐的this指向了,而是直接通过数组解构出来的useState方法来给我们use这一单一变量进行设值。
对于类组件的生命周期来说,我们常常在componentDidMount和componentDidUpdate中执行副作用（一些获取数据,更新视图之类的操作),在componentWillUnmount中做一些清除副作用或承接的操作。React提供的另一个Hook useEffer则是合并了这些复杂的生命周期,只需要这样：
useEffec(
()=>{在原先生命周期创建的函数中执行的东西,相当于ComponentDidMount与componentDidUpdate}
return {相当于componentWillUnmount})
值得一提的是useEffec的执行时机,每次执行useEffec是在渲染之后,所以()=>{}里的内容是会被多次执行,为了避免事件被重复定义,我们在每次在创建userEffec时,销毁之前的useEffec,由此useEffec和componentWillunmount还是有一些区别。
但如果是这样,我们每次setState都会引起组件的更新,就会破坏我们的预想的一些执行模式,也会影响性能。所以React官方也提供了第二个参数
useEffec(
()=>{在原先生命周期创建的函数中执行的东西,相当于ComponentDidMount与componentDidUpdate}
return {相当于componentWillUnmount},[状态数组])
当我们什么都没指定的情况下,任何更新都会引起我们函数组件的useEffec的重新创建与卸载。但指定后,React会对指定参数进行监听,我们指定参数发生变化的时候,组件会再次销毁useEffec并创建新的。
也看了下React推出的其他hooks,比如useRef,useContext,useReducer等等,但对于我来说,应用价值并不算太大，等要用的时候再细看。
再说下自定义hook吧:
自定义hook实际上并不是很高大上的东西,它只是我们的一种约定,如果一个函数内部使用了hooks,并且函数名以use开头,那他就是自定义的hook。实际上这种hook就是我们对React中hook的二次封装,在实际的项目当中,我们对一些操作的二次封装能够极大地减小我们的工作量。Do not repeat yourself。
昨天还看了下深入浅出Node.js.主要是buffer和Node的网络应用编程。
buffer实际上就是一种二进制的数据。在网络传输和文件系统中,我们都是利用buffer来传递的,在前端编程的时候我们很少考虑这些,是因为前端很少用到文件系统与网络传输。而Node提供了我们操作这些的能力,buffer的使用就不可避免了。buffer的连接很重要,它不能直接相加,那样会隐式转化成字符串然后出现乱码。正确的姿势是利用buffer.concat,数组拼接的方式。同时buffer支持的编码方式也是有限的,这种时候我们可以利用社区的力量下载一些第三方库帮助我们完成这些事情。
Node的网络应用也学过很多了。主要是TCP这块,因为没看过这块,这段时间在弥补这些基础知识的不足。但在我现在看来，TCP像是一个人给另一个人发消息说在吗,另一个回答在,然后这个人才开始说事情..等等
昨天也看了下mooc上的计算机网络,对于我们的计算机网络,它是通信技术与计算机网络的结合。实际上也是通信网络的特殊化——端也就是我们的host:都是电脑或是电子系列产品。它是由多级ISP组成,然后与区域网连接,当然对竞争对手也由IXP这样的交换网络保证全球网络的通畅。
昨天因为感觉任务不算太难，就先看了下webpack的运行机制和原理,还有一些用的比较多的loader与plugin。大概有这些:
- 优化方案
- 运行机制
- 运行原理
感觉webpack真的想深入还得下苦功夫,所以买了本深入浅出webpack.
后面继续看了下hook,主要是与class这方面的区别:
- 社区说这个也挺多的,无非就是那几个方面
- 性能
- this
- 类复杂
- 函数是第一公民
后面有杂七杂八看了许多,wobsocket,node.js之类的。
然后晚点就在写任务了,能够顺利运行了,然后开始改写,准备明天写完。
早上精神不好工作效率比较低,中午清醒了,晚上加了会班,把任务写完了。
玩了一整天
中午过来,写了下作业,发现自己写了一些没必要写的东西。然后看了下mooc上的计算机网络,然后就在看深入浅出node.js。然后geek组例会。
因为今天作业都写完了,过来就是主要在看书,总结node.js一些知识点——也算是费曼学习法吧。总之要做到有输入就要有输出。
其实很有意思,node社区的发展得益于Node模块规范的提出——Common.js，因为虽然Js在浏览器端有了很多标准的API,但对于后端来说,这一方面还是一片空白,主要存在以下几点缺陷:
- 没有模块系统——限制了Node.js去开发大型应用
- 标准库较少,只有定义的一些核心模块
- 没有标准的接口——没有定义过web服务器和数据库之类的标准接口（这个我也不是很清楚,因为没有接触过其他的后端语言）
- 缺乏包管理机制——这导致了JS中没有社区发展趋势,也没有自动加载和安装依赖的能力
在现在,Common.js已经逐渐完成了它的历史使命——正在逐渐被ES6 的 Module模块替代。当然,common.js并没有被扫进垃圾堆,而是与ES6 Module一起在为Node社区做贡献。
- 模块引用
var math = require('math')
-
模块定义
事实上,common.js在外层定义了一个module对象,当我们export一个属性的时候,这个属性就被添加到我们的module对象中。
//第一种方式,导出单个属性
exports.add=function(){}
//第二种方式,导出module对象
exports.module={需要导出的对象们}
//引入模块
let math = require('需要引入的模块')
math.引用的方法或是属性
-
模块标识
让用户能够不考虑变量污染,能够进行模块化的编程。
-
模块的引用
在模块的使用中,我们需要三个步骤：
- 路径分析
- 文件定位
- 编译执行
-
模块的分类
在Node中模块被分成了两类——核心模块和文件模块（用户编写的模块）,这两个的主要区别在于——核心模块已经被编译成二进制文件了,所以对于二进制文件不需要进行文件定位和编译执行这两部。文件模块则是需要完整的以上三个步骤。
-
缓存优先
模块化的推动意味着我们可以使用第三方的一些包与模块,而因此而推动了NPM包管理工具库的发展。而common.js也对包的结构与描述性文件进行规范。当我们npm init一个新的模块化项目（或者说是一个包）时,common.js要求我们对本项目进行一些必要性描述,主要包括以下几个字段：
- name —— 项目的名称
- description
- keywords——有利于做关键词分类搜索
- maintainers
- contributors
- bugs——一个可以反映bug的网址
- licenses——当前包使用的许可证书列表,表示这个包在哪些许可证下使用。
- respositories
- dependencies
- homepage
- os
- cpu
- engines——支持的引擎列表比如:V8
- builtin——是否是底层系统的标准组件
- implement——实现规范
- scripts
当然实际上我们去自己去开发一个项目的时候,并不需要这么多配置,有些字段是可选的,当你厌烦这些配置的时候,你也可以使用npm init -y来忽略这些要填入的信息。
//查看版本
npm -v
//安装依赖
npm init
//NPM钩子函数
npm run scripts<package.json里写的script>
//npm注册账号
npm adduser
//发布包
npm publish
//安装包
npm install
//管理包权限
npm owner ls
//分析包
npm ls
这个是因为企业需要,需要有模块中项目组织的好处,也需要考虑到模块保密性的问题。所以有了区域NPM,企业可以把NPM打包到这上面。
因为common.js是为了js在node中的合理运行才提出的,但在前端与后端的业务场景并不太相似。前端限制的是网络的带宽,后端限制的是你的cpu和内存等，而且common.js与Node异步的执行机制并不相似——它是通过同步的方式引入的。于是就有了Asyncchronous Module Definition 一个异步模块定义。下面是它的定义方法
define（function(){var exports={} return exports}）
值得一提的是,它的导出并不是像common.js一样是隐式的。
CMD是国内的玉伯提出来的,实现了AMD的一些优化。
ES6中module模块的提出,是对common.js的进一步升级,模块之争告一段落,ES module 正在逐渐取代Common.js的地位。而它相比于Common.JS主要有以下几个优点。
- Common.js是动态的,而Es module 是静态的。这是说common.js只有我们运行、编译后才能知道某个模块使用被使用——这意味着我们没法做代码静态分析。而Es module可以准确地判断我们模块是否被正确引用。
- Es module是对值的映射,而common.js只是对值的copy。这意味着我们无法从外部操作我们模块的值。
····还有想到再说
Node设计的基调就是异步I/O、事件驱动和单线程。在如今的时代里,Web应用已经不是单台服务器能够胜任的了。而对于前端来说,JS采用了异步的方式防止UI线程阻塞,但对于Node后端来说,如果不采用异步的方式,它完成多个任务的时间将会是m+n····,而对于异步来说就是max(m,n)。而Node则是首个将大规模的异步I/O应用在应用层上的平台。
它的优秀之处并非原创,它的原创之处并不优秀
当我们谈论起异步I/O和非阻塞I/O时，常常把他们弄混淆。非阻塞I/O是对操作系统来说的:当我们非阻塞调用后,操作系统会立即返回一个结果给我们,但我们没法知道它是否完成了,所以我们需要用到一种轮询的技术来看它是否完成了我们给它的任务。轮询这项技术也经过了历史的演变与进化:
- read.通过重复调用来说检查I/O状态来完成完整数据的读取。(浪费性能最多)
- select,通过文件描述符上的事件状态来判断它完成没有（有限制）
- epoll 现在linux下最好的事件I/O事件通知机制,进入I/O事件后,它会进行休眠。
而理想中的异步I/O是基于非阻塞I/O的。执行异步方法后,进行非阻塞调用,然后立即返回。在非阻塞调用结束后,返回数据给我们的回调——这是单线程中理想的异步I/O.但很多时候在现实中,我们是用多线程来模拟异步I/O而没有像理想情况下那样进行。一般我们在主线程中进行I/O调用,然后让它在I/O线程中运行(这个线程可以是阻塞I/O,也可以是非阻塞I/O),在执行完后再通知我们的主线程。
之前已经说明了异步I/O是基于操作系统的。对于Node来说的异步机制主要是由几个模块联合协作构成的：
- 事件循环
- 观察者
- 请求对象
- I/O线程池
对于Node来说,它异步调用后,会封装请求对象(相当于挂载到请求上的),然后把请求对象放到线程池里,进行I/O操作,然后结束后通知观察者。值得一提的是观察者是在事件循环里充当了服务员的工作——它会看看有没有相关事件的回调,当然观察者可以有很多，事件循环机制在每创建一个tick的时候,就会判断我们的服务员有没有新的订单(回调),如果有就执行回调。同时一个异步调用被执行后是立即送进线程池里,等待我们的I/O调用。可以说事件循环机制是针对异步函数的回调函数的。
当然也看了些其他相关的东西了。
有时候感觉像自己很浮躁.每天都想着进大厂,拿高薪.有时候学习都在想这个---想这个的原因也很简单,要决定考研还是工作了... 个人觉得自己还有很长一段路要走,不管是选择考研还是工作,长跑有时候坚持不下去了也得咬牙坚持对吧?
昨天就主要再看深入浅出Node.js,大概看了一章吧,然后就去看深入浅出webpack了,又看了javascript全栈工程师...many things
今天还是在写bugs-server和bugs-front的内容,差不多写完了吧
写完了bugs的内容,然后就在写服务拓扑项目的后端,感觉联表查太多了....感觉有点看不懂。努力写吧。
大家一起加班在写服务拓扑项目,就没什么了，感觉还不错。
休息了半天,晚上来和大家聊了下人生之类的。
继续写接口,找到点感觉了,快要写完了
调接口,联调接口,改接口
调接口,联调接口,改接口,然后搞的差不多了吧，然后bugs-front和bugs-server那边又来了任务,准备继续搞那边的任务
写bugs-front和bugs-server,还有分页与服务端的筛选没完成
写完了bugs-front和bugs-server,不过好像还是有点问题.等老师帮忙解决吧
打了一天的英雄联盟,生活的节律真的很重要,如果失去生活节奏,就是堕落的开始。