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

写这种综述性质的文章是非常耗时的，连续写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开发模型终于完成：

 

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

转载于:https://www.cnblogs.com/zhangdi/p/4026335.html