朝花夕拾

技术终面&hr面

20 min read

设计模式

  1. 单例模式 概念：又被称为单体模式，是只允许实例化一次的对象类。 使用场景：1、全局状态管理；2、管理命名空间/模块，封装工具库

  2. 外观模式 概念：外观模式为一组复杂的子系统接口，提供一个更高级的统一接口，通过这个接口使得对子系统的访问更加容易/统一。 使用场景：1、处理浏览器兼容性api（addEventListener、attachEvent）；2、对三方库做一个二次封装，提供一个统一的外观，业务不是直接依赖三方库，方便后续更换三方库。比如自定义业务监控告警的函数封装、埋点的函数封装。

  3. 装饰者模式 概念：在不改变原对象的基础上，通过对其进行包装扩展，使得可以满足用户的更复杂的需求。 使用场景：1、高阶组件（比如在原页面组件上添加权限控制的功能，使用高阶组件来达到解耦、复用的目的）；2、es6类的装饰器。

  4. 发布-订阅模式 概念：类似于观察者模式，是一种消息机制，定义了一种依赖关系，可以解决主体对象与观察者之间功能的耦合。 和观察者模式的区别：存在‌独立的事件中心（Event Bus/Broker）‌，发布者和订阅者通过中介通信，双方无直接交互。 使用场景：1、事件总线进行数据传递/通信；2、react-native中的NativeEvent；3、dom元素的事件监听addEventListener等

  5. 状态模式 概念：一个对象的内部状态发生改变，会导致其行为也发生变化。使用状态模式（类似于策略表）避免过多的if/else的分支判断。 使用场景：1、策略对象，枚举所有的状态以及对应的行为，而不是使用if/else。比如说开户状态的显示，pengding/成功/失败等状态，配置对应的展示函数。

  6. 代理模式 概念：由于一个对象不能直接引用另外一个对象，所以需要通过代理对象起到一个中介的作用。 使用场景：数据劫持、数据响应式

简述MVVM 和MVC的原理以及区别

MVVM视图模型双向绑定，是Model-View-ViewModel的缩写。MVVM的优点：

  • 低耦合。视图（View）可以独立于Model变化和修改，一个Model可以绑定到不同的View上，当View变化的时候Model可以不变化，当Model变化的时候View也可以不变。
  • 可重用性。你可以把一些视图逻辑放在一个Model里面，让很多View重用这段视图逻辑。
  • 独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel)，设计人员可以专注于页面设计。
  • 可测试。

MVC是应用最广泛的软件架构之一,一般MVC分为:Model(模型),View(视图),Controller(控制器)。这主要是基于分层的目的,让彼此的职责分开.View一般用过Controller来和Model进行联系。Controller是Model和View的协调者,View和Model不直接联系。基本都是单向联系。M和V指的意思和MVVM中的M和V意思一样。C即Controller指的是页面业务逻辑。MVC是单向通信。也就是View跟Model，必须通过Controller来承上启下。

MVC与MVVM的区别？

  • MVC和MVVM的区别并不是VM完全取代了C，ViewModel存在目的在于抽离Controller中展示的业务逻辑，而不是替代Controller，其它视图操作业务等还是应该放在Controller中实现。也就是说MVVM实现的是业务逻辑组件的重用。
  • MVC中Controller演变成MVVM中的ViewModel
  • MVVM通过数据来显示视图层而不是节点操作
  • MVVM主要解决了MVC中大量的dom操作使页面渲染性能降低,加载速度变慢,影响用户体验

code review

  1. 函数入参个数态度 使用者需要关心参数的个数和顺序，有很大的心智负担。 正确做法：是合并参数为对象，然后进行解构。

  2. 魔法数字/字符串（硬编码） 硬编码会带来若干问题，1、维护人员不太清楚其含义，2、另外会有可能的耦合。 正确做法：定义常量来取代魔法数字/字符串，同时使用语义化的变量名。

  3. 不合理的注释

const id = 1 // 定义id为1 => 定义要查找的文章id

  1. 简化逻辑分支 应该使用策略表（策略模式）进行优化，避免使用过多的if/else

  2. 条件判断过于复杂 应该单独抽离一个判断函数，保持主要流程的简洁

  3. 卫语句（提前返回） 有时候业务处理和错误处理代码揉杂在一起了，代码很难看懂。 正确做法：应该是先处理所有的错误场景，然后提前返回，剩下的再处理正常的业务流程。

  4. catch代码块为空 正确做法是提示错误信息、上报异常信息、其他业务逻辑。 如果不需要处理的话，就不应该使用catch。

