滴滴公共FE团队答群友问

【2016年】【8月】【前端之巅】【滴滴公共FE团队技术开放月】，一连三场分享活动。本文是三场活动中，【前端之巅】的粉丝——“淀粉”们的提问和嘉宾精彩回答整理而成。回顾精彩的分享内容，请关注【前端之巅】公众号并发送“滴滴”。

张耀春：如何打造公司级公共前端团队

淀粉Q1：请问通过图片快速生产h5是怎么做到的？

张耀春：其实这个是运营的需求，我们做到了 TMS 这个系统里面，其实大家有没有发现我们做的事情是类似一个闭环的，组件库服务于 MIS，TMS 服务于所有类似前端场景，图片转 H5 其实就是依托我们做的 ui + 数据推送（在一个运营界面，用户提交一个图片，然后我们有一个模板，进行替换，然后推送到 CDN，生成一个线上地址）

淀粉Q2：可否详细讲下Mis的Node前后端分离架构、大概功能和可以解决的问题？

张耀春：依托我们的DNode服务和我们完备脚本化运维：我们也写了很多微服务：比如账号登录、权限配置，MIS 的流程大致是：所有用户的流量是打到我们的前端 DNode 机器上，然后再进入 DNode 服务本身的 middleware， check 用户的登录状态，方式就是通过登录Node SDK，如果用户登录走到我们对应的业务页面，在页面页面我们可以在前端组件发起对后端 API 的请求，解决的问题：前端可以独立部署，依赖的只是接口 wiki，跨域的问题（一般要求后端开跨域或者我们 nginx 反向代理）。因为现在的普通 MIS 大部分还是嵌入在一些 PHP 里面，开发调试，上线都不可控

淀粉Q3：您好，关于工程化项目是如何组织目录，我看到有将特定的功能的文件都放到同个文件夹，如header.js header.css header.html放到同个文件夹下打包加载而不是js都放到同个文件夹下，想请教下贵公司如何做的？

张耀春：我比较喜欢回答工程化的问题哈，在这方面我们做的尝试比较多，从 grunt gulp webpack rollup，目录组织其实是同各个构建工具对应的解决方案一致的（目录结构和打包脚本里面一些配置是关联的，我们一般通过脚手架来固定目录结构），比如我们 mofang-pc 项目前面展示的：组件// 目录结构
components
didi-list
didi-list.html
didi-list.js 这个是和当前应用的 angular + webpack 有关系的，并不是固定的。

淀粉Q4：前端性能监控有做吗？

张耀春：在魔方的前端规范里面那个图，大家可以看到我们有统一的数据提交 SDK，我们会在 H5 以及我们流量比较大的 webapp 做很多的数据埋点，对应可以在数据可视化平台看到，当然我们这方面还需要做的更多的是一些用户行为的数据上报

淀粉Q5：滴滴的服务端渲染是如何处理的？如何隔离及复用前后端代码？

张耀春：滴滴的服务端 -- 这个有点大哈，我可以接受一下我知道的：server render 目前的场景是服务于我们数据可视化的一个方向，在同样的页面，我们可以配置 N 个 iframe，通过 server render 来展示各个数据源的可视化组件。还有就是 一般的H5，比如我们最近刚做的用户登录后需要获取用户的某一个特质值，然后去第三方数据里面获取里程，很多业务同学可能会依赖 PHP 或者其他，我们的做好是依托 DNode 服务，前后端代码在一个项目里面，DNode 服务或在 server 里面去通过前端统一登录的组件返回的一些用户特质，再去用户验证微服务（Node SDK） 去验证，再去第三方接口查询，所有的这些成功后，再把里程数据打到模板。

黄轶：滴滴WebApp实践经验分享

淀粉Q1：滴滴的构建工具用的是FIS吗？

黄轶：恩，滴滴公共团队这边的WebApp项目是基于scrat做构建的，它是在FIS基础上二次开发的产物。
公共这边的一些基础组件库，是基于webpack打包的。

淀粉Q2：公共团队在支持业务团队方面（问题咨询、排错等），有什么好的经验分享?

黄轶：
1.首先要有wiki和demo。
2.会建一个钉钉群和一个微信群，把需要咨询问题的同学和相关技术产品同学拉到一起，常规问题都会在群里解决。
3.也会定期组织内部分享，和业务的同学一起聊聊，问问他们在做什么，有什么痛点，也告诉他们我们做了什么，有什么可以用的。
4.服务意识很重要。当业务同学出现紧急情况比如上线依赖公共的一个服务出现问题，一定会安排人力第一时间支持和解决，不管是加班甚至熬夜（当然不是常态），会让他们对公共产生安全感和信任。

淀粉Q3：能否介绍下你平常一般怎么学习前端技术的，看书？还是找技术网站，或者只在GitHub上看?

