我我的的前端开发技术路线变化图（下）

写这种综述性质的文章是很是耗时的，连续写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。

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

--app |--system_module | |--main.js | |--thirdparty_js | | |--jquery | | |--backbone | | |--underscore | | |--sea | |--css |--moduleA | |--js | |--css |--moduleB | |--js | |--css

这套机制一开始运行的很好。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都在一块儿，你还不敢删，谁知道删了会不会出错？因此，不得不说以前的目录结构并不是一个好的目录结构。如今我推荐的改进目录结构是下面这个样子：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

--src    |--lib(thirdParty)    |   |--moduleA    |   |    |--js    |   |    |--css    |   |    |--subModuleC    |   |    |   |--moduleB    |      |--common    |   |--moduleC    |   |--moduleD    |-system    |   |--moduleE    |   |--moduleF    |   |--moduleG

这种目录结构将第三方模块和通用模块、逻辑模块划分开，每类中再建子模块。其实这就是典型的服务器端框架目录划分。这种目录结构适合在开发时使用，在部署的时候经过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开发模型终于完成：

 

新技术老是层出不穷，要遇上必须保持一颗永不磨灭的好奇心。哪怕是之后不作前端开发，咱们已经享受了求知的过程。就像下面这个图同样，这就是人生。