设计一个组件库

  • 是否有现成的脚手架，搭建项目的基础框架。没有的话就自己制定一些约定进行开发。
  • 构建工具选择（rollup、esbuild、father等），打包产物采取bundless打包，方便开发环境debug。
  • 方便开发维护人员，本地开发服务器、examples/playground页面。
  • 使用ts编写/生成ts类型声明，ts类型系统会方便后续维护成本，导出ts类型声明会方便业务方使用。
  • 组件库文档，可以使用dumi等文档工具，方便业务方查阅。
  • 版本发布支持自动化流水线（包含alpha、release版本），避免人工误操作。
  • 后续版本迭代的策略，收口到专门的维护人员，收集关于组件库的新增需求、历史bug，统一管理和维护。
  • 基础组件库单测/业务组件库可以省略。

组件库兼容性的考虑

  • bundless打包，产物是es6代码，方便debug，不增加polyfill，改由业务仓库进行（polyfill）
  • 按需引入、treeShaking

搭建项目

  • 技术选型，比如vue、react，有现成的脚手架，搭建项目的基础框架。没有的话就自己制定一些约定进行开发。
  • 选择构建工具webpack，配置相关的文件、入口、本地服务器等等。
  • 项目使用typescript进行开发，ts类型系统会极大的方便后续的维护工作。
  • 约定项目的目录（清晰的目录结构），比如pages路由、utils工具函数、components公共组件、apis后端接口等。
  • 三方包的技术选型，比如基础组件库、全局状态管理库、请求库等。
  • 项目打包部署，和运维进行配合编写自动化部署脚本。
  • 使用cdn、缓存、配置跨域等等。

怎么评估引入一个新的npm包

  • 包体积，npm的包体积尽量少、是否支持tree-shaking等
  • 维护状态，更新发版频率、最新版本、github的issues修复情况
  • ts类型支持，方便业务使用
  • 兼容性，caniuse
  • 替代方案/成本，mementjs/dayjs的选择替换（使用外观模式）

发布/部署流程

我们是周二、周四两个固定发布日。以周二发布举例：

  1. 发布前 周一准备发布计划，各需求负责人填写发布表格（需求名称、涉及的服务、相关的链接地址），整理发布的配置项（多语言文件配置等），周一晚截止。

周二早上从最新的master上切一个release分支，合并需求代码，有冲突解决冲突。（举例，我的需求涉及A、B、C三个仓库，别人的需求涉及B、C、D仓库，就会有4个仓库的release分支，其中B、C可能会有冲突需要解决）。花一早上时间完成代码合并流程。

周二下午，针对合并的release分支在专门的测试环境进行回归、验收，有问题的话相关开发人员进行修复。

  1. 发布中 周二晚上，进行生产环境的发布工作。先在预发环境进行配置、发布、验收，没有问题再进行灰度发布，慢慢放量，一般当晚会放量到5%，期间需观察监控。（因为公司的业务访问量少，新功能需要进过业务高峰期的验证，所以最少要灰度一个早高峰）

周三中午灰度完成之后，发布生产环境。

  1. 发布完成 生产发布完成之后，就把对应的release分支合并到master上。 整个灰度发布过程中可以执行停止灰度、回滚等操作。

需求开发完整的流程

  1. 产品需求初评/评审
  2. ued评审（简单的可能会和产品需求评审一起）
  3. 后端、前端的技术评审
  4. 前后端开发、联调
  5. 测试的case评审，包含冒烟case
  6. 前后端提测，需要完成冒烟case用例
  7. 测试人员进行测试
  8. 测试完成，准备上线计划，然后执行需求上线

职业规划

  • 资深前端开发：在前端领域某一个课题，能够有深入的理解和产出。
  • 前端专家：深入理解前端领域，能给出前端难题的解决方案。同时在服务端、运维端等方面也有建树。

我上加公司的岗位是高级前端开发，然后当前应聘的也是高级前端开发，所以暂时的职业规划的话，是期望能在前端开发的技术路线上走的更远，后面还有资深前端开发、前端专家这些。

为了完成这个职业目标，我对以往工作经验的总结，结合最近面试情况的复盘，有以下几个点需要提升：

  • 技术广度：nodejs方面（ssr等）之前没有相关经验，数据可视化方面（echarts、threejs等）
  • 技术深度：主要体现在技术影响力方面较低，需要持续的做技术沉淀和分享、输出，比如说技术分享、博客等

