-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
如何打造公司级公共前端团队 #2
Comments
👍 |
👍 |
👍 |
2 similar comments
👍 |
👍 |
a misspelled: |
ESlint工具配置有哪些规则可以详细说下吗?@ustbhuangyi |
@xianyuxmu |
👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
滴滴公共 FE 团队的实践和产出
1. 团队定位
(1)团队人数、职责
滴滴公共FE团队现在有十多个小伙伴,男女比例为
1: 1
。主要包含以下几大职能方向:
团队职责:
(2)所做的事
简单先介绍对外的我们做的比较大的一些事情
全局类:
1、公司统一权限登录移动化和PC改版
2、移动端用户统一登录SDK
**可视化方向:**滴滴国内央视曝光10多次春运迁徙可视化。
**组件化方向:**公司级组件库 - 魔方。
通用服务:
1、TMS 运营和模板平台
2、NPM Private
用户类:
(3)团队努力方向
2. 团队的实践和产出
滴滴公共FE团队做的实践还是很多的,现列举几个比较重大且应用度广的实践。
(1)公司级组件库:魔方
痛点:
每一个系统UI、交互规范、组件技术都不一样,复用性低,依赖第三方开源但技术支持不到位,遇到问题没人服务。
途径:
展示:
技术:
第一版:zepto + dmu(优化版的 gmu) + styl + handlebars + webpack
第二版:vue + webpack
jsbridge: ES6 + (webpack || rollup) + babel
唤起app: 统一的中间页服务 + iframe 请求 schema
关于魔方 PC 端构建流程介绍:
]由于 PC 我们全部依托 Angular 指令来编写,在 WebPack 采用了
ngtemplate-loader
不同环境 2 套配置文件:
区别:
我们打包之后的目录:
如何配置第三方依赖:
如何处理 directory 里面的 template:
如何按版本发布:
整体我们依赖 pkg.json 的 version:
关于 iOS 9 Safari iframe src with scheme not working:
Webpack 动态加载:
(2)公司级统一运营服务:TMS
痛点:
运营类 H5 zip 上传能否支持
途径:
技术:
我们采用更定制化的Nodejs服务框架(从 Sailsjs 参考了很多) + mongo + pm2
结合公司发布系统、定制日志监控和脚本化运维规范
架构图:
遇到的技术问题:
1、如何灵活地进行线上线下配置
我们的 DNode 系统里面,默认支持 2 个配置文件
启动服务的时候,控制参数:
默认走的是 dev 的所有配置
这样默认就执行了所有 prod 的配置参数
2、脚本化运维 DNode 服务:
整体我们还是依托公司的发布系统,设置后置脚本来部署和安装部分依赖:
日志监控:
设置固定的日志,依托公司统一日志监控,设置拉取策略和一些采集匹配规则
3、如何处理不同类型的文件上传?
在 DNode 里面我们所有的请求都会安装配置的 middleware 数组顺序,进行流转:
这样的优势:
首先我们检查 request 头是:
然后我们会通过
formidable
的 2 个方法:如何限制体积:
我们这边采用的是
skipper
在 bodyParser 的 middleware 里面做了一次过滤。(3)MIS 服务化、配置化、GUI 化以及前后端分类
痛点:
途径:
技术:
Nodejs + 数据存储 + 各种配置系统 + 脚本
(4)WebApp首页公共化
痛点:
滴滴早期WebApp首页是由业务线同学维护,与业务线有一定程度耦合,新业务线接入相对比较困难。
途径:
技术:
(5)H5 统一登录 SDK
痛点:
滴滴早期的登录每个业务线都会做一套,有开发成本。不利于账号部门收敛和管理各业务线账号,不利于做一些账号安全和组件升级;登录没有打通,新业务线或运营活动接入登录成本高。
途径:
展示:
技术:
(6)Npm Private
痛点:
前端项目越来越多,内部产出的工具包也比较多,如何自建一个私有库。
途径:
技术:
3. 团队学习和应用的技术方向
最近新技术的落地:
4. 如何打造公司级公共前端团队
这个问题其实我每天都在思考,好像一直没有太明确的答案,这里也只是分享一些我个人的见解:
下面我从几个方面具体来谈一谈。
(1)理想中的公共团队
团队永远和人有关系,下面我从几个简单的维度,通过我对几个游戏的理解来分享一下我认为公共团队的人所需要的气质。
1.“飙车”
**敢于超越,专业性要求高:**赛车手和我们一般的开车的同学相比:更专业、对车子的熟悉度更高、追求超越和不愿意被超越。我很多时候推荐团建都是去玩室内卡丁车,而且每次都发现:有一些同学愿意最后和一些跑圈快的一组再比一轮,即使最后,那可能也是其他圈里面最快的。
2.乐高拼图
**能够沉浸在技术里面,去思考问题,最终产出:**乐高一般有几千块零散的拼图、需要沉下心来、而且在脑海中大概有一个架子,不断地去尝试和调整,最终完成一个作品时候,你会很自豪。
3.潜水
**敢于挑战自己惧怕的东西,克服困难,战胜自己:**潜水是我开始最惧怕的一项运动,很早前我不会游泳,但我又渴望翱翔大海,在一段比较长的震痛期后,我完成了浮浅和深浅,看到了很多常人看不到的美丽景色:大海龟、大鲸鲨、暴风鱼群等。
4.写作&分享
**沟通和沉淀才能让知识更记忆深刻:**我自己喜欢翻译和写一写技术总结的文章,已经成为生活中一个不可或缺的习惯。然后再分享出来,得到一些批评和反馈。
(2)Leader个人水平的提高
作为公共团队的 FE Leader,其实我的压力还是比较大的,除了满足业务需求外,你更多还需要告诉团队方向在哪里、我们的计划是否是可以落地的。
1、每月一本的技术书籍
2、定期也会和一些比较资深的前辈取取经
3、参加一些业内比较知名的大会,比如最近的Qcon
4、长期保持技术文章沉淀总结分享的习惯
如何更合理地提供解决方案?
我自身也折腾过各种机器和环境部署、数据库,也接触过后端和安卓开发,在研究跨端体验的时候,花了 2 个月看了 iOS 相关的基础书籍和代码。
很多时候解决方案的合理性和全局观,不只是你熟悉业务就可以了,我更倾向让团队的很多同学熟悉前端独立部署、如何和不同的端交互以及他们内部相关的技术组成。而且大部分时候不敢于技术革新的一个很大原因:不了解、不熟悉、没把握。
如何高效地管理写代码和管理时间的分工?
很多时候时间确实是不够用的,而且有时候会参加很多会议和培训等。我管理时间一般的方式如下:
(3)团队管理
对内外的沟通
代码 review 和风格一致性
创造活跃的技术范
在很多时候,永远需要一个带头人跑的快一点,积极一点,在技术上鼓励创新和不断打磨沉淀优化,鼓励团队的小伙伴通过一些工具和技术手段来解决一些重复性的事情。
除了利用
合理、稳定、高效
的技术解决方案来服务日常的业务支撑外,考虑到前端技术的日新月异,我们也沉淀和创造一个统一的技术氛围:5.致谢
公共 FE 团队在任何一个大公司都离不开业务线小伙伴的支持和厚爱,领导的认可和关注。
要感谢的人很多,有很多可能我自己都叫不上名字,不管怎样,真心感谢所有帮助过以及信任着公共 FE 团队的同学,
同样地也再次特别感谢我们团队的每一个亲爱的小伙伴。
一路同行,只因为有你们:huangyi、wangjing、wangjin、suwei、shumei、xiaoqi、yanfen、miaodian、cuijing、yufei、huan总
The text was updated successfully, but these errors were encountered: