从2024年1月初到2月底为止,由本人伪装其他经验段去面试收集的来。面试城市在昆明、贵阳。前后一共差不多20家。其中三家大公司,其他都是中小型公司。拿到的offer薪酬也不是很理想,有几个规模比较大,比较理想的公司也是平薪甚至降薪拿到的offer,当然跟我本人自身的三脚猫功夫有关。
整体大环境不是很友好,特别卷,各位靓仔靓女简历里的项目尽量不要带有电商系统,后台管理系统的字眼,很多hr,面试官看到3年经验,项目是某某电商系统,某某后台管理系统直接就否了。
这方面没有一个非常官方的标准答案,每个公司规模政策都不一样,因地制宜才算经验,才能体现能力。也没有什么一两句话就可以让实力突飞猛进的技巧,所以我也放在了最后。总结了一些要注意的点。
1、回答问题时候,思路要清晰,不要扯蛋说了半天说不到重点,这里需要提前准备一两个项目,优缺点,为什么这么做,解决什么问题,达到什么效果等等,然后不断优化文案。
2、面试(二面,非技术面)的最终目的是进行画像,比如对你入职后能胜任什么工作,积极性,能给团队带来什么贡献,所以这方面回答,根据公司情况表达出你的善于沟通,技术能力,效率高,并且稳定就可以了。不要太浮夸,适当表现出真实情况,可以用想要稳定的工作,买房等拉取亲近感。记住面试官也是人,不要害怕!要自信!
可以在回答问题得时候侧面吧要想要传达的点表达出来。常用公式就是:比如我的xxx,举个例子:xxx ,我说个实际项目的例子xxx。比如面试官问你是怎么解决问题的时候,除了阐述如何解决问题还可以衔接比如我做xxx项目时候,我一个人推动的,就遇到了xxx问题,我就通过这种办法解决。(这时候你就可以把你想要表达的执行能力很强等优点给侧面传达出去)
我目前自我觉得我处于优异的执行者,目前所在瓶颈是怎么成为团队核心,比如怎么通过影响和带动他人,帮助团队获取更多成果。一些名词可以根据情况替换,比如团队核心,可以替换成技术支撑等
需要传达的内容:
技术特长:
怎么突出重点,让自己更有吸引力
避免
举例:
面试官好,我叫汤姆丁,拥有3年前端开发经验,其中有将近2年带团队经验。是实干型开发选手,vue/react等主流前端框架业务开发是完全没有问题的。node,python搭建简单的服务端写接口也是没问题。node的话使用egg,Sequelize(斯Q奶)。python的话用flask这些框架开发服务端。目前工作约20%左右在团队管理上,80%左右还是业务开发。技术上较大的成果就是,把公司业务梳理一遍,使用微前端重构。团队管理上除了技术规范,还有文档沉淀,每月复盘,提测规范等等这些流程的完善。
除了常规的资源优化,体制压缩,gzip,懒加载这些,让可以在nginx那开通一下http2,还有根据业务做一些缓存,使用indexdp。其实这些难就难在怎么定义指标,进行业务,代码逻辑层面的优化,才是难点。我初步是打算Lighthouse配合 sentry 来指定一个流程。比如首页多少秒打开合格,弱环境下要多少秒等。如果有动画是要多少帧等,因为帧数是关电脑hz的,跟配件有关。
Vue采用数据劫持 结合 发布者-订阅者的方式来实现数据的响应式,通过Object.defineProperty来劫持数据的getter、setter,在数据变动时发布消息给订阅者,订阅者收到消息后进行相应的处理,通过原生js提供的监听数据的API,当数据发生变化的时候,在回调函数中修改DOM。
缺点:
一次性递归到底开销很大,如果数据很大,大量的递归导致调用栈溢出、 不能监听对象的新增属性和删除属性 无法正确的监听数组的方法。要使用$set
除了语法,api,比如setUp,最大的不一样就是双向绑定从vue2的defineProperty改成了proxy,可以监听数组了,弊端是ie8之类的低版本兼容问题
闭包本质还是函数,通俗来讲就是把操作函数暴漏出去,然后细节放在内部。避免污染,增加安全性。简单举个例子,函数a里面定义一个函数B, 外部一个变量引用了函数A,就创建了一个闭包。现在很少用了,因为会占内存,用不好还会造成内存泄漏。比如vue中的数据劫持observer就用到了闭包
他的本质还是对象,但是呢有个上下文,是用他来创建私有变量拿数据的,不同地方调用方法,this.xx就拿上一个。继承等等。反正这么处理的根本原因还是不想做全局污染。因为现在mvvc框架原因,业务上很久没有单独处理过这个了。
除了常规的懒加载,还有keep-alive缓存组件。更多需要多使用函数式组件,还有不要设计太深的响应式数据。组件的颗粒度不能设计太细.,v-if-for不要同时使用。
computed有缓存功能拿不到this,watch主要是监听data里面的定义的量多个属性影响一个属性时,建议使用 computed。 价格,根据订单数量,优惠券等,显示价格当某个值发生变化,引起一系列的业务时,建议使用 watch。 比如input搜索,请求接口(记得做防抖),渲染列表。就可以监听input Value值。
vue3整体下来感觉更贴进react那种了,比如定义数据使用ref,不再用this.data 还有setpup可以划分逻辑,也支持jsx了
以前用shouldComponentsUpdate里面做判断,return false等。现在基本用hook,useMemo。useCallback。
useMemo场景:父的state变化,用useMemo可避免子重复渲染
会,让他不会的就用useRef作为useMemo的依赖
roadhog 是基于 webpack 的封装工具,目的是简化 webpack 的配置 umi 可以简单地理解为 roadhog + 路由,思路类似 next.js/nuxt.js,辅以一套插件机制,目的是通过框架的方式简化 React 开发 dva 目前是最纯粹的数据流,和 umi 和 roadhog 之间并没有相互的依赖关系,可以分开使用也可以一起使用。
住要是避免重复计算,增加性能。因为react用到的是diff算法,吧树形结构按层级分解,只比较同级元素。所以列表,循环时候要给个key。
把树形结构按照层级分解,只比较同级元素。所以需要给列表结构的每个单元添加唯一的 key 属性,方便比较,节约性能。基于这个,开发的时候可以重写 shouldComponentUpdate 提高 diff 的性能。当然现在大部分是使用useMemo。useCallback。去优化了。
JavaScript中的map不会对为null或者undefined的数据进行处理,而React.Children.map中的map可以处理React.Children为null或者undefined的情况。
高阶组件本质还是组件,只是一个包装了另外一个 React 组件的 组件。可以通俗理解成,一个函数里可能有好几种组件。这种形式通常实现为一个函数,本质上是一个类工厂。运用场景,多个组件都用到同一段逻辑时候,就需要吧共同逻辑提取出来,利用高阶组件的形式将这段逻辑整合到每一个组件中, 从而减少代码的逻辑重复 。
需要代码重用时, react如果有多个组件都用到了同一段逻辑, 这时,就可以把共同的逻辑部分提取出来,利用高阶组件的形式将这段逻辑整合到每一个组件中, 从而减少代码的逻辑重复 。又或者需要组件增强优化时, 比如我们在项目中使用的组件有些不是自己写的, 而是从网上撸下来的,但是第三方写的组件可能比较复杂, 有时不能完全满足需求, 但第三方组件不易修改, 此时也可以用高阶组件,在不修改原始组件的前提下, 对组件添加满足实际开发需求的功能
有井号没井号,一个是用window里面的pushState一个是用onpopstate做进退
好处就是不用管this了,谁调用就是谁的上下文,不能使用new,没有arguments,也没有原型和super等等。
重排:渲染树中的元素结构,尺寸、属性这些发生改变时候,浏览器就会重新渲染。
重绘:页面某些元素发生变化,浏览器就会对元素进行重绘,比如background这些。如果是opacit既出发重排也出发重绘
强缓存就是根据header的字段,Expires和Cache-Control来判断是否过期再请求服务器,坏处就是服务器更新了,如果还没过期就会主动请求。而协商缓存就是从服务器判断是否重新请求。前端你可以在头部meat标签设置,多少秒刷新文档等。作用就是对http请求缓存,减少请求次数,达到优化效果。
防抖:让 事件 在触发后 N 秒后执行,如果在 N 秒内重新触发,则 重新计算 时间。input的搜索等
节流 : 在规范时间内,只能触发一次函数,如果多次触发不会执行。比如支付按钮等。
浏览器的事件循环:执行js代码的时候,遇见同步任务,直接推入调用栈中执行,遇到异步任务,将该任务挂起,等到异步任务有返回之后推入任务队列中,当调用栈中的同步任务全部执行完成,将任务队列中的任务按顺序一个个推入执行,重复执行这一系列的行为, 异步任务又分为宏任务和微任务。
宏任务: 任务队列中的任务称为宏任务,每个宏任务都包含一个微任务队列
微任务: 等宏任务中的主要功能都完成后,渲染殷勤不急着去执行下一个宏任务,而是执行当前宏任务中的微任务
宏任务包括:执行script标签内部代码、setTimeout、ajax请求
微任务包括:pormise、MutonObserver、Object.observer
最稳妥最常见的就是服务器开允许访问。剩下就是jsonp,现在很少了每个接口都需要特定处理,一般都用反向代里,proxy这些。我们目前是采用node中间件进行转发。跟nginx反向代理差不多。当然C端的项目原则上是不允许跨域的。而且生产环境也是全部关闭,安全性问题。真需要跨部门也是通过接口去处理,比如小程序内部打开h5进行下单之类
其实我觉得最大的困难有亮点,第一人才培养,第二就是达成共识。第三文档沉淀。1和3都很好理解,字面意思。第二点达成共识呢,我举个理想的场景。整个团队大家都有明确目标,然后一起使劲往同一个方向前进。又比如领导有需求下来了,大家能明白这个需求的意义,而不是单纯的完成任务。大概就是这种感觉。
我为了完成上面三个几个目标,做了以下几个措施:每月(项目)复盘,多写注释,拆解需求。复盘包获代码量,还有收集遇到的问题,还有一些技术方案收集。当然代码量不是越高越好,越高就证明复用性可能没做好就帮忙深入去看看。因为组员性格情况可能不同,所以这些可以线上进行。然后再整理一下变成文档沉淀下来。踩过很多坑,分享啥的,最后组员都不积极,采用这种,然后偶尔写写文章。当然根据每个人性格采取
然后就是需求拆解了这个,举个最简单的例子,产品那边的需求不单单是怎么做怎么做,整个项目有背景的需要说明,然后我会协助拆解成任务,比如登录页,为什么用短信短信验证码,为什么使用按钮要隐藏起来,因为我们只想要客户买,不想让他用等等。当然是极端例子哈,一些简单常规的肯定不讲了。这样拆分后呢,时间评估就准很多了,因为所有都有个对比,比如登录页一天,商品列表页更简单应该半天就好等等。效率自然就高了。
当然还经历很多,都是一个大前端团队去接任务,后面慢慢改成分成业务组,当然这些我一个人肯定处理不来,需要总监他们协助。反正很深的感悟就是,这些没有标准答案,也没想像中发发任务,故时间,开分享会这么简单。要因人而异,因地适宜
因为之前公司好几个后台管理系统,每个管理系统都有相同的功能,这样维护起来费时费力,所以我重新梳理了业务逻辑,使用react/umi搭建项目,利用git submodule去维护跨项目之间共同的代码方法。使项目更清晰明了,维护成本大大降低。
最大得亮点还是在业务梳理,推广微前端这个。遇到
核心原理使用react-dnd这个,然后呢一开始的理想是很丰满的,颗粒度非常小,后面越做阻力越大,比如一些层级,如果用定位的话,不好维护。最后是我们跟产品制定好规则,分两一种,一种是页面模板,一种是组件,比如banner,导航栏,可以选择样式类型,然后自己拼成页面,导出来的是一个数组,如果需要后台会生成对应代码,单独部署,就是先去仓库拉去模板代码。然后利用node-fs编写配置文件。再把整体项目打包出来,或者根据钩子,生成到gitlat上。这种场景多半用于需要单独部署维护的项目,比如是某个客户买了我们产品。需要独立部署
其实还是需要回到人才还有达成共识上面,我做的每月复盘,都是曲线救国,如果他本人不愿意或者摆烂的,就需要指定好情况,当他当作单一的生产单位。然后怎么让技术部门逆推去推动商务,就是赚钱。
技术上面的话因为不是开发框架又不是手撕底层原理这种,相对棘手的还是类似指定性能优化这种需要根据业务制定,但市场又没有很完善很开源的产品。这种就比较复杂。
------答案2适用于非管理------
我个人执行力还有业务开发是完全没问题的,目前的瓶颈在于怎么把个人的能力扩散到团队中,影响和带动他人,为团队带来更多结果和更高收益。
app: 19还是20年把,setupWebViewJavascriptBridge ios升级,要区分安卓或者ios特殊处理,低版本兼容。
A标签包裹图片,不用A标签的href跳转,点击事加进行window.location.href跳转没出发
一般攻击手段有xss,csrf,DDoS.xss现在较少了。一般就行方等严格项目有要求,我们都是用转义方式来避免xss攻击。csrf得话采用token,DDoS是服务器那边得,一般采取ip禁止