78 个前端基建问题的讲师答疑合集 | 第二届早早聊
2020/3/20 11:01:44
本文主要是介绍78 个前端基建问题的讲师答疑合集 | 第二届早早聊，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！
前端早早聊大会，前端成长新起点，帮你提前二十天，站在新的起跑线，目标成为用得上，听得懂，抄得走的前端大会，计划 2020 年办 12 期，由前端早早聊与掘金联合举办。
- 第一期 2020.1.11 在杭州举办，主题 「前端转管理」，450 人报名参加，反响强烈
- 第二期 2020.2.29 在线上直播，主题 「前端搞基建」，760 人报名参加，反响强烈
- 第三期 2020.3.28 在线上直播，主题 「前端搞搭建」，报名请加关注「前端早早聊」公众号跟进历届大会 PPT/录播视频/图文讲稿，回复 "大会" 二字获取。
第三届报名链接：www.huodongxing.com/go/tl3
- 团队成立 3 年|小爝 - 如何推动基础架构项目落地
- 团队成立 4 年|堂主 - 如何推动前端团队的基础设施建设
- 团队成立 5 年|Scott - 如何在人单力薄时立项推动基建
- 团队成立 6 年|芋头 - 如何在大前端团队实现基建价值突破
- 团队成立 12 年|崇志 - 如何设计大型前端团队基建路线
本文针对第二期报名用户在专属直播间的提问，在直播中没来及回复的，5 位讲师后续的回答，直播中回答的问题只记录不做文字化。
一、如何推动基础架构项目落地 - 小爝
1. 已回答问题
Q: 请教小爝： 在新浪做基建这项工作，是公司要求你去做的，还是？
A: 我的工作职责就是负责这块东西，招聘我去公司的时候也是确定就要负责这块内容。
Q: 请教小爝：前端bff层在落地上有遇到什么比较深刻的问题吗（比如业务上的阻碍、前后端配合的阻碍），对于暂时没有bff落地的团队，业务发展到什么程度，比较适合引入bff层？
A: 大部分的阻碍都主要在于和公司已有运维系统的集成，日志的打通，前端不会什么太大的阻碍，除了技术上的，比如监控的手段，后端知识的学习。没有落地BFF得团队也不需要急于干这件事，主要还是看公司内部是否有这方面的储备和打算，是否在前后端联调方面或者人力成本上有一定的优化控件。我们做这件事得几个收益是，一个是节约维护成本，一个是减少沟通成本。最后还做了性能优化，节约了公司的资源，最后前端人员还能在更多的层面加大自己的架构施展空间，因为有了后端开发这个锤子。
在一些大企业或者国外的企业，这种模式很常见并且已经持续了很多年，比如FB，Google，国内的百度，字节跳动，快手等，都有相关BFF的落地和实践，之前用的PHP，现在用Nodejs而已。
Q: 请教小爝：关于DARUK logger 设计思路？
A: 标准化日志是一个公司应该统一的格式，那么我们的logger就是吸收了公司的统一日志标准，又增加了可以自己扩展或者扩充字段接口的能力。再加上继承在框架内部以中间件和lib包的方式载入实现的而已。
没什么太多的设计思路，有一个点比较有意思，如何获取nodejs中每一层middlewares的时间损耗日志，可以思考一下方法，要是自己写一个logger如何去做。
大部分还是技巧方面的东西比较多，主要思路还是要做一套统一的日志标准格式。因为不同语言不同项目如何统一运维监控，日志就是大家约定好的接口。
2. 直播未回答问题
2.1 详细技术问题
Q: 请教小爝：怎么看flutter ?
A: 这个问题太大，我就我们这边的一个实践来谈体会，东西不错，但是基础工程需要做的点太多，比如底层得plugin支持，如果公司已经有了一套jsbridge这种hybrid架构或者RN，WEEX这种bridge的实现，上了flutter还要再重复造一层，新项目可以尝试，老项目建议不要轻易折腾，循序渐进的使用。
技术没有好坏，在flutter还不能快速实现热更新的时候，我们暂时不会大规模采用，这涉及到很多方面，比如之前的UI组件和业务代码无法很好的复用的问题，一些基础建设工具需要重新开发，成本太大而优点有限。
个人认为flutter更适合个人开发者和创业公司，可以快速出一些三端一致又对个性化要求不高的产品，一套代码多端统一是一个特别美好的愿景，但是真实情况就是，你一直要各种处理差异性和不同平台的逻辑实现。没有历史包袱可以尝试，当然以上都是我个人的观点，我没有深入的用过Flutter，大家听听就好。
Q: 请教小爝：监控系统思路能再提供下么?
A: 这个话题有点大，简单来说错误监控主要依赖于系统的几个api，比如window.onerror，全局的promise异常捕获，利用AOP来把一些原生类进行包装加try catch等不同的技术手段来监控，可以参考一些开源或者不开源的error的收集SDK，反编译下就有收获了。
而性能方面的监控主要是指标的指定，这有2个纬度，一个是业界的统一指标比如lighthouse，seeppage等统一的几个点，还有就是业务自身的一些特殊要求监控，比如异步组件，spa路由的切换这一类需求还是需要根据项目自己研发对应的收集方法。最后业务数据的监控可以走正常的业务上报就行了，主要是如何做到快速的让业务同学无感上报，这在于api的设计。数据日志都有了，收集后的数据探索，清洗，储存，分析还有可视化是一套标准的大数据可视化工作流。简单来说我们这边还是使用开源工具来进行搭建，但是部署和运维还是走公司的统一监控部门，这要看数据的量级和自身部门devops的能力了，前期我们有自己运维过，数据量大了之后hold不住了，还是接入了公司统一的日志平台。
Q: 请教小爝：自研监控体系和已有的对比有什么优势 ?
A: 自研的好处就是想怎么改怎么改，本身监控不是很复杂的前端代码实现，用开源框架不是不行，难的是日志接口标准的统一，自研会更好对接一些。
Q: 请教小爝：前端监控体系，有哪些开源项目可以参考?
A: sentry，badjs，我之前开源的GER，还有fundebug的前端埋点代码也可以参考参考，收费的oneapm都挺不错。不是说收费的就不能参考，主要在于参考他们的监控思路和纬度，实现上没太多难点。
Q: 请教小爝：平台类型的app，界面的拼合有好用的工具 ?
A:平台类型的app，界面拼合的工具我真的不太清楚，因为我不开发APP。。。
Q: 请教小爝：CI/CD 的 job，stage 等你们是怎么设计的？
A: 我们主要是用stage来区分上线环境，比如测试和生产是不同的stage来触发的，还有一个就是用来区分APP端内和H5的资源，他们的流程也是不一样的，比如APP内的离线包是需要ci中进行patch计算和特殊处理的，当然H5也有H5自己的处理逻辑。简单来说就是区分好env和platform。
Q: 请教小爝：如何在基建工程化中集成和手机，各大性能数据日志？
A: 题目没看懂不好意思，我个人理解你想问的是，如何打通app和hb或者h5的性能数据日志？这个我问过客户端的同学，客户端如果要自己收集，也都是大部分借助webview的生命周期（native）和注入一些JavaScript代码来实现的，那么注入JavaScript代码其实利用的就还是js的能力收集，再回调给客户端做统一汇总上报。不知道是不是要问这个问题，题目没看太明白。
Q: 请教小爝：造轮子的时候，如何权衡是使用业界现成轮子还是自己造呢？
A: 看需求，业界满足的话，当然用业界的了。不过要有帮别人擦屁股的觉悟。
Q: 请教小爝： ci/cd，是每个项目都clone一份写好的配置吗，ci升级如何考虑的?
A: 我分享的时候有说，我们申请的是整个gitlab几个组的token，所以只要是项目在我们规定的几个组中，就都会有我们的ci runner，当然也可以创建整个gitlab全局的ci runner，这都是支持的。
所以你只需要把gitlab-ci.yml 集成到脚手架中就可以了，这样每个初始化的项目扔到git上就都是统一的ci/cd了。
Q: 请教小爝：请问下你们 iOS 和 Android 都使用的什么样的 Hybrid 离线缓存方案？
A: 我们用的是一套离线包方式，我们这个叫离线包，不是离线缓存，离线包的意思就是说把一个zip包下到了手机本地的目录，然后通过加载本地目录的资源文件，比如css，js，html，字体，资源图来实现的离线加速，而动态数据则还是走端上转发的API接口。
Q: 请教小爝：接口错误从前端监控上报，如何评估失败率多少是合理用户本身网络有问题?
A: 一般日志上报上来后，需要有一个数据探索的过程，比如我们百分位分析，99%的用户数据都是正常，1%的高位数是非常高的脏数据，那么我们可能需要先去掉这部分脏数据再去看成功和失败率，并且需要对数据做一个周期性的观察才能决定，比如一周或者10天，因为业务指标是有波动的，一个错误率的上升除了你接口有错误之外，还可能是因为访问量突然层高导致的波动，所以需要动态的去看各种率是否合理，也就是报警的阀值。可以去看一下我们知乎的专栏，里面有讲利用动态分布来计算性能和错误率的一些文章。
Q: 请教小爝：grafana中展示错误、劫持等监控数据，如何具体展示错误发生在哪里，查看具体的报错信息？
A: grafana除了画图，也可以画表。。
Q: 请教小爝：为什么要从 express 到 koa，是遇到了什么问题吗？这样做是出于什么样的考虑？
A: 因为这边有一些项目在开始开发的时候还没有koa，只有express，这些算是上古原始项目。问题没有太多，express也是一个很优秀的web框架，社区目前也比较活跃，插件很多。但是本质上来说用koa来编写web 中间件的优势很大，所以我们选择了koa，koa本身聚焦的事情很少，设计的很巧妙，我们也进行过不少其他web框架的压测，最终从性能，可扩展性，社区开源包的基类，上手程度和流行程度上最后决定了用koa来做二次web框架开发。
Q: 请教小爝：埋点要怎么做，有哪些指标、阈值吗？埋哪里？如何筛选需要埋点的用户？
A: 不太理解这位同学问的是什么埋点，性能？错误？业务日志？不同的埋点方法上面我有回答了，阀值应该是根据收回来的数据分析出来的，不可能在收集之前就定。埋哪里这个。。。
我感觉应该埋到代码里吧……
如何筛选这个问题可以有多种办法，比如错误的埋点，我们就做了筛选，本地会有一个概率比来决定是否报，已经报过的错误我们是不会二次上报的等策略来控制。也可以根据用户桶来分，这个需要借助我们内部AB系统来实现。
2.2 资源相关
Q: 请教小爝：3个人的团队如何提升项目基建 ？
A: 好好干业务，别想用不着的了，好好保养头发。。如果精力实在无处发泄，写代码的时候多写点注释也行啊。
我个人认为，10人左右的前端团队配置1-1.5个做全职基建的人就足够了。如果3个人的团队，还是吃点好的吧，可以借助一些开源的工具，把上线流程打顺，把组件尽量模块化，能复用就行了。
Q: 请教小爝：你们目前团队基建人力和业务人力占比情况？
A: 我们前端team一共24人，我这边9个，但是我们也有自己的业务，所以算下来真正全职干这个事的可能只有3-4个人左右（闲了就干点）。
Q: 请教小爝：本身公司没有独立基建团队 如果来平衡业务与基建呢?
A: 这不是一个平衡的问题，是业务堵到这里了，没有一个系统的解决办法的时候，可能业务也推进不下去了。所以不管有没有独立的基建团队，总要有那么几个人，解决业务解决不了的系统难题，帮大家梳理开发规范和搭建开发环境，他们做的就是基建的事，比如你的leader。
Q: 请教小爝：基建项目的时间安排是怎么做的？因为我们只会给业务需求评估时间。业务比较紧的时候，基建很容易被耽搁?
A: 我自己评估，再给领导汇报，管理好里程碑和做普通业务一样。业务比较紧的时候。。。我们也不会让已经投进去的人出来再去做业务的，除非特别特别紧。：）
2.3 基建价值类
Q: 请教小爝：基建的项目是怎么立项的?
A: 有需求扛不住了，要求提出系统性解决方案的，然后立项的。也有我们遇见的一些未来可能遇到的需求，而立项提前解决的。大部分业务驱动，少部分自己发现，这其实是一个很难说清楚的问题，任何一个需求都可以抽象出来公共层，这部分就是基建要做的事，就像mvc一样，一个人也能写，把m，v，c拆开也能写。
Q: 请教小爝：如何回答提前做某项技术的好处 ?
A: 这要看是什么技术，一般来说就是做竞品对比，数据推演这一类的分析。
Q: 请教小爝：公司不重视前端 怎么提升前端价值 ?
A: 去一家重视前端价值的公司，正所谓人到中年，很难改变别人，那就改变自己吧。
Q: 请教小爝：如何说服产品做基建, 产品只关注项目功能上线？
A: 如果我是产品，我也不关注。你可以请产品MM撸串，或者跟产品妹妹说，这个基建做好了，以后deadline可以提前3天！那我估计你们还能聊聊。
2.4 问题定责类
Q: 请教小爝：监控系统BUG，无法复现?
A: 无法复现的前端BUG问题在于你和对方的环境不一致，如果你收集了环境信息，并且复现了当时的环境，一般就是可以复现的了。
比如兼容性类，比如外部注入的js，比如被劫持了，比如你和用户的操作不一致等等，所以我们也收集了用户的最后几次操作，比如你们的数据不一致（接口导致的报错）。
Q: 请教小爝：出了问题怎么解决，紧急和非紧急？后续追责怎么处理？
A: 任何系统都可能出问题，出了问题当然是先回滚代码啦，追责一般都是根据影响范围来算得，比如你挂了多久，影响多少pv，uv这种东西来定级。
Q: 请教小爝：发现问题后，如何更好的从中心点结构化的挖掘解决问题的价值，以及如何更好的规划和落地?
A: 提前设计，提前推算，提前统一结论，不要先做了再说，做完没人用，不是别人想要的东西。很多公司都是这样，包括做业务需求也是，没有先明确目标达成一致，所以就很难落地。
2.5 其他
Q: 请教小爝：怎么入手基础建设 ?
A: 先成为一名前端，再加入一个大的前端团队，然后好好学习天天向上，老板没准看你灵气十足，就让你去做基础建设了……
Q: 请教小爝：怎么去学习这个基建知识点的 ?
A: 大量的工作经验和善于发现问题的双眼。
Q: 请教小爝：你们团队叫啥名字，怎么能买到（加入）呢?
A: 老板好，我们卖艺不卖身。
二、如何推动基础架构项目落地 - 堂主
1. 已回答问题
Q: 请教堂主：你们目前团队基建人力和业务人力占比情况？
A:
Q: 请教堂主：请问 PPT 中展示的规范&文档是自建的吗（形式很棒啊）？
A:
Q: 请教堂主：为啥不直接用gitlab？
A:
2. 直播未回答问题
2.1 详细技术问题
2.1.1 组件相关
Q: 请教堂主：组件覆盖率是怎么统计的？埋点吗？
A: 组件覆盖率 = 组件被引用次数 / 前端项目总数。组件被引用次数可以通过扫描 Git 仓库中的项目代码得到。
Q: 请教堂主：业务组件的持续升级方案是如何做的？
A: 业务组件在项目中被引用时，不允许所有版本都进行持续自动升级，默认只允许自动升级补丁版本。项目中在引用组件版本的时候，加上 ^ 即可（例如 ^1.0.0）。
Q: 请教堂主：业务组件如何更好的在多个工程应用 ？
A: 业务组件的出发点是为了业务的收敛和开发成本的降低，要做好业务组件，需要有三个规范：脚手架规范、命名规范、使用规范。
- 脚手架：规定组件的代码结构、测试范例以及对应的部署发布流程
- 命名规范：合理有意义的命名，通过命名可以直观理解到其用途和场景
- 使用规范：通过业务组件库文档站点 以及 README & package.json 来说明其 API 设计和使用范例
Q: 请教堂主：组件复用率、版本信息收集怎么收集？
A：第一，组件复用率是通过扫描 Git 仓库里前端工程，来收集组件被引用次数。第二，版本信息是在敦煌组件管理发布工具中收集，用户在发布组件时，我们会默认读取 package.json 里面组件的当前版本，然后用户可以选择升级哪一位版本，系统会自动发布相应的自增长版本。另外，发布时也必须要填写发布日志。
Q: 请教堂主：组件的版本管理是如何做的？是保持最新在每个迭代验证掉还是？如何解决相互依赖的版本问题？
A: 第一，组件的版本号分成 3 位（主版本/次版本/补丁版本）。组件维护者在发布组件的时候可以根据实际情况自行选择自增长哪位版本号。第二，组件在项目中被引用时，不允许所有版本都进行持续自动升级，默认只允许自动升级补丁版本。项目中在引用组件版本的时候，加上 ^ 即可（例如 ^1.0.0）。第三，目前敦煌组件管理会检查组件的依赖树，如果存在版本依赖冲突，就会提示给用户，让用户手动选择使用哪个版本。
2.1.2 测试相关
Q: 请教堂主：监控系统定位出的BUG，业务人员无法复现，怎么办？
A：这是 2 个问题，一是反馈精准性，影响到可复现率；二是线上报错的分级标准，什么情况下可忽略暂不跟进。反馈精准性如果只有一个报错提示没更多有用信息，那就得考虑完善监控能力了，利用业界现成的话如基于 Sentry，自建的话一个可考虑的方向是基于目前的数据驱动视图，在报错的时候把页面的数据 store 快照下来以便在本地快速恢复现场。至于无法复现情况下是否要研发及时跟进，就得看你们的线上报错的分级标准了，什么情况下可放一放（如就一个用户系统反馈有报错其他都没有，或者系统提示有报错但用户回访发现并未阻塞任何操作之类）。
Q: 请教堂主：如何做自动化端对端测试？
A: 这方面我们团队目前还没有对应的建设落地，没办法回答更多。
Q: 请教堂主：toB 的基建有什么好的建议？
A: toB 的特点，一是面向客户的定制化能力要求较高，这个技术侧从模板化 + 配置化方面多想想，在这个基础上能衍生出很多服务于业务的建设，如配置中心、表单中心等。二是新老系统并存，重构成本高，这部分有资源的可以尝试下微前端方向。
Q: 请教堂主：现在推的single-spa您怎么看 ？
A: 目前我们团队还没涉及，没办法回答更多，但我们后续会在这个方向进行探索。
Q: 请教堂主：微前端这方面实践，能说说吗？
A: 目前我们团队还没涉及，没办法回答更多，但我们后续会在这个方向进行探索。
Q: 请教堂主：脚手架等物料工具在老项目落地 ？
A: 我这的策略是老项目沿用既有方案，什么时候项目要重构了什么时候迁移到新的，不会为了迁移而迁移。如果是那种前后端不分离特别影响人效的项目，那我的建议是搭车项目需求一点点尽早迁移掉。
Q: 请教堂主：项目要求支持ie9,前端有什么好的选型嘛 ？
A: 市场占比千分之几的情况下，首先尝试说服业务方接受不支持 + 提示升级的方式。真要支持到 IE9 业界也是有办法的，查查就能找到。
Q: 请教堂主：请问合规检测只能扫通用性的吗，是否可以单独项目检测单独规则 ？
A: 目前合规检测基于不同类型脚手架，对于某一类型如 Vue PC 应用，脚手架配置了特定检测规则集合，不会细化到具体单个项目（成本较高、复用率低），实现上主要通过配置 ESLint 规则继承与开发插件来实现相关检测。
Q: 请教堂主：cli工具如何做依赖库的版本升级, 如果统一升级, 新版跟旧版无法兼容时怎么处理？
A: 依赖库的版本应严格根据 语义化版本控制，当依赖库版本升级时，可通过 cli 工具提示开发人员新的版本信息。当发布的为向下兼容版本，业务项目可根据业务节奏自行升级。当发布的为非向下兼容版本，并需统一时，需提供对应的版本迁移方案及测试方案，保证业务稳定性
2.2 资源相关类
Q: 请教堂主：公司前端就一个人，怎么搞基建呢 ？
A: 基建只是个 Action，基建的目标是通过标准化、工具化、自动化、系统化，提效降本。人很少的时候，专注于从做完到做好的顺序，基本的规范、脚手架、组件库还是要搞搞的，但不必拘泥于必须是自建，用社区现成的全家桶也挺好。这里的重点不是什么都要自己写，而是能通过合理组合社区的开源工具、物料，来实现更优质高效的业务支撑。
Q: 请教堂主：公司就一个前端带两个新手的时候该怎么基建 ？
A: 参考上面问题答案。
Q: 请教堂主：如果团队没有多余的人去搞基建，小团队该怎么办？
A: 参考上面问题答案。
Q: 请教堂主：团队人很少的时候，怎么做人员划分搞基建？
A: 参考上面问题答案。
Q: 请教堂主：我这边要去一个新公司。那边人比较少。请问该如何推动基建 ？
A: 参考上面问题答案。
2.4 团队管理
Q: 请教堂主：保持团队高干劲，核心要靠什么 ？
A: 我的观点是在做什么之前，先解决人愿不愿意干的问题。就像分享文章稿中说的，身价取决于解决问题的能力，做的事情能让大家感受到能力在提升，专业化在上升，对他们自己是有增益价值的，自然认同感会好得多。另外，合理的里程碑目标很重要，牛逼得吹饼得画，更得能把吹的牛逼实现饼能吃到嘴里，持续打胜仗的状态非常重要。
Q: 请教堂主：对于初创团队如何，如何提高效率？
A: 业务少走弯路，关注交付用户价值，而非系统功能；简化协作流程，流程多说明防御性心态重，任其发展会各种部门墙；研发侧多利用市场和开源社区的能力，没必要什么都 0 到 1 自建。
Q: 请教堂主：如何去推动其他同学，愿意去接纳我搭建的脚手架呢？
A: 有些时候自上而下，会好过自下而上；工具的审美，少即性感，站在使用者角度考虑如何轻量化操作，提升使用体验，把复杂的东西封装在工具内部 —— 有些工具不好推广，原因是开发者就是在炫技，弄了一大堆功能操作异常复杂，增加了使用者的成本。
Q: 请教堂主：对于基建意识比较弱的同学如何在项目中去培养这种意识 ？
A: 第一选好该方向基建的 Owner，人对了，事就成功一半。第二管理工具跟上，业务落地结果好给奖励，最好没落地没结果浪费了资源要拿不好的结果。第三对于共建的执行同学，不合适的该换就换。
Q: 请教堂主：如何鼓励团队中喜欢做业务的童鞋，多参与一些横向基建的工作？
A: 苦劳不完全等于功劳，辛苦加班值得鼓掌，但靠加班出蛮力的方式没办法支撑业务的爆发增长。当团队中其他人因为更聪明的做到了事半功倍而得到更好的结果，那些习惯了出蛮力解决问题的同学会有转变的 —— 因为收益结构变了。
Q: 请教堂主：如何更好的建立一个开发中各部分的规范，从什么地方切入更好？
A: 没有最好的只有最合适的，我这规范是团队十几个核心同学一起逐步的碰撞讨论出来的。
Q: 请教堂主：请问您是怎么激励前期团队去做些工作了？特别是晚上跟周末大家主动去完成这些基建项目？
A: 我说说实际情况，你自己琢磨 —— 空降到这边，第一次和同学聊天，我就很直白：“你们都是当初阿里、腾讯这样的一线企业进不去，微店、蘑菇街这类也进不去才来到政采云的。我不一样。我希望未来的几年，我们能一起做些不一样的事，带来一些改变，让我们这些人能越来越职业化，而非越来越外包化。我们不可能一直都在一个公司，如果有一天你想离开这里了，我希望那时候的你们能昂首挺胸的去和大厂的 HR 谈 Offer，而不是被比我们低的多的公司碾压和压薪资。”
2.5 其他
Q: 请教堂主：是否可以远程面试 ？
A: 现阶段我这招聘暂时暂停，再过一段时间会重启。
Q: 请教堂主：里程碑使用什么方式绘制的？
Q: 请教堂主：堂主看待问题的能力和眼界很高屋建瓴，平时如何学习和实践呢？
A: 遇到的问题多了，又没人能帮你破局只能靠自己的时候，你就发现你也行了。
Q: 请教堂主：对于中后台的业务，您觉得哪个基建项目对前端效能的提升帮助最大？
A: 仅限前端的话，组件（高频） + 模板（中低频）
Q: 请教堂主：对敦煌非常感兴趣，可以更多地介绍一下这个系统产生的背景以及如何演进成现在的成果吗？
A: 大家对敦煌普遍感兴趣，那我这个问题多说说。
先说背景，首先是内部沉淀了一些东西，如各种规范、脚手架、组件库，分散在不同的团队，实际使用中发现割裂感很严重，信息不对称，不同团队之间有些同学都不知道还有这些。然后是有一个同学（后来成为敦煌这个建设方向的负责人）仿制飞冰搞了一个简化的模板管理客户端（GUI 的），但因为我们业务不像阿里有那样海量的中后台业务场景，我们这除非是业务改版或者新业务，不然模板的场景也是低频场景，所以开始我并没看好那个模板管理客户端，只是觉得从练兵角度还 OK 才没拍死这个方向。
再后来那哥们在被我怼了无数次的“低频”问题后，加上另一个新入职大神“蓝架”（花名蓝湛，架构能力强我们称之为蓝架）的帮助下终于“开窍”了，当他们来问我“堂主你觉得能不能这样、这样、那样、那样，这么整合算不算吃香难看？”之类巴拉巴拉的时候，我说“你随便我不管”。
于是就开搞了。“敦煌”这个名字是我取的：敦，大也；煌，盛也；据丝绸之路之要冲，中西方贸易的核心中转站。这个平台也要搞成个枢纽。目标就是团队同学上班，第一开钉钉，第二就是开敦煌（甚至连编辑器都能敦煌帮你唤起并定位到对应的仓库目录去），前端业务应用的开发，整个流程在这个系统上都能单人搞定，且不会有阻塞感。
现在来看第一阶段目标已经基本上搞定了，昨天那哥们又被我拉来，我们聊了下 IDE...
三、如何推动基础架构项目落地 - Scott
Q: 请教Scott：这些好看的图表都是怎么做的？
A: 我常用的作图工具就是 XMind Zen/Processon/Keynote，应该可以涵盖大部分作图需求了。
四、如何推动基础架构项目落地 - 芋头
1. 已回答问题
Q: 请教芋头：这次基建很多都是与后端、运维打交道的，那这块都是如何推动（除了内驱，如何说服更高领导来支持）？
A: 首先需要团队具备后端和运维相关的知识沉淀，例如做服务，肯定需要了解后端，做持续集成，肯定会涉及到运维的知识，通过这些事情一步步去沉淀这方面的经验，同时 leader 自身也需要去扩展自己的知识边界，这样才能和这些技术栈的角色更好的交流和合作。
Q: 请教芋头：ppt上的蓝风文档打不开啊，可以了解学习下吗？
A: 这些基建大部分都是内部资料，没有对外开放的计划哈，主要是对外开放需要对大家负责，暂时还承担不了这个重担，所以只是简单分享下思路。
2. 直播未回答问题
Q: 请教芋头：类似定位兼容多个地图时，势必会导致文件非常大，不会担心api运行慢的性能问题么？
A: 这个基本就是兼容百度和高德两个，另外引入他们的JSSDK是异步的，初始化参数用哪个就会依赖哪个，不会造成文件大的问题。
Q: 请教芋头：如何使用node作为微服务API网关（BFF）？
A: api 网关，可以很灵活，也可以很定制化，可以是图形化的编排，也可以就是手动写路由代码，这个可能还不是重点，重点是网关层的定位是什么，我们现在的尝试，在小型的 SaaS 业务中，SaaS 领域的服务，用 java 实现，但是与基础服务的对接以及展示层的输出由 node 实现，例如注册登录、店铺用户、聊天银行卡等之类的对接，与业务领域本身无关，由 node 实现，这也只是一个探索，另外我们也在探索 api 网关编排图形化的方式，不过 BFF 层的逻辑，往往不是转发接口这么简单，如果是，这一层独立存在的必要也没有了。
Q: 请教芋头：自建UI组件库的文档是使用的什么搭建的？
A: 自己实现的一套机制，样式应该有参考 elementUI
五、如何推动基础架构项目落地 - 崇志
1. 已回答问题
Q: 请教崇志：阿里体系团队诸多，各个团队也有独立的业务述求和技术产出，那如何平衡自研平台，跨bu共建和成果推广间的关系？
A: 基本上我们还是遵循避免重复造轮子的原则，先梳理贴合我们团队具体的开发流程，然后在各个开发流程上去调研集团内或社区是否有成熟的基建可用，如果有，则基于此之上进行二次开发以适合我们的开发需求。如果没有，则考虑自研。如果自研的基建具有足够的通用性，就会考虑推广到集团内跨BU共建。
2. 直播未回答问题
Q: 请教崇志：rmx-cli 开源吗？
A: rmx-cli目前用到很多集团内部的公用包，所以无法开源，这个命令行工具主要还是贴合自己团队开发需求的产物。
Q: 请教崇志：magix是开源的吗？
A: magix是开源的，github地址：github.com/thx/magix
Q: 请教崇志：AI识别页面是基于什么原理和技术实现的？
A: 技术主要基于目标检测（object inject），标记一些历史交互稿或视觉稿页面上的元素及其位置通过机器学习目标检测算法（例如：ssd），提取出一些关心的页面元素+OCR识别文字，就能提取出页面的结构化信息。原理可以参考微软最早的开源项目：github.com/microsoft/a…
Q: 请教崇志：能细讲下AI识别页面，以及效率提高多少 ？
A: 目前识别元素的能力还在beta阶段，不借助识别可以手动填写有那些元素和文案也可以进行手动可视化搭建。AI的能力还在beta阶段，集团其他部门比较成熟的产品可以看看 imgcook.taobao.org/
Q: 请教崇志：vframe微前端方案，区块和宿主依赖的框架版本不一致如何处理，比如依赖的React或者vue？
A: 首先我们提供了精简后的 [magix运行环境] 的包，只包括运行业务view所需要的模块加载、基础类库、magix核心代码、组件等，然后再提供一个 magix-ports-react 包，用来处理一些业务上约定的事情，比如view的登录与权限控制等等，然后这样就可以将magix框架的业务view嵌入到react体系的页面当中了。
Q: 请教崇志：前端开发时的mock阶段，前端是怎样造开发数据的呢？服务端接口变动是，前端怎样维护这套mock数据？
A: 因为我们有统一的接口管理平台RAP，所以是由后端开发人员在RAP上录入mock接口数据，同时填写好接口说明，我们会要求后端接口录入一定要精确 ，如果接口变动，需要体现在RAP上，我们前端以RAP接口数据为准。
第三期 2020.3.28 在线上直播，主题 「前端搞搭建」，扫码关注「前端早早聊」公众号参与报名：
这篇关于78 个前端基建问题的讲师答疑合集 | 第二届早早聊的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！
- 2024-05-30毕设私活神器
- 2024-05-30html
- 2024-05-09一定要避坑:关于微信H5分享，温馨提示你不要再踩坑了!!!
- 2024-05-09本地项目放到公网访问！炒鸡煎蛋！
- 2024-04-07金融企业区域集中库的设计构想和测试验证
- 2024-03-11前端CSS的工程化——掌握Sass这四大特性就够了
- 2024-02-21h5关联css样式（html怎么和css关联）-icode9专业技术文章分享
- 2024-02-07Firefox禁止远程字体加速网页加载及图标字体补充安装
- 2024-02-07一个菜鸡前端的3年总结-「2023」
- 2024-01-18最火前端Web组态软件(可视化)
