// 优点：积极主动，学习能力强
// 一、头脑清醒，思路清晰，遇事沉着冷静，能分清事情的轻重缓急。// 比如遇见紧急问题，有着条例的分析能力，抽丝剥茧的解决问题
// 二、除了分内外，能发现问题，并积极主动做达到。如hrdata发现移动端问题，本质是高效获取信息，帮助产品理清思路，助力业务
// 三、本人适应能力强，且求知欲也很强，能够不断的学习、上进。适应能力，转岗到xx后，通过一两次高质量的分享快速融入团队，融入集体，业务上通过五视图方法论快速上手业务
// 四。学习能力强,比如写书，吸收基础知识，扩展出很多深度分析，深度案例见解
//
// 别人如何评价我？
// 随和，值得信赖，有始有终，技术视野广，技术深度强，在组里是React专家，都来请假我
// 缺点是：
// 要求下面的人也和我一样，在别人视野不够，不理解我的时候有点着急，做不到我就事必躬亲，没有让其他同学做
// 规划是：
// 业务上，深入业务，影响业务
// 技术上，技术广度，技术深度的提升，通过技术架构等手段保证业务质量效率性能的提升
// 我的成长历程：16年7月研究生毕业，1-3，而后每年升1级的速度，升2-1，升2-2，而后到成都升级2-3，3-1.，做的打印，帮助商家，做的基础框架，支撑30+人团队高效业务迭代，支撑了600加页面
// hrdata的方面，支撑移动端，理解业务特点做框架，帮助开发团队提效，做产品认知升级
// 我的业务能力是收到认可的，去年8月转岗后接手的业务秋季名额极少的15%特调
// x2也是很关注业务的，在hrdata业务特殊时期，也是经常需要汇报的
// 其他的一线大厂，中厂都在面，有offer在谈的，有还在进行中的
// 领导很发散，领导了6个大业务方向，而且很信任我，做了几个技术任务，对我来说也是好事，但是铺得太广了，我希望更多在业务上理解业务，帮助业务，更多的解决我的业务痛点。
对业务能胜任，理由如下：
1.技术广度，深度足够
2.有着一定的业务敏感度
3.除了业务外，还能主动发现问题解决问题
最能概括你自己的三个词是什么？
学习能力强、适应能力强、敢于担当
如何理解业务？
业务是一系列行为的集合，最终体现在用户上，广义的用户包含b，c，g（government），d(开发)等
业务的目的是解决用户的需求，或者解决用户的痛点，更抽象来说即为助人，并在其中找到商业价值，经营和生意的意识
举个例子，框架，React解决了开发者快速开发UI的需求，SaaS系统解决了店内高效经营管理的需求，技术都是为业务服务，创造业务价值，我的理解就是通过工具（通过自己手里的生产资料）来助人，并在其中找到商业价值，
saas业务服务的用户是店内商家，解决的问题是店内经营效率低的问题，带来的价值是提高店内经营效率，帮助商家决策，辅助解决问题
打印票据例子，票据会被蒸笼盖住，降低了店内经营效率（厨师无法看到信息），分析本质需求：是看到票据信息是本质需求，达到本质需求有2种路径，一种是
把票据的字段放在下方，做个开关这样可以通过开关看到下方的文字信息，第二个路径是允许字段的灵活移动，字段的多个增加。在两个路径中，我推崇
第二个路径，第二个技术路径除了解决现有问题外，更能对长远产生影响，因为无法预测字段会被覆盖多少，第一种方案可能只能解决一小部分问题，当票据被蒸笼压得多的时候，一样存在问题
并且第二个路径对长远会带来影响，比如用户希望调整其他字段顺序，增删字段等
HR报表业务是人力业务范畴，业务服务的是公司的BP，招聘经理，管理者等。解决的问题是提供了组织的，人的数据事实，通过信息的高效获取辅助公司人员进行决策，带来的价值是公司经营，组织调整，人员调整的依据，
最后为公司的经营和战略服务
举个例子：会查看一个组织（部门）的人才梯度，年龄梯度，工龄梯度，男女占比。从人来看，人力成本，人力绩效，人员招聘，薪酬，培训，发展，轮岗 晋升。
对培训这个例子，培训1000人，培训完后对绩效有没有帮助
hr业务的招聘，人员分析，入转调离，人才发展，办公效率
招聘：人才供给分析 招聘漏斗
人才分析：序列
业务和技术？
1.从数据，移动端例子
2.从规划
3.从调研
4.从本质，业务本质
不要局限在前端能做啥，业务是啥和前端没关系，先充分理解需求，再去考虑技术
5.从人员间，增加产品认知
调研，充分理解了需求，想到下一步，一起讨论，帮助产品理清未来的思路，探讨发展的路径
信息的高效获取，是本质需求，这个透视表为目的地，有2个路径，产品的路径是公司的表格A组件，然后就是合并单元格，给产品建立交叉表的认知，提供B路径到达，交叉表，行列交换，列求合，列求均值，单元格合并求值
从当下看解决了表格合并单元格等问题，长远看，为专业的交叉表铺路，最重要的是是符合业务发展的，根据公司的特点，也是产品沟通过
根据业务需求改了图表
6.从业务特点，来理解
业务的本质是要满足bp等用户的看数需求
我的看法，hr报表业务是一个多而杂的业务，对招聘培训这个例子，招聘1000人，假如计划的是12月底，但是一直招不满，就会拉招聘面试的数据做成报表来分析，
又比如对于培训的例子，培训了1000人，培训完后对绩效有没有帮助，可能需要拉培训前后的绩效对比来分析培训效果
理解到了业务多而杂的业务特点，需求，业务需求是横向扩宽，建立普通看板
在面对多尔杂的业务背景下，我的目标是快速帮助技术团队响应业务需求
用户侧：通过策略模式，应用不同的process策略，能提前帮用户处理好，也可以用户自己实现
元件尽量只关心ui
体现里式替换，用baseUnit的接口，实际上传入的都是具体unit,第二个如果某个场景的代码复用既可以通过类继承实现， 也可以通过对象组合实现， 尽量选择对象组合的设计方式
设计思路，设计单一职责的元件，通过组合生成复杂元件，通过children和middleware构建复杂元件，children是子字段，middleware是中间件是增加能力，
比如series的label是children,比如lable的格式化formatter属性通过格式化中间件enhancer引入
比如barseries有多个属性，通过中间件引入，中间件是一个装饰器
用户引用复杂元件,不引入单一元件，复杂组件其实是一个中介者，复杂组件与单一组件的组合构成组件树
开闭，对增加扩展，对修改关闭
所有元件都继承BaseUnit 抽象类,需要实现render方法，对于目前render方法返回需要实现得和echarts的api一致
通过组合形成复杂的echart opition
数据处理通过chart的处理逻辑注入抽象的ds,各个unit的 render能够通过抽象想ds获取到需要的数据
各个unit都定义了静态的shcema,用于整体schema的组合
在生成shcema的阶段，使用visitor模式，遍历所有的unit,获取到每个unit,children和decrator的schema，然后组合成整体schema
打印是怎么做的：
票据三类
使用react-dnd
做组件嵌套
声明一个中介者，来沟通左侧组件区，中间画布区，与右侧属性区
交互上，使用命令模式，dispatch出一个命令，接受区使用一个数据处理工厂，处理数据
底层数据上采用xml,合并，块拖拽，列交换，行交换
pm票据编辑工具
设计模式面向对象：
创建型：工厂方法，抽象工厂，创建者，单例，原型
结构型：适配器，桥，组合，装饰器，代理，门面,享元
行为型：职责链，命令，itertor, mediator（中介）,解释器,memo,observe,state,strage,templabe method,visitor
route用了啥，5个，职责链，门面（history.push）,observer(观察者), 大量装饰器，命令模式（pushState）
微前端用了啥？：2个门面模式，生命周期mount,unmount,update,render,组合（dom树）
打印的发展：pm化
微前端的发展：性能的记录，复用的体现，各模块的调用结构体现
solid：单一职责，react下组件能抽出去函数，就不是单一职责的，逻辑与ui分离就是单一职责的体现
，开闭(通过装饰器，hoc等)，里式替换（比如组件中，父组件接受a,b,c替换成子组件也应该能接受a,b,c），
接口隔离：一个组件接口应该明确，不要...prop展开，如果不隔离，其他的接口传入组件
依赖倒置抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对抽象（接口）编程，而不是针对实现细节编程。
hook:依赖导致，应该针对抽象编程，而不是针对实现
迪米特法则：不和陌生人通信
www.everydayreact.com/articles/so…
如何理解函数式：
优缺点：肉眼不可见的ifelse,for，安全的异常捕获，并发安全，无副作用，可复用
可扩展性--我是否需要不断地重构代码来支持额外的功能？
易模块化--如果我更改了一个文件，另一个文件是否会受到影响？
可重用性--是否有很多重复的代码？
可测性--给这些函数添加单元测试是否让我纠结？
易推理性--我写的代码是否非结构化严重并难以推理？
以上都可以通过函数式
声明式编程-面向抽象，不是面向实现编程，不关心细节
纯函数-无副作用，如document
引用透明-引用都是可见的
不可变性-immutable，不会muta源数据
使用纯函数的代码绝不会更改或破坏全局状态，有助于提高代码的可测试性和可维护性
函数式编程采用声明式的风格，易于推理，提高代码的可读性。
函数式编程将函数视为积木，通过一等高阶函数来提高代码的模块化和可重用性。
可以利用响应式编程组合各个函数来降低事件驱动程序的复杂性
1.组成 由两部组成，代数类型，和操作。
1.1：代数类型：最上层是范畴学的抽象范畴，其中代数类型有一系列规范，javascirpt的一个规范叫fantasy-land,规范中有functor也叫函子，apply,applicative,chain,monad,semigroup,monoid等
其中function是一个容器，容器能装一个值，有一个map方法，这个是基本的代数规范，apply规范是需要基于functor规范进行，实现了ap方法,chai,applicative继承了apply,实现了chain,of方法,monad继承了
applicative,chain，也就是说实现了monad的应有map,ap,of,chain。chain能扁平展开functor，map能做指的态射，ap能保存函数
在定义了代数类型后，市面有很多规范的实现,比如sancturay,fluture等，定义了常用的代数类型，比如maybe,either,task（异步），maybe,either能处理空值，或者validator处理多个空值
通过maybe等方式来判断值的存在与否，可以链式串联下去
通过either来把错误数据传出去
1.2: 操作常用如ramda进行函数式，提供了很多utility，依赖hm描述，比如mapProps,可以描述为 prop->props,而React函数式是props->element,故而
可以通过export default R.pipe(tranformProps,Component)得到新Componet，其中tranformProps可以用Ramda的比如evolve进行
或者直接写const mapProps = R.curry((mapping, C) => R.o(renderComponent(C), mapping));
另外比如ifEles,cond,ramda都有提供，可以避免if
compose的本质：最后一个函数的入参可以有多个，然后后面的组合入参必须是一个，这是由于函数的return只有一个值，单值组合
Ramda里面compose从右到左，也可以pipe从左到右
curry的本质：把函数降到一元，x=>y=>z 方便function等的装入(单值），functor映射，单值映射，以及ap操作ap一个functor（funtor也是单值）
1.3 心智模型，用法,push的用法，让数据发生在未来，而不是主动call数据，如rxjs就是函数式思路，promise也是push思路的一种体现
1.性能
为什么需要hook?
为了能在function上补齐能力，并且向function过渡
从设计上来讲：react函数式设计，ui=f(state)
从DX来讲，react class有hoc嵌套，render回调地狱等问题，并且逻辑散落在多个生命周期中，不相关的逻辑在一个生命周期内，样板代码太多，this指向
从构建角度来说，react class构建出来有很多样板代码，为了class引入了很多polyfill
从内存来说，每个reactcass 都有一个实例
从研发视角来说，更能以effect视角看问题，不需要willreceive等
性能优化：
指标收集：performance，fmp算法，web-vitals,自定义打点、埋点,首屏css
指标分析：跳出率，转换率
基础优化：网络，缓存，servicework,图片，包优化，异步包 http2
框架优化：react 少render,useTransi,useDeffer,immer数据共享
内存优化：canvas减少doM，webgl，webgpu，虚拟列表
体验优化：scroll合成层，mouseover提前加载资源
架构优化：ssr,服务端流式渲染
多端优化：离线包，预加载
如何处理性能问题
1.1基础：webgl / canvas减少dom（开启合成层硬件加速），http2，网络缓存，webworker,sevicewoker,接口合并，数据分片，webassembly，虚拟列表，SSR，首屏css，构建上，运行时上，用permanceObserver做paint,lcf,first-input，event,longtask监控，提升合成层（但不能乱用）content-visibilty等,用mouseover提前prefetch,在服务端流渲染,打包渲染，如全栈框架remix，
gzip,图片webp，懒加载，indexdb中jscache,css cache
再客户端方面，然后可以扩展到服务端方面
1.2框架上：React
数据：immer大规模数据共享内存
用法：usememo，usecallback等
工具：React Fiber render监控render
未来：useTransition(react router 顶层setlocation的时候可以用)，userDeferVal（组件的rennder教复杂时可以用），Server React Component，Server Stream Render（React 18）
1.3 架构上
空间换时间，
中断设计（Fiber）并发
做好分层，防腐？？
1.4多端
1.预加载
2.离线包
1.4设计上
no rumtime solidjs,sevlte
2.质量
1.静态检查，lint
2.动态检查，（如重写window）
3.CI/CD 持续集成
4.上线流程化
5.强ts类型
6.研发范式（如表单，报表）
7.研发框架
8.CR
9.测试，单测，集成，e2e测试
3.效率
1.低代码
2.研发范式
3.业务理解，预判，提前建设（短期加班暂时性解决，不是最终方案，若业务规模扩大10倍，建设基建支持）
（Q：对低代码有什么认知？）
A：垂直领域做可扩展的低代码，低代码不是银弹
4.项目总结
Q：产品能力/技术产品能力
A：数据，访谈，市场调研，分析报告
Q：如何服务好一个业务？
A：
1.理解业务：了解业务现状，服务人群，角色，使用习惯
2.建设各项埋点，收集指标数据
3.业务代码整理，逻辑架构等五识图
4.痛点领域专项
5.发觉业务数据隐患，通过技术反哺业务
6.适当给产品输入，建立技术认知
7.产品技术都导向业务需求，同一目标业务增长
Q:一个新业务，如何开展？
A：通过架构五视图，每个识图描述一个方面，最后总和起来形成业务的技术支撑。逻辑架构（分层，微内核，DDD），数据架构（内存数据定义，数据流描述），运行架构（运行时描述，模块与模块间），开发架构（用的什么开发工具，mock怎么来的，文件结构如何，开发仓库分布，用什么技术栈），物理架构（部署架构）：cdn 分布，容灾设置，灰度，ng，node。
Q：目前在负责的项目，什么角色
背景：关于部门，关于人的报表，关于公司运作。招聘，招聘周期，人才结构，入转调离，部门概率，员工明细，办公考勤，评估发展，服务于bp，管理人员，有一定突发性质。
然后一来到，先打点收集，评估页面，技术推动低成本做了页面移动端适配，拿到了一定结果
过后在前端开发过程中，发现目前的人员配置面临压力，一周5报表的压力。开发模式是不断硬编码开发，只能承担一周2报表，结果是只能砍需求或者加班。
问题：如何提高研发效率
然后看到报表的趋同性质，都是筛选器，图表，计划封装报表数据流与组件，转变一下报表研发方式
以封装的思路
数据流上：底层做了数据流的json描述，上层做了json的驱动（json怎么转到驱动上），最上层计划做可视化低码
组件上：对图表组件研发进行了约束抽象：etl,olap（补齐）,ui三层，excel内存结构与心智模型
图表定义了axis,tooltip,label,grid等，希望任何图表都能通过这个接口能描述出来
结果：编写报表只需要按照既定的约束写数据流，然后组件开发只用开发数据处理逻辑，能承载一周5个简单报表压力
遇到数据流方案的选取问题：
在数据流的选取上，没有用hook，用hook就开了一道扣子（1.不经抽象的fc,fc内代码越来越多，逻辑越来越臃肿，2.不经优化不按规范书写的hook，一些场景会导致组件逻辑的混乱
），一个function会非常长，我们认为报表页面是遵从model与ui的形式，业务逻辑都应该再model里面，UI负责纯展示，我们定义的json就能指明一个model.。选型上调研了rematch,easy-peasy等，由于rematch的computed，注入的能力需要pluggin的形式，需要配置中间件，不够开箱即用，我们选取了更开箱即用的easy-peasy（easy-peasy,zustand,rematch对比？）computed injection immer
对于复杂报表，更多复杂在数据流与联动逻辑上，我们数据流采取硬编码，组件研发思路还可以采用三层思路
规划：然后看到未来报表的无序与大量（为什么无序），计划做BI工具，思路策略是复用sdk得到基本的取数能力，再自研行列权限管控，再把图表组件集成到BI工具中
第二个做低码
结果：编写报表只需要按照既定的约束写数据流，然后组件开发只用开发数据处理逻辑，能承载一周5个简单报表压力
HR报表，HR报表业务前端负责人，对报表研发体系进行了设计（需体现设计能力），体现在2个方面
1.数据流
2.图表研发
解决了人力的问题
Q：怎么解决的人力的问题
1.数据流研发范式-----定义DataProvider等数据流单元，描述筛选器-数据-渲染流程，无需复杂的接口代码
使用了easy-peasy 做业务逻辑与UI的解耦，easy-peasy是一个"电池包含的"状态管理，具备computed，injection,thunk等功能，不需要通过插件引入这些功能
为什么不用hook，1.不经抽象的fc,fc内代码越来越多，逻辑越来越臃肿，2.不经优化不按规范书写的hook，一些场景会导致组件逻辑的混乱
2.图表研发范式，定义ETL，数据加工，图表UI三层，ETL做数据清洗，如年龄校验，数据加工层做数据处理，方式是内存中维护多张Excel 表，在Excel 中计算，计算的结果给到UI层，UI层定义了图表的抽象描述如，使用组件模式组装，底层再映射到如Echarts ，d3等。在各层能分层实施，在UI层能快速组合。
过程中遇到什么问题，如何解决？
jsx组件如何静态化：组件静态描述生成，在项目进行过程中，需要将UI组件静态生成一个组件树的抽象描述JSON，不改变组件代码，类似umi自动生成文件，生成一份组件描述给到三方组件（属性面板）消费
通过组件的static静态方法,在静态过程予以调用，静态过程使用ServerRenderToMarkUp，静态构建出组件树的JSON描述
结果：2正式员工到1正式+1外包胜任
Q：你在xx比较满意的事？
A：发现问题，定义问题，解决问题
一。发现/证明问题：体验问题
1.发现有用户截图反馈移动端打开PC报表，打点收集数据，ua，屏幕点触，停留时间，访问页面等
有3%的移动端且有明显点触与停留的访问，访问时段在非工作时间，页面集中在数据概览页
2.用户访谈，用户习惯在非工作时间用手机，场景收集，在外，吃饭，恰好使用手机，按照时间占比，用户大概30%几率使用手机简单看数
3.调研，竞对做了适配，甚至有竞对移动端访问量接近50%
4.产品规划，未来的推送类链接约20+，现有人力如何做好应对
二。定义问题：主要矛盾是链接在移动端打开体验，次要矛盾是未来的业务增长现有人力如何满足
三。挖掘本质需求：无论主要矛盾，次要矛盾，本质是用户随时随地看数需求
四。解决方案：awd,多端开发，rwd,响应式开发，选用响应式开发，理由：人力节约，再在具体场景做pc,移动端分叉组件
存量页面使用顶层框架遍历dom，改变css
五。结果：技术推动上线解决了移动端的打开体验
Q：你在xx不满意的事
A：组织架构
Q：你在xx满意的项目？
A：SaaS项目的微前端
Q：解决了什么问题
A：解决了类Chrome交互下的中大型SAAS后台维护性问题
（Q：怎么做的？怎么体现出难度）
A：用分治手段来增加可维护性
从五识图来描述
SaaS项目的微前端：
背景：类Chrome交互下的中大型SAAS后台面向商家 有大量页面提供餐饮经营服务管理，报表，营销，供应链等，每个类目种类繁多，业务流程复杂，这些业务集中在一个系统，顶部是大导航，左侧还有菜单导航，此外还有一个chrome页签系统。为了解耦，使用了微前端的架构，各子应用独立开发，互不干扰，便于各模块独立迭代与维护
微前端运行时有2个问题：
沙箱怎么嵌入：调研了qiankun,icestark使用xhr+with的形式，一开始也用了这个形式，但是一直觉得不够优雅，一个是需要xhr取脚本，脚本万一不支持跨域怎么办，二个是取到后还需要eval，这样太耗费性能了，需要在已经做好词法分析语法分析后，还要eval再来一遍
这一系列流程下来，性能会受到影响，最后换了一个思路，用jsop的思路，将运行时的代码放在一个闭包内，所有的变量获取，如window，都取到的是闭包内的window，最后通过perfamert.mark打点，快30ms，带来的代价时子应用需要引入一个构建插件，插件会给生成的结果外再包一层jsonp调用。子应用导出怎么获取，使用note,再get，note一个沙箱变量，再获取一个沙箱变量
keep-alive怎么做，react-router,react都没实现，简单的使用react-router满足不了要求，背景是要满足chrome页签模型，缓存，remount,unmount等，如何能满足调用简单，扩展性强，不打扰到开发习惯，又增强了系统能力，还有一定的扩展能力
扩展了3类跳转方法，支持20+人次稳定高速迭代600+页面，满足了3个chrome底层能力，插件化hoc,enhances满足了业务多样的导航，跳转需求，支撑了6-7个扩展能力
逻辑视图：微前端体系，主子逻辑视图，路由插件
底层：微前端
插件：路由插件
上层：子应用业务模块层
运行视图：沙箱，路由加载子项目，动态css，dll……
开发视图：monorepo，并保留大多数研发习惯
数据视图：hook
部署视图：构建，灰度
（Q：怎么体现出解决问题的能力）过程遇到什么问题（过度到路由），怎么解决的？
A：
路由是分研发习惯和基础能力，在通常情况下，路由能力是够用的，但是在中大型saas系统上，路由能力不够了（怎么不够用自己展开），那么
1.如何在保证研发习惯情况下，增加路由能力？
2.如何保证良好的扩展性，支持其他业务的接入，并满足业务过程中不断变化的路由需求？
设计了2层次
路由能力层（解决问题1）+路由插件层（解决问题2）
通过路由能力层，满足业务需求（chrome模型）：保留路由写法研发习惯，以此扩写路由能力，获得Route的unmount,remount,cache能力
具体做法：Enhance history，扩写Route，配置化路由
通过路由插件层，满足路由，扩展能力，横向扩写history，纵向增加消费context的HOC。插件具体的应用：页签，页签栈，生命周期回调，跳转确认，滚动恢复等具体举例
具体做法：横向Enhance history，加入如中间件机制，纵向提供如消费context的HOC，增强组件能力
整体结果是啥：
支持20+人次稳定高速迭代
回头来看，怎么做更好？
主要在微前端上：使用模块联邦，web components等方式，来思考微前端
模块联邦对构建更友好，web components更模块化
5.技术问题
js基础
React
状态管理
事件循环
webpack
微前端，qiankun,icework,alf,字节magic
路由
ts
css
6.算法/js
手写bind，promise，lru,immutable，回溯，动态规划，二(多)叉树
