前几天刚刚重构了项目的组织结构。这是前端项目第二次在组织架构上发生重大变化。这也是一个“按类型文件夹”到“按功能文件夹”的过程。为什么会有这个过程？因为感觉项目越来越大，每次修改一个地方可能要打开三四个文件，比如一个页面修改哪里。然后首先是页面的HTML，然后是Controller，Less，接口对应的服务文件等等，整个工程都是我自己搭建的，可能不会有什么问题。找的时候只需要回忆一下对应的文件就可以了，但是如果有新成员加入进来，难免会有遗漏，因为他也很难判断一个页面的本地改动涉及到哪些文件。一开始项目刚建的时候，也就是只有一页，项目是按照文件类型来组织的。但是，随着项目的庞大规模和各方面的影响，渐渐地，按类型划分就成了一种责任不明的感觉。项目一开始的结构大概是这样的，太具体记不住了，大概是这样的：--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划分的。因为有了AngularSPA，基本上一个Controller对应一个子页面，然后把所有的js和less合并压缩，加载到index页面。当然，还做了一些更细化的工作，这里只是说说看一下项目的原型。接下来做了哪些改变？与其说接下来做了什么改变，不如说是什么促使我们做出改变。说到这里，我们就转移一个话题，什么是稳定好的文件组织结构，我现在的一个定义是“稳健、包容”。当事情发生变化时，您当前的组织结构可以很容易地改变适应新变化的小成本，而不是对整个项目的重大变化，甚至涉及代码。当原型完成后，项目一天比一天大，有两个任务进入了流程要考虑。一个是关于项目构建的自动化，包括库文件的管理、库之间的依赖关系、代码的压缩与合并等，还有静态资源的版本号、开发模式和发布模式下不同的代码构建等。另一个问题是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文??件夹，然后有details、new、edit等页面和对应的其他文件。因此，基于良好的URL设计，我们需要一个语义化的组织文件结构。项目的自动化构建是如何涉及到文件结构的？每个小话题感觉都可以引出一些细化和深入的东西，项目自动化构建解决什么问题？这解决了许多问题，但AngularSPA有两个主要要求。一种是整合静态资源，比如合并、压缩，发布时使用带有版本号的静态资源。一种是在开发过程中重新编译了一些Less文件和JS文件，页面自动刷新等，简单来说，一个是发布，一个是开发，为了让这两个步骤更加方便有序，做了一些努力。在以上过程中，无论是开发还是发布，都会生成很多构建文件。它还会影响您对项目目录和文件组织的调整。新建项目结构的每一次修改都涉及到项目的方方面面，非常复杂。随着项目越来越大，这种改造的成本也会越来越高。越来越高了，所以尽快确定一个好的结构是非常迫切的。先给出当前期的结构：大致说一下现在怎么划分，因为是SPA，所以必须有一个index.html作为页面加载器，app。js是angular的主文件，app.less是所有Less文件的入口。components是angular的各个组件，包括common、services、directives、filters、router、run.js（这里主要是放置一些需要随App代码一起启动运行的，比如插件初始化配置，以及类似路由监听和处理事件等）。一个子页面按照功能模块划分模块，对应的Controller的JS文件和Less的CSS文件都在一个文件夹下。所有的内容都是生成的。我结合使用Bower和Gulp来自动构建项目。这样目录结构就清晰了，把公共的部分分到一起，把每个页面对应的相关文件整理到一起，然后再按照功能来排列和划分。这样在维护的时候很容易找到需要修改的相关文件。同事日常开发和项目发布都是用build里面的文件，开发和发布对应的是两套不同的文件，所以感觉整个项目就清爽多了。项目建设之路不止于此。限于篇幅，很多东西还是不能放在一起说清楚，比如Controller的职责划分，服务的结构，Bower和Gulp是如何配合完成项目构建的。这些可能以后再讨论，在Github上留个架子，有兴趣的可以留言。虽然觉得有很多地方不太清楚，但是关于组织架构，也就差不多了。只是项目建设的路漫漫其修远兮，***我还有话要跟大家分享。该项目的建设只能说已经完成了初级阶段。如果再好一点，也算是中等水平了。那么应该有一个进阶或者***目标。Angular是一组框架而不是库。它给了我们很大的发挥空间。从目前的情况来看，还是有需要改进的地方。我总结了几点。当然，这几点对于大部分项目都是适用的：各个部分之间的耦合程度，是否要做深度解耦。是不是Controller的责任太大了，不仅仅是业务，很多乱七八糟的东西丢到Controller里面，导致形成了‘超级控制器’。是不是有些公共的东西没有提取出来，还在重复复制代码。MVVC的概念，你有没有发现你在angular.m中没有M的概念。用面向对象的思想看架构和代码，有没有职责单一，开放和封闭。其实还有很多需要改进的地方，我一直在慢慢整理。可以说，一个比较完整的货架有两个最突出的特点之一。一是结构清晰，易于维护，因为每个部分职责单一，为修改而封闭，为扩展而开发。另一个特点是开发效率极高，大量内容被抽象出来公开。组件，70%的代码都写好了，只写业务部分。如果还有一个很重要的原因让我们孜孜不倦地改进结构，那就是在项目越来越大的时候阻止有效的维护。我个人觉得这是最重要的一点，就是通过清晰的代码和结构来降低维护成本。成本。原文来自：http://my.oschina.net/blogshi/blog/322883