黄轶：
1.看书。系统的学习是很重要的，沉下心来把书中的技术点掌握，一定会比只在网上看一些快餐类的文章效果好。而且出来前端语言方面的书籍，一些周边的书籍比如《HTTP权威指南》、《设计模式》、《精通正则表达式》等等不错的书都可以好好研读。当然，关注一些Weekly也是很好的习惯。
2.兴趣导向。我很喜欢编程，所以平时也会多敲代码，除了工作之外，我会花自己的业余时间学习。可以找一些自己的兴趣点，比如对h5游戏感兴趣，我就自己写了几个小游戏如2048，连连看。比如连连看我想做多人对战，就又顺便学习了socket.io。
3.github上看优秀的开源代码，这里是要有选择性的看，因为毕竟时间经历有限。举个例子，比如我最近在用Vue框架，我会想一下她的数据视图绑定原理是怎么实现的，这样带着问题去看。看之前我会先看它的官网、文档和一些周边文章。对他的功能和设计大概了解了以后，再去看实现的细节。看源码的过程中看到一些不错的设计的代码吸收过来。

淀粉Q4：面对层出不穷的框架和工具库，我们该如何选择？

黄轶：

1.要选择适合自己业务需求的框架，这个“合适”是一定是需要有经验的架构师或者高工做技术选型。
2.一些基本场景参考，比如做PC内部MIS系统可以选择Angular和React，移动端可以选择Vue等。
3.要看这个框架or工具是否足够“靠谱”：是否有人维护，issue是否能及时响应，和周边社区和生态工具是否完善。
4.关于我们，公共团队相对业务团队一定是跑的更快的，在不断的调研试错，内部培训+评审，有了解决方案就大胆实践。

淀粉Q5：组件的版本控制有什么手段?

黄轶：比如用webpack构建的时候，可以在output输出的时候在目录结构上加入版本号，版本号可以读取package.json文件中的版本号。举个例子，可以这样配置：
【【【【【【B问题2图片】】】】

淀粉Q6: 开发移动端如何选择使用原生iOS开发还是html5开发

黄轶：这个问题有点大，原生开发和h5开发其实各有所长，主要还是看场景。原生的优势可能在于一些对性能要求高的场景，比如游戏，体验会更好。H5开发在于一些频繁迭代的页面，h5上线简单，没有发版的压力。H5还有一点优势，可以减少包体积，h5和原生混合的应用场景的趋势约来越多。

淀粉Q7:前端组件化开发与管理，是怎样进行跨模块调用的，以及后期维护的方式。

黄轶：
1.跨模块这个概念有点模糊，如果是组件依赖一些公共资源，我们一般会和components平级放一个common目录，这个目录里会有一些通用的JS、CSS、图片等公共资源。如果是指组件之前的通讯，那么如果是父子组件的通讯，一般来说父组件会依赖子组件，它能够调用子组件的方法。而子组件是不依赖父组件，它是可以放在任何地方，可以通过事件的派发通知父组件，但不能主动调用父组件的方法；如果是平级组件，可以通过全局事件中心去做通讯。
2.组件的维护肯定是把组件依赖的js、css、模板、图片放在一个目录就近管理。

淀粉Q8，随着业务复杂性递增，单元测试是否同步跟进。UI层面是否部署自动化测试。开发人员是否需要编写测试代码。

黄轶：这是个好问题，单元测试确实很重要，现在一些流行的MVVM框架比如Vue，都提供了很好的单元测试。UI部署自动化测试确实也很重要，这一块滴滴这边做的也还不够，做了一小部分的尝试，大部分页面还都是在黑盒测试。开发人员如果业务压力不是特别大的时候，编写一些测试代码是很好的习惯，可以基于现在一些流行的测试框架写，是值得提倡的做法。

淀粉Q9：对于小公司，只有一个前端，没有架构师，对于技术选型和单元测试等相关，我们该怎么办？

黄轶：
1. 可以多关注一些业内的比较热和新的技术，然后看看他们的应用场景，有没有和自己业务比较贴合的点。
2. 可以加一些类似“前端之巅”这样的技术讨论群，和一些厉害的或者有类似经验的人交流。不过要注意提问题的方式，问题首先是要自己经过思考的，其次是把问题具象化，不要问太大的问题。
3.有的时候，对于创业公司而言，可能快是最重要的，所以做技术选型的时候也可以规避掉一些学习成本高的框架，选一些能快速上手开发业务的。
4. 最关键的一点，还是要不断自我学习，提升自我的能力。在做业务的时候多思考，看看流程中哪些不合理的地方，可以提升效率的地方，有没有好的技术和工具去帮你解决和提升效率。把大问题简化拆分成一个个小问题，一点点的优化。

淀粉Q10：对于展示性，交互比较多，数据量少的活动，专题类页面，怎么快速开发，进行组件化开发？

