首页 > 前端技术 > 我个人的前端开发技术路线变化图(下)
2013
11-03

我个人的前端开发技术路线变化图(下)

写这种综述性质的文章是非常耗时的,连续写4,5个小时还觉得没有写到位是很正常的事。然而要说写完一篇这样的文章就会有什么特别的斩获吗?要我看,其实也没多少,但一丝经验的积累,确实还是有的。所谓做事要有始有终,既然我已经决定要做一个表率,就必须坚持下去。我在没有什么观众的情况下坚持画画了那么久,何况现在所做的事有了几个同学、家长、甚至一些素昧谋面的网友的关注。任何一时的懈怠都是致命的。不为别人,只为我自己。

mega kill

接前篇,在2011年4月到10月间的MPX项目中我和侯振宇进行了自己的前端业务开发框架的研究与实践,继而意识到自己的薄弱和学习别人的重要性。于是在2011年11月开始的robin项目中,我们将我们的新思路运用了进去。robin项目是实验室有史以来最大的项目,是WFS云存储系统的2.0版,包含全新的前后台架构、界面设计、客户端支持。既然是云存储系统,考虑到对外接口的问题,那么后端必然是得采用我们已经多次实践过的restful架构来做,前端必然依旧是包含大量业务逻辑的重型前端。吸取了之前项目中自制的前端业务框架的经验教训,我们这次选择了多种开源框架和类库一起完成整个架构:sea.js做前端模块调度、underscore做前端模板、backbone来规范数据层和做数据与视图的绑定(前端MVC)、jquery做底层辅助类库,除此之外还稍微用了点flot.js、uploadify之类的功能类库做相应的功能。

于是,项目的目录大概像这个样子:每个模块文件夹中都包含其所属的js/css/html,所有模块平级存放。还有一个系统模块,它包含所有必需包含的主要类库和框架,以及负责总调度的业务逻辑main.js。

这套机制一开始运行的很好。2011年10月立项,11月开工,1月中旬演示版就出来了,整个设计+代码开发工作只花了不到3个月的时间就完成了预定的功能。值得一提的是,backbone并不是从一开始就加入的,而是11月下旬代码开发了一小半的时候才加入的。当时这类的前端MVC框架并不止backbone一种,但是当我们完成了原型后,意识到必须用一个框架来规范数据测层和做数据与视图的绑定时,backbone小巧精悍的特质吸引了我们,可以让我们很容易地把它加入到原型中且少做伤筋动骨的改变。此外,backbone捆绑销售的underscore实在是太好用了,甚至让我日后觉得它比backbone要强悍的多。虽然现在随着前端的大发展,Underscore的竞争对手越来越多越来越强大(比如lazy.js 和Lo-Dash),但是我依然对下划线抱有敢情。

的确,选择和学习这些框架都要成本,但这都值得。所有这一切都让前端变得重要起来。前端不仅体积越来越大,功能也越来越丰富,做了很多原来后台脚本语言才做的事。其实MVC、数据与视图绑定之类的东西,后端早玩烂了。如今,作为前端开发者,越来越需要了解后端的知识;同时,后台程序员也需要知道前端的基础——分为了两个工种是为了更有效率,而互相学习则是为了进一步提高。我想未来一个前端工程师如果不知道设计模式之类的东西,肯定只能在低层次的角色里混。

unstopedable

robin项目一开始其实运行的还好,截止2012年1月我们大家都还很满意。但是自从2012年3月以后,情况就不同了。但在不断地新加需求和修改bug中,系统原有的架构变得越来越混乱。这不仅体现在后台越来越多功能大同小异的API接口上,也反映在前端越来越混乱的目录层次上。我们的系统从一开始就不是一个能经受起不断变化的需求的架构,而且就以实验室的学生而言,精力也不允许我们在不断满足新需求的同时再进行重构。老板们都等着你赶紧提交新功能呢,结果你2个礼拜什么新功能都没做,就跟老板说你把代码重构了让结构更清晰云云,放在大公司人多也就罢了,一个实验室就这么两个能干活的人你给我说这个?!问题就积累的下来,但此乃人力之所限,不得已而为之。

就拿上面提到的这个前端文件目录来说吧,这种主从式的结构一开始看似还行,但是随着新功能的不断加入,就会有越来越多的第三方类库引入。例如一个显示树形列表的treejs库,你是放在system_module里面还是单独作为一个平级module来存放?既然treejs不是哪里都要用,那就作为平级module存放吧。最后结果,就是平级module越来越多,第三方类库的module与功能逻辑module混在一起,什么小虾小鱼甚至没用的module都在一起,你还不敢删,谁知道删了会不会出错?所以,不得不说之前的目录结构并非一个好的目录结构。现在我推荐的改进目录结构是下面这个样子:

这种目录结构将第三方模块和通用模块、逻辑模块划分开,每类中再建子模块。其实这就是典型的服务器端框架目录划分。这种目录结构适合在开发时使用,在部署的时候通过grunt等工具将css,js分别打包压缩分装到指定目录(通常另建build目录)。第三方模块最好不要直接使用,而是将其中有用的模块用grunt打包压缩到common下的指定目录去调用,这样可以避免第三方代码升级、修改第三方代码等问题带来的错误;同时通过逻辑模块中入口函数的调用参数的不同,很容易直到哪个是没人要的小鱼小虾,可以或删或改。通过gruntjs也可以很容易地分块测试逻辑模块。如果项目比较小,则可以化简一些,放大common模块的包含范围,不做src目录和build目录的区分即可。总而言之,这就是一个典型的前端学习后台进行目录划分的例子。