最有成就感的一件事情

react-icon组件库项目在前端团队内使用，正式落地，成为团队统一的规范标准。

这个项目的话，在提出问题、需求目标确认、需求调研、前端方案评审、前端开发、前端宣贯，我都有参与，也是项目的前端负责人，所以这个icon组件库的正式落地使用以及成为团队的规范，对自己来说是非常有成就感的事情，非常鼓舞。

难点：1、icon数据源的问题（如何协同、维护）；2、适配双端；3、如何更新发布。

可提升：目前使用需要频繁升级，将构建放在本地，通过postinstall钩子进行构建。

最后悔的一件事情

背景：大概24年10月份，获得晋升提名，但是最终晋升失败了，原因据说是在团队内的技术影响力比较小。

最后悔的事情就是没有提高在团队内的技术影响力。其他人的话，有参与多语言改造方案的调研、决策，app多bundle的拆分等等难点的实施，更具影响力。

措施/复盘：组会积极分享（xxxx最佳实践、xxxx工具的使用等等）、踊跃参与技术选型/技术决策、参与难点攻坚等。

对加班的看法

  • 我认为加班的主要目的是”完成好工作”。
  • 有未完成的工作必须要加班加点完成。比如说紧急的线上问题需要当天发版修复的，不紧急的线上问题需要整理好提测分支给测试回归验收的，这些工作任务虽然属于突发情况，但也属于前端开发的本职工作，应当完成。
  • “完成好”，如果工作任务按时完成了，只能评估60分及格，但是自己的能力完全可以达到80分甚至更好。这个时候可以秉持着”尽善尽美”（公司价值观）的原则，尽量优化相关的逻辑，避免后续出问题。
  • 另外一点是开发人员的工作特殊性，遇到前端发布的时候，一般也会有加班的情况出现，不可避免。
  • 加班的影响：1、加深内卷这种不好提倡风气；2、不利于正常的项目管理。（巨额的工作量不应该通过加班来完成，而是需要合理的排期、合理的项目规划）。

怎么评价自己

好的：

  • 1、干活的一个好手；（相关领域的需求，能够按时完成任务，没有过重大线上故障）
  • 2、乐于助人；（乐于帮助同事解决技术问题，formily的schema配置等）
  • 3、积极参与团队活动（羽毛球、排球等活动，outer-day旅游活动-海昌公园）

不好的：（准备几个）

  • 1、工作任务完成得比较常规，不太会提出创新的解决方案，因为容易导致未知问题
  • 2、生活上比较内向，比较宅

评价上一个公司

  • 技术氛围比较好，经常会有技术分享，针对技术问题会有热烈的交流讨论。有利于技术的沉淀和成长。
  • 经常会有复盘会，例如质量月会、故障复盘会等，加深对前端质量、系统稳定性保障的认知。
  • 技术勇于创新，大胆改造：在入职后，亲身参与/目睹了很多历史项目的大刀阔斧的改造。
  • 业务能力行业内处于领先地位，比如收款能力、风控能力都受到客户的好评。
  • 客户第一，尽善尽美：无论是销售，还是产品、开发，都以客户的需求为导向，进行公司产品的设计。比如说公司新版本的收款账户页面，还是咨询了很多客户才定稿的。

怎么评价本公司

  • 从面试反馈来看，工作效率非常高。
  • 技术上来看，已经集成先进的ai功能，走在时代的前沿，是一个紧跟时代潮流的产品和技术团队。
  • 举例人员，能和这些资深的工程师进行交流和学习，相信技术氛围一定很浓厚，会有收获。
  • 举例出版，很open有活力的工程师，相信公司的工作环境也一定非常有活力和开放。
  • 总结：是一个更高的平台能够展现自己、锻炼自己、提升自己。

手头上是否有offer

  • 有一家offer，但是公司的规模比较小，发展前景可能不太好，所以最近在看大公司的一些工作机会。
  • 列举其他进行中的流程。

离职原因

工作快满3年，公司没有续约，最后在发年终奖之前先裁掉了。

补充：

  • 公司合法合规，有补偿，公司对得起我，我对得起公司
  • 大家私下在工作中也都是好朋友，经常一起活动，不要太僵硬，好聚好散
  • 避免下家公司背景调查不好的响应，朝前看

Graph View