黄轶：
1. 对于h5专题运营活动类的开发，短期可以基于一些比较流行的h5开发框架开发，过程中可以做抽象，把一些通用的功能封装，模块化，组件化，未来可以复用。
2. 长期来说可以做一套h5编辑器，提供若干套模板和若干种组件，通过配置化或者可视化编辑的方式，让运营同学自己编辑生成一个运营活动页面。
3. 我们公共这边还整理了一套动画案例库，对于复杂的动画做收录，便于以后的参考和复用。

王静：公司级组件库以及MIS系统的技术实践分享

淀粉Q1：与后台交互都做一层转发，这样会不会影响性能或增加响应时间？

王静：在性能和响应时间上面，我们最多的都是在h5页面做监控，每天量级在百万pv, 耗时也均在可控范围之内，同时我们还做了容错机制，没有大家想象中的那么差。

淀粉Q2：ng或者react都有打包文件过大的问题，异步加载有啥好解决办法？

王静：目前我们项目上组件是支持自定义合并打包的方式，也开通了cdn gzip 加速。同时能够和 i在第二次分享中提到过，我们会使用webpackde require.ensure 实现异步加载， 我们还有combo 服务，支持动态合并。

淀粉Q3：移动端如何提高性能

王静：这是一个面试中经常被提及的问题，相信网上的答案一定非常的全面。比如代码优化，减少http 请求、减少dom操作等。

淀粉Q4：使用者如何使用这个组件库

王静：为了方便实用者快速准确的使用组件，我们提供了魔方官网，上面记录了我们所有的组件，并附带详细的组件说明，组件的demo及代码都展示在页面中，用户可以直接将所需组件代码复制后，修改响应参数对应字断即可使用。分享中有提到，我们为了节约使用者搭建项目的时间，我们搭建了组件库响应的脚手架。而且组件库是按照版本迭代的，每次出现新的版本，我们会已最快速度同步到魔方组件库。

淀粉Q5：组件库搭建的时候有没有遇到过业务线的前端同事没有使用组件库的情况、或者不使用组件库的情况？是通过定期人工review代码要求业务线同事使用组件库？

王静：开发组件是一件容易的事情，推广组件是件让人头疼的事情。在推广组件的时候，我们也会遇到同样的问题，“我原本业务线就已经有了， 为什么要用你的呢？” 对于这种情况，我们不会强制必须用我们的，首先要做的就是树立好用户口碑，不辜负信任我们的用户。为使用者提供7*24小时 vip 服务，并且提供各种渠道的答疑解惑群，解决使用者使用上的疑问。大家口口相传，组件的推广就会很顺利。其次，我们还会在各种渠道上面，为我们的组件库做宣传，其中包括我们的新员工入职手册。最后，我们也允许使用者和我们共同完善组件，我们review他们提供的代码。

淀粉Q7：刚才看react组件通过componentwillreceiveprops调用setstate,为什么不直接用props？

**王静：**props是由外部组件所决定，并且会影响到component的render，我们在componentWillReceiveProps方法中调用setstate方法去触发页面数据的更新或者状态的改变。

淀粉Q8：您好，我想问下很多插件有现成的，比如iscroll日历插件等，滴滴再内部开发初衷是什么？为什么不直接拿来用呢？

王静：现有的插件十分丰富，功能强大，有的时候会出现一个问题，你在使用的时候出现问题不会得到及时的响应，为快速解决问题你可能要去研究它的源代码。有血插件并不能准确的完成你的需求，有的组件可能功能包罗万象，你只用一少部分。这种情况下，建议还是花费一些精力去自己开发。就像上面所说的，在 h5 方向我们又自己的bscroll ，有专人维护，代码可控。但是，如果有特别好、提问题能及时响应的、文档齐全的插件，也是强烈推荐使用的。

淀粉Q9：问一下实现上的问题，我看到pc控件库核心文件里有jq，还有些控件里打包了jq插件，想问下pc的angularjs控件库的实现上，有使用jq么，jq是否用在指令中操作dom，替代的内置jqlite？如果是ng封装jq控件，是什么样的思路？

王静：在开发组件中，在没有特殊使用的情况下，建议还是使用angular中内嵌的jqLite，它是jquery库的一个子集。使用angular.element 方法会返回一个jqLite对象。如果在一些极少的情况下内置的无法满足，可 i子集写一个简单的工具函数。

淀粉Q10：魔方组件库源码是开源的么？

王静：实在抱歉。我们的魔方组件库不是开源的。

淀粉Q11：没有做到前后端分离，前端只负责开发angular组件，后端只是使用开发好的组件拼接就可以完成MIS的界面开发吗？

王静： 其实我们这边在开发 mis 项目上的人力有限，有些比较着急的业务线，就由后端同学自己开发，我们提供完善的文档和相应的支持。项目完全维护在他们自己的系统上面，我们只是提供一套成熟的组件库。