前几天刚刚把项目的组织结构进行了一次重构,这是前端项目至今第二次进行组织结构上大的变化,也是一个"folder by type"到"folder by feature"的过程.

为什么有这个过程

因为感觉到项目的日益庞大,每次修改一个地方我可能要打开三四个文件,比如说一个页面上的哪里要修改.那么首先是页面的HTML,然后是Controller,Less,对应接口的service文件等等.整个项目是我一手构建的可能还不会出问题,只是找的时候要回想一下对应的文件,但是如果一个新的成员加入进来,不免就有些疏漏,因为他也很难确定一个页面上的局部变动,到底要涉及到哪些文件.

最开始在项目刚刚构建的时候,也就是只有一个页面的,就开始按照文件类型进行项目的组织.不过随着项目的庞大,以及各方面其他的影响,逐渐,按照type进行划分已经出现了职责不清晰的感觉.

希望你喜欢，并分享我的工作~带你走近AngularJS系列：

最开始项目的结构大概是这样,太具体的有点记不清了,大概是这样的:

-- static
-- js
-- app.js
-- routers.js
-- services.js
-- directive.js
-- filter.js
-- controllers
-- userController.js
-- someModule.js
-- less
-- index.less
-- user.less
-- someModule.less
-- build
-- all.2014090901.js
-- all.2014090901.css
-- templtes
-- index.html
-- user.html

基本结构就是按照功能对Controller进行划分了,因为做的Angular SPA所以基本上一个Controller对应一个子页面,然后将所有的js以及less合并压缩出来,在index页面加载.当然其实还做了一些更细致的工作,这里只是说一下项目的雏形.

接下来都做了哪些改变

与其说接下来做了哪些改变,不如说一下有哪些东西促进了我们要进行改变.说到这在岔开一个话题,什么叫做稳定良好的文件组织结构,一个我现在下的定义就是"健壮并包容".当一个东西发生变化的时候,你当前的组织结构能够以很小的代价去适应新的变化,而不是整个项目大改特改,甚至牵连到代码.

当雏形完成后,项目日益增大,有两个task进入了要考虑的流程.一个是关于项目的自动化构建,包括是库文件的管理,库之间的依赖关系,代码的压缩合并等,还有静态资源的版本号,开发模式和发布模式下不同代码构建等等.另一个问题就是URL的设计,怎么和文件的组织结构保持高度统一.

这两个问题都比较杂,先说URL的设计吧.

关于"好的URL设计"的定义有好几条,可以自行百度,我不打算抄袭百度百科了.只谈我认为最重要的就是对用户的友好,什么叫URL对用户的友好呢 说白了就是让你的URL一看就懂,一猜一个准.我认为这样设计就可以了,可能你会说了谁会无聊到去记住URL地址呢,想要以后访问收藏一下就可以了.

这个我没什么兴趣去反驳,不过你怎么看不见百度或者淘宝的网站将地址设计为"www.baidu.com/hsakudhkajshdgjasgdjhsgfjhsagfjhsdgfjhasgfj786347823yuisbhdufy".

URL的语义化很大程度上表达了对用户的友好.比如我现在"/restaurant","/restaurant/new","/restaurant/2","/restaurant/2/edit"这几个URL对应的页面分别是:

餐厅页面(列表数据),新建餐厅页面,餐厅id为2的餐厅页面,餐厅id为2的餐厅编辑页面.

很容易猜到不是吗,将2改为其他对应的id也能访问到指定的餐厅页面.这个URL映射关系从结构上说就应该与我们的文件夹结构对应,也就是应该有一个restaurant文件夹,然后里面有详情,新建,编辑等页面以及对应的其他文件.所以基于良好的URL设计,我们是需要一个符合语义的组织文件结构的.

项目的自动化构建怎么牵扯到文件结构

每个小话题感觉都能引出一些详细的深入的东西,项目自动化构建为了解决什么问题 这个解决了很多问题,但是对于一个Angular SPA来讲主要有两个需求.一个是将静态资源合的整合,比如合并压缩,发布时使用带有版本号的静态资源.另一个是开发过程中的一些Less文件以及JS文件的重新编译,页面自动刷新等.

简单说一是为了发布,一是为了开发,为这两个步骤更加便捷有序做出一些努力.

在上面的过程中,不管是开发还是发布,都会生成很多build出来的文件,这也会影响到你对项目目录和文件组织的调整.