前端开发体系建设日记 about blog HOT 189 OPEN

mark 再看

from blog.

mark一下。

from blog.

seajs开发体系，支付宝团队前端开发体系，以 spm 为构建和包管理工具
fis-plus，百度绝大多数前端团队使用的开发体系，以fis为构建工具内核，以lights为包管理工具
edp，百度ecomfe前端开发体系，以 edp 为构建和包管理工具
modjs，腾讯AlloyTeam团队出品的开发体系
yeoman，google出品的解决方案，以grunt为构建工具，bower为包管理工具

总结的很好

from blog.

@litson 不会看了半天还是只看到fis吧。。。工具不重要，如果用grunt能实现也挺好。问题是工具之外的过程、步骤

from blog.

@LeoYuan

这个问题是有取舍的。

虽然在某个时间点上看，是有三个产品插件，共用了一个公共库，但当公共库升级的时候，很快就会出现以下两种情况：

1. 部署这个公共库的唯一最新版本，三个产品插件立刻使用它。
2. 部署这个公共库的两个版本，需要升级的插件升级依赖，不需要的使用旧版本。

方案1有一个比较高的工程风险，使得升级公共库的时候要非常谨慎，而且有着比较高的回归测试成本。方案2会产生冗余，跟install方案没有本质区别。

我经常对做工程设计的同学说的一句话就是：

两害之中取其轻

工程设计通常没有完美方案，很多环节都是在寻找平衡点，所以针对这种场景的两害风险与回归测试成本 vs. 性能上的冗余代价 的取舍，这是从业务特征来的，没有统一的定论。

从你的描述中我大概能感觉到你们是把一个完整的产品拆分成多个产品线来开发的。所以可共享部分比较多，而且产品与产品之间页面跳转比较频繁，用户不是独立访问每一个产品的，所以这种情况下共享的收益就比较大。

而我们是多个产品，彼此之间访问独立，没有多少跳转的情况，所以共享的收益较小，而冗余的收益比较大（因为减少了风险）。

from blog.

工程化还是很复杂的一件事情

from blog.

So, sexy !

from blog.

= =。。。好厉害，好多新东西都没办法用到。。。所以也不知道怎么学。。。学的东西，是应为在使用，学不到，是因为，没在用。

from blog.

工程化的思考除了需要过硬的编程能力，更多需要的是对人和工程本身的深刻洞察。大赞！

from blog.

不愧是国内工业化前端第一人！！服！

from blog.

当前端项目达到一定规模后，工程问题将成为主要瓶颈，原来孤立的技术要素开始彼此产生影响，需要有人从比较高的角度去梳理、寻找适合自己团队的集成解决方案。

說得好！

from blog.

满足一切前端开发需求，诚不欺我也。

from blog.

4天解决如此多的开发需求，给力

为何没有上后端静态资源管理以及后端模板的组件化能力呢？是时间问题还是有的新的思考？

from blog.

真的很长，晚上回去慢慢看。

from blog.

@hefangshi

不同的公司要采用不同的技术选型，以松鼠团队现状来看，这样的选型是比较合适的，后面会做更深入的探索。

from blog.

@fouber 我们有一套基于 Ruby 的集成方案 Linner 在团队实践一年了, 思路一致.

在使用上追求简洁, 易用. 尤其体现在配置上.

from blog.

@SaitoWu

不错，赞一个，每个团队都会实践自己的解决方案，相信思路上也会一致，因为这个过程是普适的。

from blog.

赞

from blog.

牛逼~

from blog.

写得很好，赞一个

from blog.

好专业啊

from blog.

赞~

from blog.

写的真好 赞一个 战斗力真强

from blog.

NB

from blog.

给力！！学习了！！！

from blog.

@yyman001

早晚会用到，到时再去了解也不迟

from blog.

太牛逼～

from blog.

赞 Fis
关于按需加载有个问题，请教下。
我理解，按需加载其实是按照 Page 的粒度进行的，比 Module 更高一层。理论上讲，Page 会比 Module 少很多。
基于这种想法的按需加载方案：
1、增加两个(js + css)列表(排序防止不用顺序不命中缓存)记录已加载的 Page（直接 require.async 的 Module）。
2、require 新的 Page 时将 1 中的列表拼接发送给服务器。
3、服务器解析依赖，返回对应的 Module 以及依赖的内容。

这样可以：
1、不再需要将所有依赖关系发送给客户端，减小文件大小。
2、请求链接更短(期望值)，更清晰。