不过遗憾的是我没有时间和精力来把robin这么重构一遍了。只希望下个项目能尽量好一些。(哈,那时候我还会写代码吗,我的本职是写论文呀~)

《软件工程》一书一开始就指出,软件生命周期中最重要的阶段是设计、编码、测试和维护,其中维护要占1半以上的时间。我当时不理解,现在完全理解了。robin日后的维护从2012年3月一直持续到现在。新功能加了3次,各种定制版做了5回。可知折腾一个易于扩充易于修改的架构多么重要!

wicked sick

2012年9月底,我去新浪云事业部实习。每周在那边做三天,回实验室做2天。一开始也就做些小鱼小虾的活,后来越做越多,临走前几周更提了一个建议:前台采用angularjs作为开发框架。他们很快就接受了。因为他们也想做restful的整体架构,也需要前端有高效率的开发模式。

angularjs其实2012年4月我就开始用了,是侯振宇凭着自己对技术的敏感先发现然后推荐给我的。这跟我们使用backbone时候的种种不爽有关。虽然backbone小巧强悍,但是用它写的代码,还是少不了jquery等的配合,数据层和视图层之间的交互还是比较复杂。而2012年恰好是前端框架大爆发的一年,各路诸侯争先发布和升级了各种前端开发框架,并且batman.js, angular.js, ember.js , knockout.js等等,无一不与数据层和视图层之间的交互有关。MVVM架构成了时髦——我无意比较这些框架的好坏,我之前很多篇文章都有讲过了(前端框架的总结与推荐)。但我得说,这MVVM的框架用起来实在太舒服了,以至于一用它我就把backbone扔到脑后再也不想了。以至于从那时起我成了angularjs的坚定支持者。2012年11月到2013年1月我写了不少angularjs的代码。这段时间侯总也从后端转向了前端(我认识的很多后端程序员现在都很喜欢搞前端了,这是为毛?),他还帮助angularjs社区翻译angularjs的开发指南。后来侯总跟着我新浪实习所在的部门的人一起去搞创业公司unitedstack去了。一开始用得就是angularjs,直到2013年7月份换成avalon.js(他们真的很能折腾,很能重构,创业公司跟大学实验室区别太大了)。

monster kill

2013年3月到5月我蛰伏了一段时间考博。考完了以后一切生活依旧。不同的是我有幸主导了实验室新项目park的开发。该项目从产品层次来说是个典型的CRUD应用,故而我毫不犹豫地采用了grunt + boilerplate + angularjs + bootstrap + D3 + requirejs 的架构来实现它。本来我还想更激进一些,打算用nodejs做后端,搞express+nodejs+angularjs+mongoDB这么一套时髦的玩意。但是开发产品从来不是什么技术新就用什么,通常是新技术与旧基础之间的妥协。毕竟实验室的人员不是创业公司的员工,没有那么大的能力和精力来实践一套没用过的玩意。新技术一开始都要趟地雷的,没那个精力就别折腾。考虑到实验室传统上后台还是用php+mysql的方案,那么还是用老方案来吧。前端用angularjs. 新项目从2013年7月开始做,做到10月一期基本完成。还是restful架构,后台用php开发框架codeigniter,前端以angularjs为主。前端的相关内容,我已发4篇angularjs项目实战的文章来讲了。故而这里不做赘述。期间发现angularjs上手很快,但精通很难。事实上,它不适合js基础较为薄弱的人(例如把自己定位为修页面的前端工程师),反倒是后台程序员学它很快。期间种种,再撰文吧。

事实上,自2012年起,这前端就一直风起云涌,大量开发框架、设计思想层出不穷。nodejs更是包打天下,php能干的,我JS也全能干,还干的更多。让人觉得前端大有可为。我就想用js从头打到尾,用express+nodejs+angularjs就是实现这个理想的现成方案。除了这个方案,还有meteorjs这样的一站式前后台解决方案。我擦,ruby on rails的饭碗都要被抢啦!这有篇老外的文章:Why Meteor will kill Ruby on Rails 大家可以略作一观。

最后关于meteor,  这里引用一下侯总对meteor的介绍:Meteor是一个基于nodejs、webSocket、mongoDB的整体开发框架,在它的实现中,前后端的数据模型已经几乎没有差别。前端对数据模型进行任何改动,只要调用“save”方法,所有数据就自动存到服务器端的mongoDB中了——终于可以忘了主动发送请求给服务器,终于可以忘了服务器要和前端实现几乎一样的数据模型层。而任何前端“订阅的”后端数据出现改动,前端数据模型也会马上自动得到了更新——终于可以忘了主动轮询,终于可以忘了拿到后端数据再解析成前端模型。除了前后端模型的双向自动绑定,Meteor同时还实现了数据到前端模板的自动更新。 不过,Meteor的模板在处理视图到模型的改动时扩展性不如AngularJS。因此,将AngularJS和meteor结合是最好的选择。到这里,快速Web开发模型终于完成:

 

新技术总是层出不穷,要赶上必须保持一颗永不磨灭的好奇心。哪怕是以后不做前端开发,我们已经享受了求知的过程。就像下面这个图一样,这就是人生。

男人的一生


我个人的前端开发技术路线变化图(下)》有 1 条评论

留下一个回复

你的email不会被公开。