前端开发环境过滤器
更新日期:
作为一个前端，经常被各种环境困扰。古人说穷则变变则通。最近实在是忍受不了之前开发环境的总总弊端，下定决心好好整了整。
那些年被虐待的经历
鄙人公司目前后端开发还是主要以java为主，使用的是spring的架构。之前的开发情况是，前端切好静态页面，给开发去套vm。
显然这是一种特别效率低下的事情。开发其实很多时候不能理解我们的html结构，所以多数时候我们得跑到开发旁边，一起改vm。
后来开发说了，他们不管vm了，让我们写。好啊，我们写还自由点。可是我还是too young too simple。写vm，我们只能在本地跑java环境，这个包，那个包。这个依赖，那个依赖。经常是开发svn升级了一个包，我们这边就跑不起来环境了，然后又是各种找开发来帮忙整环境，苦不开言。这里深深鄙视下java，大部分时间都花在打包还有环境调试上了。
再后来我们想了个办法，嗯，有那种持续集成环境，就是一个线上虚拟机。我们不用本地跑vm了。不过问题依旧，经常性的环境挂掉。而且最大的问题是每次svn改了vm。都要去发布下。
再后来不能忍了，团队的大牛推荐了vagrant。可以本地跑虚拟机，采用分发的方式。开发跑vagrant。然后打包发给我们，这样环境就一模一样。而且是本地虚拟机，所以改了vm立马生效。听起来很美好，可是再次证明现实很骨感，环境还是经常性的挂掉，因为开发用的windows，而我们vagrant里面的跑的linux，还是不少差别。在开发帮忙调试了几次环境后，发现问题依旧。也越来越懒得帮我们看环境了。
再后来，又回到了原始的境地，前端跑到开发旁边调vm。调js。
忍无可忍无需再忍
就这样，我们一直忍受着这种开发模式。因为nodejs如今如火如荼的进行着，而公司内部各个bu都在考虑用node做前后端分离，我们一直期待着有一天，把view层抽出来。这样就不用再跑java环境了。java只提供http数据接口。整个渲染层交给node，由我们自己把控。还可以自己模拟数据。
想想还是有点小激动呢。
但是。。。现实还是再一次拍死了我们。因为开发，运维对node还是有点抵触的：
- 认为这么新的东西。稳定性没有保障。
- 而且vm用的好好的，干啥要换。使用了node中间层反而增加了前端的工作量，本来就资源不够了。
- 对开发其实并没有特别的好处，只是方便了前端把控环境。
于是在我们老大跟他们讨论了几次后，node中间层一直在做ing。嗯，这个做的过程不知道要持续多久。
作为小p，推动不了这么大的全局性的改变。但是环境问题真的受！够！了！
偶然的情况下发现了velocityjs这个项目。于是想着完全可以用node来模拟java环境嘛，把vm跑起来不就好了。
说干就干，于是在后来一个比较小的模板展示的项目里，使用express搭建了一套环境。把vm跑起来了。并且vm上面的那些变量都是我们自己使用json模拟。
于是我们终于解脱了，不再需要跑java环境，还可以脱离java。把功能完全写好，各个逻辑都使用模拟数据验证完，然后跟开发联调基本就是分分种的事。
想的更多点
虽然我们在小的项目里尝试了。但是对于比较复杂的项目，还是觉得整体改造比较困难。后来商量了下，其实可以做一个命令行工具。进行一些简单的配置就可以把vm跑起来。没错感觉就是个启动服务的工具了。
其实除了vm渲染的问题，我们还面对不少困难。
- 本地静态服务，之前都是本地起一个nginx。来新人了，都得教半天配置。另外线上的静态资源有时是支持combo的。我们跑vm的时候都得把combo的资源人肉切分。
- 项目一般都是使用less编写。开发的时候需要使用gulp跑一个watch，或者使用koala这种工具。
- ajax请求无法模拟，做静态页面的时候。都是自己写个简单的php脚本，打出一些简单的数据，来模拟。
- 在线上环境调试时，不方便。线上引用的都是压缩的文件。虽然可以通过url变量控制引用不压缩的。但是修改代码的时候，还是需要本地改好，打包发cdn，一看效果不对又要回滚。后来想到用reres来映射线上js到本地。可是combo的资源映射起来就难办了。另外我们前端使用了一种打包技术，将html模板打包到js里面，所以直接映射js就少了模板。总之一直是一个头两个大。
总体来说，我们的环境太零散，太凌乱。用起来也是各种困难。
所以想着能不能搞个工具解决所有这些问题呢？
正好那段时间一直在玩koa。突然发现koa天生适合解决这个问题。于是说干就敢，制作了qfilter这个工具。
说白了使用koa开一个本地服务命令行工具：
- 开发一个静态资源中间件用来处理js，css，html请求，支持combo。
- 开发一个vm中间件，当请求是vm模板时就使用velocityjs渲染vm后返回。
- 开发一个ajax中间件，处理所有的ajax请求。
- 开发一个rewrite中间件来改写请求的url。
- 开发一个less中间件实时编译less。
我们看上面说的：
第一个问题，静态资源中间件就解决了。
第二个问题，先使用rewrite中间件来改写请求的路径url，把css的请求映射到对应的less文件，并且到下一个less中间件时实时编译返回的内容返回。性能上并没有啥大问题。
第三个问题，ajax中间件搞定，只需要指定个目录，写一些模拟数据就好了。
第四个问题，因为通过上面的一系列中间件，可以使本地环境跟线上环境一模一样。我们只需要使用switchsharp这种代理软件把线上的js请求都映射到本地的服务，线上的css请求会映射到本地服务，本地服务再请求对应的less，再实时编译返回。线上的combojs请求，映射到本地服务，本地服务自动分割合并不同的js返回给浏览器。并且是立即修改，立即生效，调试变得异常简单。
整体上的思路，就是线上线下的页面都是一样的，线上请求什么，线下开发也是一样的。但是请求过来了，返回什么内容是本地服务说了算，请求css，我映射到对应的less并且编译返回。请求vm，我渲染后再返回。只不过线上是直接请求的打包生成好的css。请求的也是java渲染好的vm。而这些本地的服务都能百分百模拟。
于是前端开发的时候，不需要跑java环境了，如果前面的人配置好了各个参数。新人只需要跑到环境根目录下运行 qf s 于是世界清静了。所有的环境都在这一行命令行里面了。环境不再碎片化。而且线上线下一套环境，无缝切换。调试也更加简单。解放了大量的劳动力。
最终产出了这个基于koa的工具 qfilter
结语
任何事情，不要期望着未来遥远的解决方案，与其等遥远的阳光，还不如先想办法解决当前寒冷的问题。将来node中间件必将彻底解决环境问题，解决前后端分离问题。其实我这种反而是旁门左道了，但是我觉得解决问题才是最重要的。更何况，其实qfilter不只是解决了vm的渲染问题了。