稍微增加服务器处理，有 Cache 情况下可以无视。

这种方案是不是更好呢？

from blog.

@ZoomZhao

了解你的意思了，这也是一种不错的机制，需要把依赖关系表产出给静态资源服务器，然后去diff差异。并不一定是page，只要require.async把自己被调用过的参数记录下来，然后再发起加载请求的时候带上就好了，在后端做diff，非常机智！

from blog.

大局观啊！我用grunt做前端构建工具时，就把项目文件按照css,html,js,image来划分的。后来才发现，特码的，我写的组件，css，js，图片太分散了。外人怎么引用啊？

from blog.

写的好详细，点赞

from blog.

佩服云龙，用fis基本上不用去关注构建的任何问题了，只需关注业务本身，开发效率提升不少！继续推广，普及fis，不同公司在fis的基础上都会很快搭建出一个符合个性化的前端集成解决方案！

from blog.

正好在梳理工程上的一些问题，lz此文真是雪中送炭那，给了不少启示，十分感谢~

from blog.

长见识了

from blog.

是啊，我也是这样想的，看了这篇文章受益不少

发自我的 iPad

在 2014年4月30日，10:39，xiaomingming [email protected] 写道：

大局观啊！我用grunt做前端构建工具时，就把项目文件按照css,html,js,image来划分的。后来才发现，特码的，我写的组件，css，js，图片太分散了。外人怎么引用啊？

—
Reply to this email directly or view it on GitHub.

from blog.

component_modules目录存放外部模块资源的意思是这里存放一些公共的模块，例如公共组件等公共资源吗？
如果是这样的话，每新建一个项目都要将所有的公共资源拉到本地来？那这些公共资源又是怎样维护的？

from blog.

通过compoment或bower。

发自我的 iPad Mini

在 2014年5月2日，16:31，Dongming Ji [email protected] 写道：

component_modules目录存放外部模块资源的意思是这里存放一些公共的模块，例如公共组件等公共资源吗？
如果是这样的话，每新建一个项目都要将所有的公共资源拉到本地来？那这些公共资源又是怎样维护的？

—
Reply to this email directly or view it on GitHub.

from blog.

@xiaoji121

我提供了一个命令行工具，叫

scrat install name@version

新建项目，用户可以创建一个 component.json 的文件，内容为：

{
    "dependencies" : {
        "xxxx" : "1.0.0"
    }
}

然后在项目下执行scrat install就能自动在项目中拉取过来了，而真正的代码是维护在其他仓库中的。

from blog.

赞！

from blog.

是不是每个项目的工程里面都会有一份公共模块的拷贝，发布时这些公共模块也会作为项目的一部分随项目代码一同发布到线上？

在 2014年5月2日 下午5:16，张云龙 [email protected]写道：

@xiaoji121 https://github.com/xiaoji121

我提供了一个命令行工具，叫

scrat install name@version

新建项目，用户可以创建一个 component.json 的文件，内容为：

{
"dependencies" : {
"xxxx" : "1.0.0"
}}

然后在项目下执行scrat install就能自动在项目中拉取过来了，而真正的代码是维护在其他仓库中的。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-42007425
.

from blog.

@xiaoji121

是的

from blog.

不明觉厉，我是来点赞的

from blog.

涨姿势。

from blog.

松鼠浏览器的项目来了：这工期还是太长了，能不能再压一下

from blog.

其实我是来围观的。顺便发一下，这个前端知识收集：
https://github.com/jikeytang/front-end-collect

from blog.

建立alias那段fis-conf.js代码有一行错误：map.alias[match[1]] = id; 应改为 map.alias[match[1]] = file.id; 不然就报错了。很少见到这么完整的讲清楚前端流程的文章，写的超棒。

from blog.

@cospring 多谢提醒，马上修正

from blog.

好文！翻来覆去看了将近十遍，终于理清一些东西！赞龙兄！哈哈！

from blog.

@zhaowx

写的太长了。。。所以要反复阅读么。。。

from blog.

按照这个开发日记，自己也做下来了。现在剩下合并请求（combo ）这块还有些迷茫。
在这个blog中只是提到了在得到依赖关系表之后可以将请求合并，但并木有什么实现办法啊。
我看了下seajs的，有一个seajs-combo插件，也需要配合服务器开启combo功能。 咱这边能详细一些么，可以实施一下！
谢龙兄！

from blog.

@zhaowx

我在文档中提到过seajs-combo的问题，这个你可以再看看那部分的说明。

...
第一个问题还好，尤其是在gzip下差不多多少字节，但是要配置js压缩器保留require函数不压缩。第二个问题就比较麻烦了，虽然seajs有seajs-combo插件可以一定程度上减少请求，但仍然不能很好的解决这个问题。举个例子，有如下seajs模块依赖关系树：
...

文章中上面那段文字后面我比较详细的叙述了关于模块化框架的设计思路。值得注意的是，业内目前没有设计的非常好的，兼顾了性能的模块化框架，因此我们通常要自己动手实践，其依据就是我在文章中说到的原理了。

这里有一个框架： https://github.com/scrat-team/scrat.js/blob/master/scrat.js

就是这篇文档中提到的一个模块化框架的具体实现，你可以参考一下。其核心实现是借助工具分析生成的依赖关系表来设计模块化框架的接口，你可以看看下面的代码，这样的接口改怎么实现：

require.config({
    "deps": {
        "proj/1.0.4/bar/bar.js": [
            "proj/1.0.4/bar/bar.css"
        ],
        "proj/1.0.4/foo/foo.js": [
            "proj/1.0.4/bar/bar.js",
            "proj/1.0.4/foo/foo.css"
        ]
    }
});
require.async('proj/1.0.4/foo/foo.js', function(foo){
    //todo
});

后面我会再单独写文章详细介绍模块化框架的设计原则。这部分是前端集成解决方案的关键地方

from blog.

嗯，谢谢龙兄这么详细的回复！
我使用了scrat.js,现在也得到了这个关系表。那接下来要是想进行请求的合并，那就需要自己动手实践了，龙兄应该是这个意思吧？
那么在得到完整的依赖关系表之后，就可以按照seajs-combo的思路进行请求合并?

from blog.

@zhaowx

哦，这里确实没有说一个细节，就是我加了一个配置

fis release -p 的时候，生成的结果是：

require.config({
    "combo": true,
    "deps": {
        "proj/1.0.4/bar/bar.js": [
            "proj/1.0.4/bar/bar.css"
        ],
        "proj/1.0.4/foo/foo.js": [
            "proj/1.0.4/bar/bar.js",
            "proj/1.0.4/foo/foo.css"
        ]
    }
});

不加-p参数的时候，就没有那个combo参数了，当然这个功能并不是fis内置的，而是我写的插件实现的，你可以看这里：

https://github.com/scrat-team/scrat/blob/a22737eeba668970cc0bc976b91e04690660f286/index.js#L80

你可以自己根据框架的要求和设计思路自己实现。

然后框架发现有这个combo标记，就会把依赖的资源的请求变成一个combo的url，当然处理combourl的响应问题还是要对应的服务端支持的，这个你可以看这里：

https://github.com/scrat-team/project/blob/master/index.js#L20-L40

from blog.

对对对，就是这个！
大赞！

from blog.

赞+1，一口气看完总体上感觉就是目前团队内部想要整体实现的一个前端集成解决方案（PS：请原谅我偷偷地把内部文档“前端框架解决方案"也更正过来了）……

对开发目录结构这块有一些疑问，想请教一下 @fouber :

ps: 除非你的团队只有1-2个人，你的项目只有很少的代码量，而且不用关心性能和未来的维护问题，否则，以文件为依据设计的开发概念是应该被抛弃的。

我们团队的项目较多，由于历史原因，静态文件目录结构都是按照Js, Css, Images统一把静态文件管理在static.xxx.xxx，APP(包括页面模板)都是放在类似app.xxx.xxx这里，这样做的主要原因是觉得更方便的管理静态资源，提高重复利用，也有利于日后的CDN处理。

但是，按照龙兄所说到的这种目录结构，管理相对来说个人觉得更复杂了，而且像上面有说到的，共用资源的调用也是不方便了……

呵呵，以上纯属个人愚见，有说得不对的地方请多多指教~

from blog.

@xiaoji121 @fouber
借着小鸡的问题再问一下。

假如有一个公共库，用来提供项目需要的所有组件，这时有三个产品插件，都会使用到公共库中的组件，假如按照npm/aralejs/scrat这种软件市场的install模式的话，势必会造成公共资源在三个插件中都有一份copy，而这三个插件最终都会部署到同一个手机主客户端系统中，造成安装包的臃肿。

这是我们真实的案例，目前我们采用的是将这个公共库直接放入到手机主客中，其他业务线插件直接引用，不再有install的概念。

请问你对这种场景有什么好的建议么？多谢。

from blog.

多谢 @fouber 如此详尽的回答， 分析过程真的很到位，赞！
其中至少两点让我觉得特别赞，

方案2会产生冗余，跟install方案没有本质区别。

从长期维护的角度看待这个问题，而不仅仅是停留在当前时刻上。

工程设计通常没有完美方案，很多环节都是在寻找平衡点，两害之中取其轻。

醍醐灌顶

from blog.

想请教个问题，如果我想调试fis的代码（甚至假设要自己写fis插件）,应该怎么弄呢？
试了好几种方式，但总的说来都是要node --debug-brk {fis安装目录}/fis.js 。然后用node-inspector之类的调试器监听
但这样的话程序运行路径就不会是要打包的项目路径了。整个程序会中途退出
调试fis和调试其它Node程序不一样的一点就是它是要依赖当前运行目录的…而Node调试又要指定fis.js所在的运行目录……
难道只能用最原始的console？真心求教

from blog.

@kpaxqin 建议试试看webstorm，调试的时候working directory设置成文件目录，javascript file path设置成fis路径即可。node-inspector的性能比较差，调试FIS比较吃力。

from blog.

@kpaxqin 没有用过node的--debug-brk模式，但是我们自己开发用的是IDE，比如phpstorm、webstorm，都能对fis进行调试。

from blog.

@fouber @hefangshi 感谢回答
我用Phpstorm试了下，在要编译项目的working copy 下设置external libraries 到fis目录，再配置debug config中node的javascript file路径到fis.js，设置要执行的参数release -Dpm
点击debug后在console里看到实际执行的是
"D:\Program Files\nodejs\node.exe" --debug-brk=49628 C:\Users\Administrator\AppData\Roaming\npm\node_modules\fis\fis.js release -Dpm

能进入fis.js里的断点，但是在执行release.js之前就报错
process disconnected unexpectedly
最终也没有打包输出

是我哪儿理解错了吗？

from blog.

@kpaxqin javascript file路径不是fis.js，而是bin/fis这个文件

不太了解你说的external libraries目录设置到FIS下面是干什么，可能不太需要，但是working directory是需要设置到待编译项目下的

from blog.

@hefangshi 非常感谢，在phpstorm下已经弄成功了
核心问题出在我之前是设置到fis.js，正确的应该是bin/fis

external libraries设到fis下是为了在当前项目中打开fis的源码以便打断点，或者有其它做法？

按照console里打印的命令，试了下连接node-inspector（更习惯chrome的调试界面和快捷键），还是和之前一样的问题（调到一半报端口错误），估计是node-inspector的问题了

from blog.

@kpaxqin 明白了，external libraries加上了是比较方便，可以直接导航过去

from blog.

大赞

from blog.

已经收录，谢谢。《免费的计算机编程类中文书籍》 https://github.com/justjavac/free-programming-books-zh_CN

from blog.

@justjavac
ok

from blog.

巧豆麻豆

from blog.

很好，作者是百度的前端开发吧。个人觉得这种框架最好能剥离公司标签。

from blog.

@thankwsx

本人已离职，而且尽量剥离了公司的标签，采用fis作为核心工具，是因为相同的功能用grunt实现几乎是不可能的。。。

from blog.

@fouber 呃，离开百度了啊。有方向吗？要不要到我这里玩玩？

from blog.

前端的架构，对于数据填充我一直有疑惑，目前常见的两条路
1，ajax结合restful
2，后端模板
前者在复杂的页面的情况下请求会非常多，除非后台提供复合接口（但这样就把 接口与展现耦合了）
后者不利于前后端解耦，而且往往会束缚前端的技术空间，项目变大的时候维护难度就会滚雪球

想请教下@fouber 的看法。

from blog.

@hax

已经入职松鼠公司了。。。

from blog.

@kpaxqin

1. RESTFul的情况，一般会多一层复合接口API，就是某种UI接入层，这种做法确实在展现全页面的时候为了性能而放弃了对REST的坚持。工程为性能让步，这是很常见的做法，没有办法。不过其实让步的并不是非常多，仅在全页面展现的时候才做让步。RESTFul的另一个问题是请求要多一次，相比模板直接渲染，还是差一些的。通过loading界面来让用户“感觉”快一些。
2. 选用后端模板，必须要坚持一个原则，就是 一定要让前端工程师写后端模板。绝对不能把分工划分为【前端工程师写静态页面→后端工程师把它变成模板】。而且，要在后端模板中实现静态资源管理及其接口，相关思路，可以看一下这个demo： https://github.com/fouber/static-resource-management-system-demo

我个人是非常推崇方案二的，但不绝对，还是要根据具体的业务场景来选择。在松鼠团队我最终选型了方案一，因为业务的数据要求高度统一，而且移动端比较倾向于SPA类型的产品，方案一的亲和力比较强。

from blog.

@fouber
【必须要坚持一个原则，就是 一定要让前端工程师写后端模板】
一针见血，让后端工程师套模板的弊端已经见识到不少了。
但是前端一旦开始写模板，那么相应的Url路由（页面管理）、模板工具类等需求也会随之而来，同时，由于需要向不同的模板页面输出数据，后端依然不能彻底专注于业务
给我的感觉就是：似乎在前后端结合这个问题上，物理界限和工程界限两者有一定冲突
淘宝这篇文章的思路有点意思：
http://ued.taobao.org/blog/2014/04/full-stack-development-with-nodejs/
和您在上面的看法也有一个共同点：传统后端工作中有一部分其实应该交给前端

再回头看看基于restful服务的SPA，某种程度上说，是否可以理解为把controller层直接搬到了浏览器端，统一了物理界限和工程界限
而基于后端模板的项目，为了提高项目的效率和可维护性，目前的趋势是让前端跨越浏览器这道物理界限，完全控制view层，甚至controller层

from blog.

基于RESTFul的SPA是比较清晰的架构，但是有两个弊端，就是SEO和性能优化。首次全页面渲染总是要多一个数据请求，而且SEO不友好。

前端工程师接手整个UI层不是什么问题，在熊掌公司也这么实践的，fis团队接管了后端框架中的模板引擎模块，路由到没有接管，因为模板渲染并不关心路由问题。controller确实要分成两大类，一类是RESTFul的API处理，另一类是页面渲染的数据拼装处理，第二类使得后端工程师不能专注业务，而是根据页面展现组装模板数据。

目前前后端架构的设计确实还没有一个很好的方案出来，前后端衔接的ui层是一个“脏地带”，理想架构应该能同时满足前端友好、后端友好、seo友好、性能友好，目前来看两者都有缺陷：

淘宝的那篇文章比较著名，不过我觉得nodejs的功效不应该被放大，服务端应用开发和浏览器应用开发是两个完全不同的概念，语言相同不会带来多少好处。

至于其他说什么用nodejs的话可以让“模板前后端都能渲染”，这纯属胡扯，虽然技术上可行，但设计一个这样的开发体系是很困难的。另外有一些说可以“让js在前后端都能跑”也是扯淡，看过某些所谓前后端能跑的js，其实都是这样的代码结构：

if(runAtServer){
    //do something in server
} else {
    //do something in browser
}

是的，输出到前端的代码携带了一坨不需要的逻辑分支，这对于要求低带宽的前端来说好矬逼，而且很容易暴露server端的敏感信息。

说跑题了，总结一下：

1. RESTFul和传统模板引擎各有优缺点，自己权衡吧
2. UI接入层是一个“脏地带”，前端想搞好，应该接管这里
3. 接管UI要做理性的技术选型，别看着亲切就选了，容易自坑

from blog.

@fouber 感谢回复，收益良多
看那篇文章的时候我觉得让前端跨越物理障碍，接管UI层确实是个很好的思路
之前有个SPA项目，被这个脏地带拖累得很惨，现在的项目是维护期的传统模板项目，也觉得开发不够清爽
看那文章我也确实觉得异样，仅仅是语言程度的相通，nodejs方案的说服力似乎并不充分。碍于这方面实践经验尚浅，难以找到问题所在

from blog.

Restful 不是万能，但是以我的理解，并不存在“前者在复杂的页面的情况下请求会非常多，除非后台提供复合接口（但这样就把 接口与展现耦合了）”的问题。Rest相比RPC本来就是大颗粒度数据，你把Rest当成RPC使用才有复合接口的问题。至于说接口和展现耦合的问题，我认为多数情况其实是Rest抽象没做好。

from blog.

@fouber 的图里比较的不是 Restful 和传统模板，而是典型的 SPA 和典型的后端模板生成的方案。其中性能这项，各有优点和缺点，难以简单比较啊。

