截止目前为止，自己开发过不下十款小程序。算是有些经验，其实对于一个熟悉了前端开发的工程师，小程序的入门会非常简单，无非是要多熟悉些API和小程序的开发工具。本质上和写一个H5页面没有什么区别。

阅读剩余部分 ->

建立可视化分析统计可以帮助我们更好的理解webpack。我们可以很容易地从构建结果那里得到的统计数据，我们可以使用一个工具来可视化这些数据，可以分析我们程序包的组成。

阅读剩余部分 ->

作为开发，不仅仅是前端，优化总是你绕不开的事，我们的目标就是要产品变得更快。优化的对象不仅仅指产品本身，还有我们日常的开发流程。从加入团队到现在，大概有一半左右的时间花在了优化上，期间遇到了很多问题，回过头看，优化这件事情并不是那么简单，也是些很琐碎的事情，要打造一个无痛的开发流程，并且能够相对轻松的对产品持续优化真的不轻松。没有银弹，任何项目都要花很多时间和精力。但任何值得改善的地方能够有所提升都让我们觉得努力没白费。有时候只想懒一点，从枯燥的重复中解放出来。

阅读剩余部分 ->

当FIS满足不了业务的特殊需求的时候，就需要定制化一些功能，按照官网的说明，可扩展的点有这么几个：

阅读剩余部分 ->

先来说说为什么要自动化。凡是要考虑到自动化时，你所做的工作必然是存在很多重复乏味的劳作，很有必要通过程序来完成这些任务。这样一来就可以解放生产力，将更多的精力和时间投入到更多有意义的事情上。随着前端开发不再是简单的作坊式作业，而成为一个复杂的工程时，还涉及到性能优化一系列工作等等，这时自动化已然是迫切的需求。

阅读剩余部分 ->

每次发版本都有个蛋疼的问题，同一个页面改版，不仅要保证发出去的页面不报错，而且得兼容现网的版本。最为传统的方法就是在资源文件后面加上一个随机参数xxx.js?t=1234，但即使是这样也无法保证拉回的xxx.js是新文件。最为安全的方法是将文件名改为新的。

面对多人开发、模块共用等问题，你会发现手动改文件名是一个非常搓的想法，程序员喜欢偷懒，这是天性。理想的状态可能是这样的：不需要去做多余的体力劳动，只需一个命令即可完成，从开发到提测，到最后的上线。

基于nodejs的构建工具还是比较多，诸如grunt，gulp，yeoman，fis等等。

经过一些日子的捣腾，现在FIS已经在团队跑起来了，完全避免了发版本的问题。但FIS带来的好处远不止这些，下一篇文章会讲到我是如何将FIS运用到项目中的，以及对性能优化带来的好处。各位看官，这次且随我看看FIS到底是个什么玩意儿。

阅读剩余部分 ->