微前端与前端管理
2020-11-23 16:39:40 0 举报AI智能生成
前端管理
作者其他创作
大纲/内容
微前端
为什么需要微前端
系统模块增多，单体应用变得臃肿，开发效率低下，构建速度变慢；
人员扩大，需要多个前端团队独立开发，独立部署，如果都在一个仓储中开发会带来一些列问题；
解决遗留系统，新模块需要使用最新的框架和技术，旧系统还继续使用。
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
基本概念
最早提出微前端这个概念的应该是在 ThoughtWork 的技术雷达，主要是把微服务的概念引入到了前端，让前端的多个模块或者应用解耦，做到让前端的子模块独立仓储，独立运行，独立部署，独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理。
简单来讲：微前端是一种由独立交付的多个前端应用组成整体的架构风格。具体的，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
特点
代码库更小，更内聚、可维护性更高，可独立部署
松耦合、自治的团队可扩展性更好，降低代码耦合
渐进地升级、更新甚至重写部分前端功能成为了可能，可以按照业务垂直拆分更高效
适用场景
业务模块相对独立的复杂单体应用
综合考虑团队技术能力和业务现状选择适合的方式
实现方式
使用 iframe 组合
iframe 天然具备微前端的基因。只需将单体的前端应用，按照业务模块进行拆分，分别部署。最后通过 iframe 进行动态加载即可
优点
天然具备隔离性
缺点
主页面和 iframe 共享最大允许的 HTTP 链接数
iframe 阻塞主页面加载
浏览器的后退按钮无效
服务端模板渲染组合
常见的实现方式是，服务端根据路由动态渲染特定页面的模板文件，如：通过 Nginx 服务器根据 url 路径动态设置要加载的模板
实现简单
技术栈独立
需要额外配置 Nginx
前后端分离不彻底
微前端框架 single-spa
https://single-spa.js.org/
对于时刻将 “没有 js 做不到的事情” 视为座右铭的前端程序员们是不可能不造轮子的，鼎鼎大名的 single-spa 就这么被造出来了
借助 single-spa，开发者可以为不同的子应用使用不同的技术栈，比如子应用 A 使用 vue 开发，子应用 B 使用 react 开发，完全没有历史债务。
纯前端解决方案
可以使用多种技术栈
完善的生态
上手成本高
需要改造现有应用
跨应用的联调变得复杂
蚂蚁微前端 qiankun
https://qiankun.umijs.org/zh/
qiankun 是一个基于 single-spa 的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。
设计理念
由于主应用微应用都能做到技术栈无关，qiankun 对于用户而言只是一个类似 jQuery 的库，你需要调用几个 qiankun 的 API 即可完成应用的微前端改造。同时由于 qiankun 的 HTML entry 及沙箱的设计，使得微应用的接入像使用 iframe 一样简单。
微前端的核心目标是将巨石应用拆解成若干可以自治的松耦合微应用，而 qiankun 的诸多设计均是秉持这一原则，如 HTML entry、沙箱、应用间通信等。这样才能确保微应用真正具备 独立开发、独立运行 的能力。
微前端 与 前端管理
研发管理
管理目标
保证高效率、高质量地完成项目的研发和上线工作，并保证软件在线上运行过程中的高性能和安全性。
保证项目进度可控，风险可控。
保证研发团队良好、合理、稳定的梯队。每个角色及其不同职级，都有良好的成长、晋升路径和机会。
团队内有良好的技术氛围、创新氛围，并且保持激情，有很强的战斗力和进攻力。
自我管理
大局观
自省能力
谨言
自信
技术能力
逻辑思维能力
悟性、学习能力
向上管理
老板，以及老板的老板，也是自己管理的对象，不容忽视。
据说，升职，就是让老板的老板看到自己的亮点，让老板的老板发现老板因为关键人物“你”超出预期。所以，站在老板的视角思考问题，非常重要。
下情上达，掌握一线信息，锻炼思维，提升自己，自我呈现
技术管理
新技术选型
个人技术栈
团队技术栈
项目管理
迭代需求把关
进度管理
项目资源协调
人员管理
向下沟通
选择人
了解人
员工的生活与家庭背景
员工的性格和诉求
员工所处的阶段
定期面谈（组长+抽选员工）
要求人
有效授权
绩效目标设定、分解、跟进、调整、评价、改进
激励人
绩效|升职|加薪|年终|期权|股票
赞赏
赞赏要具体，要有针对性
赞赏要及时，要真诚
赞赏要当众（批评要私下）
善始善终，结尾不要批评对方
培养人
骨干培养
团队技术培训和提升
事和诉求的匹配
员工的上升渠道
对每个成员的成长负责
评估人
日常考勤请假
绩效考核
述职、定期总结
异常成员跟踪
淘汰人
这一点比较难跨出去，招聘时的看走眼，或者接手新团队的成员，都有可能出现无能、懒散、老白兔等。
如果不及时淘汰，积累下来，难免会影响团队氛围、士气、公平，需果断将其淘汰。
因为一些不可描述的因素，实在不能全部淘汰，尽量保证占比较低。
团队管理
自管理能力（自驱）
建立很好的汇报机制，包括进度、风险、问题
建立很好的向下传达、周知机制
团队优化
跟进线上问题、及时通报周知处理结果
绩效管理
文档沉淀与积累
团队对外技术影响力提升
决策链梳理
会议质量&效率
前端管理
基本管理
项目技术培训
提前解决项目难点，复杂点，宣讲并在项目新建demo目录
技术调研，新技术选型
项目可配置
字体配置 采用rem 布局
全局颜色，使用变量定义
mock抽离为json，便于前后端接口联调
路由定义可配置，抽离前缀
预览全项目，提取可共用组件
工作总结及开发建议
开发进度要如实汇报，做了多少就是多少，没做好，不要说做好了
技术实现尽量基于现有技术实现，以工作质量和工作效率第一，不要自己去实现一些插件的功能，因为很可能有bug，并且大幅增加开发时间
和团队leader及时沟通，比如，如果任务量大，要说出来，不要自己闷 头做
一些比较难的问题，如果自己解决困难，首先，不要自己硬做，团队内解决， 团队解决不了，leader解决
需求方新增需求，不要马上开发，首选和需求确定好，然后跟leader沟通，怎么做确定之后，再开发，以免白增加工作量
细节问题，一般来说，完成第一，细节后续优化，不要因小失大
开发总结
Git使用过程中，完成一个功能或者修复一个bug就提交push，不要写了一大堆再说，容易丢代码
去写一些功能，看看以前的代码或项目有没有现成的，拿来直接用
如果去维护样式，可以在下边写，覆盖上边的，可以减少代码冲突
写样式之前，要看一下项目，要不要封装成组件，统一处理
代码要简洁易懂，注意代码层次，不要有大段的注释啥的
数据容错处理， 空处理
0 条评论
回复 删除
下一页