但基本意思到位的。故我认为理想的方案是新一代模板，或者说表现层描述语言，直接结合两者优点。

from blog.

淘宝那个 nodejs 的方案的关键点其实不是 nodejs，而是获得了一种把本来后端做的事情干掉的可能。这才是最重要的。因此在这点上语言相同是非常重要的，因为前端有这个技能和话语权。很多事情，不是单单技术问题啊。

from blog.

@hax

恩，可能概念上确实有一些模糊的描述。我理解的RESTFul，是指以资源为单位的细粒度接口，但是页面展现的时候，可能要读取多种资源的数据，那么就有合并这些数据请求的需要。

表格中对比的确实更想说是SPA和传统模板的对比，性能部分是考虑传统模板可以一次性渲染出整个html页面，而SPA第一步先请求一个html骨架，然后发起数据请求，这个过程总是没有传统模板有优势。理想的模板方案应该同时满足前后端友好、seo友好、性能友好。4年前FB在velocity上提出的Quickling方案，我觉得目前接近这个要求，但是实现成本略高。

淘宝的那篇文章，关键点不在nodejs，表示赞同。干掉后端的部分事情是有必要的，表示赞同。话语权问题，表示赞同，但还是要提醒大家，不要盲从，在有话语权的前提下，选型可以从容一些。

from blog.

@hax
【Rest相比RPC本来就是大颗粒度数据，你把Rest当成RPC使用才有复合接口的问题】
粒度是整个restful的基础，决定最终接口的可用性，也是比较容易出问题的地方

我理解的“合适”的粒度，一定是与展现无关的，类似传统j2ee架构中的service层
这样一来在面对复杂页面，多种数据、业务组合时，必然会有针对UI合并请求的需要
还有些项目要求把rest同时暴露给第三方开发者，抽象时的粒度会更小

我目前只实际接触过一个restful项目，理解尚浅，有什么不对的地方还望斧正

from blog.

@kpaxqin 合适的粒度与展现无关正是一个误解。REST的一个要点在于对资源的抽象，而此资源不可直接对应于业务逻辑的数据。比较而言，其实更接近“展现”，但是是展现的model，而不是像我们一般写页面的时候会包含许多与该页面几乎无关的非常次要的内容。

出现针对UI合并的请求，不是说不可能出现，但是如果大量出现，其实说明这个对resource的抽象出现了偏差，很可能过分暴露了数据细节。

其实理解REST的关键是在于始终记得，传统的web正是非常REST的，只不过它用的是HTML而不是JSON或者XML之类。所以如果要做一个好的资源抽象，只要想象你还是写页面，但是写完全干净的一个页面，而不用考虑由产品、视觉、技术限制等因素所附加的要素。

from blog.

文章，评论全部看完，收获良多！

from blog.

尽然看完了,不错~

from blog.

@byszhao

真有耐心。。。

from blog.

nice 32 个顶呱呱

from blog.

非常赞，简单、易懂。学习了如何从零开始构建适合业务的解决方案

from blog.

我震惊了！ 默默回首再看一遍。。。

from blog.

重新看了一遍，确实是干货好文。

from blog.

看完一遍留言，收益颇多，给了我一个方向，马上再来第二遍回味下，然后实践起来了

from blog.

👍 虽然只看到一半，先评论再看。

from blog.

评论里都放干货，过分了龙哥

from blog.

可以。。。

from blog.

本鸟已嚼文3遍

from blog.

想问个很菜的问题，开发目录与部署目录分离之后，开始的时候没法看到效果，必须等构建完成后才能看到效果，构建期间要等，哪怕构建很快也是有个时间差问题，大家是怎么解决这个构建时间问题的？

from blog.

既然已经是部署和开发了，想看效果可以在开发目录里看，不需要每次都看部署的效果吧

发自我的 iPhone

在 2015年2月1日，下午12:29，liulangxiong [email protected] 写道：

想问个很菜的问题，开发目录与部署目录分离之后，开始的时候没法看到效果，必须等构建完成后才能看到效果，构建期间要等，哪怕构建很快也是有个时间差问题，大家是怎么解决这个构建时间问题的？

—
Reply to this email directly or view it on GitHub.

from blog.

@liulangxiong 有缓存，再次构建只会处理和改动文件相关的文件。

from blog.

拜读了，满分的好文啊，给了非常多的启示！！！

from blog.

又读了一遍, 每回都有更深的感受.

from blog.