[技术分享]让前端开发更高效

最近两天我在杭州参加D2,会上见到了一大圈熟悉的面孔,阿里举办这样的会议不仅仅是树立自身的技术形象,也创造了一个让各路工程师集中到一起的好机会。昨天去了一趟淘宝,很感谢圆心的招待;今天和玉伯一块吃饭,也是相聊甚欢。

下午我主要分享是的《让前端开发更高效》,刚才搜了一下,发现CSDN简直神速,已经有新闻稿发出来了。我也趁热放出Slide吧:D2分享:让前端开发更高效

这次分享主要介绍的是我现在主要在负责的百度前端集成解决方案(FIS),我们希望能通过FIS,简化开发、快速解决需求。主要分成组件化、自动化两大部分来展开 —— 这也是FIS的两大核心。由于时间很有限,分享只能浅尝辄止,希望思路对大家有所帮助。将来也会找机会分享其中的实现细节,并且FIS也已经有开源计划。

我的twitter是 @cnberg ;新浪微博是 @berg ,如果大家有什么问题也可以在下面留言或者微博联系我。

13 条评论

  1. Allen.M 于 2012-07-09 @ 15:49:46

    去现场听了你的分享,受益颇多。但是我有些问题,当时没机会问,在这里写下吧。

    我想知道你们这个系统有没有解决静态资源的缓存问题。静态资源一般都会设置一个较长的过期时间,这样的话,每次做需求,都会涉及到一个清除缓存的问题,常见的解决方式是,监听静态文件的变化,如果变化了,静态资源的 url 上就加一个时间戳。但是 css 里面引用的图片呢?如果我更改了某背景图的内容,css 中没有修改这个图片地址,这种情况你们的这工具有处理吗?

    另外我还关注应用平滑升级到新版本的问题,我们静态资源是有专门的静态资源服务器,前端和后端也是相对独立发布的,发布过程无法让这两者完全同步发布。那如果这次需求,前端和后端都需要更改,而且无法兼容以前的版本,那如果前端和后端能够同时发布,用户自然能够平滑过度到新版本。实际操作,我经常采用,新建一个静态资源文件,让后端来引用这个新的文件,发布过程让前端先发布(发布成功后,旧版本和新版本同时在线上存在),然后等后端发布成功后,由于引入的新的静态资源文件线上已经准备好,用户也可以平滑过度到新版本。

    现在这个是手工做的,如果你们解决了这个问题,让它自动化,我想看看你们的思路。

  2. berg 于 2012-07-10 @ 21:21:00

    [Comment ID #16730 Will Be Quoted Here]

    关于css中引用图片时间戳的问题:在fis中,会在内容处理阶段分析css语法,找到图片,如果发现图片有变化,会重新编译css sprite,因为图片也是一类资源,在系统中和css、js并没有什么本质的不同。其实中间稍微比较麻烦的是分析css语法,不过这都是一次性工作,做好以后就长期不用变化了。

    关于平滑升级的问题:我们的思路和你的基本相同。因为我们所有的资源都是有md5戳的,因此静态资源先上线不会有任何问题,然后再上线模板和后端。

  3. Allen.M 于 2012-07-11 @ 10:23:04

    [Comment ID #16735 Will Be Quoted Here]

    看上去,你们连 css sprite 也会通过这个系统自动生成,是吗?

    关于平滑升级的问题,我想知道更多细节,你说所有的资源都有 md5 戳,那模板中引入的静态资源需要指定 md5 戳吗?我猜是不需要的吧,需要的话就太麻烦了。但是如果不需要,那应该就会自动更新吧,我猜测是下面的思路:

    这次需求只有前端代码更改,后端不需要发布,前端代码发布后,线上的系统自动发现了有新代码发布,更改模板中引入的静态资源 md5 戳。

    如果按照我的猜想,那平滑升级要怎么做呢?因为先发静态资源,那按照上面这个逻辑,静态资源发布成功后,模板文件中引入的静态资源 md5 戳会立即变掉才对,那岂不是就发生了,后端代码还没上线,新的前端代码已经被用户访问到了的情况。

    以上是我的猜测,我想了解下你们怎么处理这种情况的。谢谢了。

  4. berg 于 2012-07-11 @ 10:42:16

    [Comment ID #16738 Will Be Quoted Here]

    当然,css sprite也是通过这个系统自动生成。

    模板中引入的静态资源用户压根不用关心,所有的md5戳都是系统生成的。我说一下具体的流程吧。

    1. 完成开发,编译,此时静态文件的最终md5戳就已经确定了,生成静态文件包,以及和静态资源包配套的一个运行时php(你可以简单的这样理解)
    2. 发布静态文件包,因为md5的存在,不会覆盖之前代码
    3. 发布模板和后端程序,包括前面所说的php,此时页面中的引用修改,用户可见修改效果。

  5. Allen.M 于 2012-07-11 @ 11:43:02

    看到你上面的解释,也就是说,页面中静态资源的引用修改,是发生在模板和后端程序的发布环节,对吧。

    那对于我上面提到的,如果这次需求,只需要更改前端代码,后端和模板代码不需要更改。对于这种情况,是不是也要额外发布一次模板和后端代码呢?

  6. berg 于 2012-07-11 @ 15:04:27

    [Comment ID #16740 Will Be Quoted Here]

    的确是这样。如果静态资源和模板每次都是同时上线,就不会有额外发布的问题,否则,只修改了静态资源,也是要上线模板的。

  7. Allen.M 于 2012-07-11 @ 15:08:14

    [Comment ID #16742 Will Be Quoted Here]

    好的,明白了,我也为了这些问题纠结了不少时间,关于平滑上线这个,想法和你们已经做的基本一致,但是一直还没机会和时间去做,静态文件编译没你们考虑的那么多。这次听你的分享收获了很多,非常感谢你的分享和耐心解答我的问题。

  8. Allen.M 于 2012-07-11 @ 15:09:30

    另外等待你们开源,应该很多东西我们可以拿过来用。

  9. zhangchen2397 于 2012-07-16 @ 19:41:38

    [Comment ID #16740 Will Be Quoted Here]
    您好,我们公司这边后端有一个服务,如果有一个需求,只需要修改静态文件(css, js),不需要修改模板或后端代码时,只需要把修改好的静态文件发布就可以了,不需要额外去发布模板了。

    因为后端的服务会监听静态文件的变化,如果发布有变化,会在引用静态文件的url后面自动加上时间戳。

  10. Allen.M 于 2012-07-24 @ 12:29:24

    [Comment ID #16770 Will Be Quoted Here]

    这样监控文件变化的方式,带来的副作用就是:无法平滑上线了。。。
    因为每次发布后,自动加上时间戳,那用户就立即载入到最新的 js, css 了。但是后端的配套代码现在可能还没上线。

  11. Allen.M 于 2012-07-24 @ 12:29:59

    [Comment ID #16805 Will Be Quoted Here]

    也不是“无法”,没这么绝对,只是不好处理了而已。很多时候可能需要手工来处理下。

  12. Xj.Ye 于 2012-08-05 @ 00:39:04

    看到第一条评论,马上就感觉这是我们现在遇到的问题,@Allen.M,才发现曾经和你谈论过。
    关于发布过程中平滑过渡的问题,这应该是一个可行的方案,实际操作中可能会很有很多的细节需要处理,如修改公共文件时模板如何全量编译?全量发布?多人同时发布时前一个人将我的时间戳更新了,而我真正的对应模板还没发布等等… …

    前面还看到了“重新编译css sprite”,如何重新编译css sprite?你们是只维护icon,而雪碧图是自动生成吗?

  13. berg 于 2012-08-05 @ 11:17:22

    [Comment ID #16928 Will Be Quoted Here]

    1. 全量发布是必须的,先发静态文件(带MD5的,不存在覆盖问题),模板上线就可以直接用已经上线的静态文件了
    2. spite是自动生成的,没错。

发表评论

火花来自思想的碰撞,请留下你宝贵的评论吧: