前端项⽬结构设计精细⽅案
开始的开始，前端项⽬很简单，html放外⾯，然后新建⼀个css和js⽂件夹，看起来很清晰。
随着时间推进，项⽬变⼤，问题开始⼀⼀出现了：
html 太多，起来⿇烦
css 和 js 需要压缩
css 和 js需要发布到 CDN
开始只简单依赖⼀个jQuery，后来发现依赖的插件越来越多，不好更新维护
html ⾥⾯怎么实现公共⼀个头
js和css包含⼤量重复代码，怎么重构项⽬
前端如何把代码交付给后端填模板代码
很多公司⾯对这些问题都有了⾃⼰的⽅案，Node 因为语⾔也是JS，成了很多公司的⾸选。
相关的热门框架有grunt,gulp,webpack,bower等等。
愿意读⽂档的⼈早以⽤上这些新奇玩意⼉并且解决了⼤量前端问题。
虽然⼯具很多，但对于很多新团队来说，如何完美地规划项⽬却仍然是⼀道坎。
他们不知道应该在何时，如何使⽤这些⼯具。前端项⽬的设计可以⾮常随意，正是这些随意，让很多⼈在选择中开始迷茫。
本⽂将提供⼀个趋于完美的前端项⽬结构规划⽅案，希望能为各位在重构前端项⽬时提供帮助。
⼀个规划⽅案，并不只是定义⽂件怎么放，⽂件怎么命名，⽽更重要的是包含实现整个流程的⼯具，如果没有⼯具⽀持，所有⽅案都是扯淡。
前端项⽬结构
根⽬录
|- assets:  存放所有js和css等，这些资源可能发布到 CDN
|  |- images: 存放所有 CSS 样式需要的背景图⽚
|  |- fonts: 存放所有 CSS 样式需要的字体
|  |- styles: 存放所有CSS
|  |  |- common: 存放公共的 CSS 代码
|  |- scripts: 存放所有 JS
|  |  |- common: 存放公共的 JS 代码
|- include:  存放所有公共的 HTML 头尾⽚段
|- images:  存放前景图⽚和flash
|- libs:  存放前端所需的第三⽅类库
|- views:  如果使⽤了后端 MVC 框架，则页⾯放在这⾥。
|- _my:  存放开发者⾃⼰需要的⽂件，这个⽂件夹应该被 GIT 和 SVN 忽略掉。
|- page1.html 存放最终的前端页⾯，如果使⽤了 MVC 框架则不需要。
HTML ⽂档结构
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>标题</title>
<!-- #include virtual="/include/header.inc" -->
<link rel="stylesheet" type="text/css" href="assets/styles/common/blog.css"/>
<link rel="stylesheet" type="text/css" href="assets/styles/page2.css"/>
</head>
<body>
<!-- #include virtual="/include/body.inc" -->
内容
<!-- #include virtual="/include/footer.inc" -->
<script type="text/javascript" src="assets/scripts/common/blog.js"></script>
<script type="text/javascript" src="assets/scripts/page2.js"></script>
<!-- #include virtual="/include/stat.inc" -->
</body>
</html>
/include/header.inc:
<meta http-equiv="X-UA-Compatible" content="IE=edge, chrome=1"/>
<meta name="viewport" content="width=device-width, initial-scale=1, minimal-ui, maximum-scale=1, user-scalable=no"/>
<meta name="apple-itunes-app" content="app-id, app-argument=">
<meta name="description" content=""/>
<meta name="keywords" content=""/>
<link rel="search" type="application/opensearchdescription+xml" href="/l" title=""/>
<link rel="shortcut icon" href="favicon.ico"/>
<link rel="apple-touch-icon" href="favicon.png">
<link rel="stylesheet" type="text/css" href="../assets/styles/common/common.css"/>
/include/body.inc:
这⾥可以放⼀些全站公⽤的页头，⽐如需要为全站加⼀个紧急通知的 banner，可以加在这⾥。
<!--[if lt IE 9]>
<div role="alert">你的浏览器实在<strong>太太太太太太旧了</strong>，放学别⾛，升级完浏览器再说 <a target="_blank" class="alert-link" href="browsehappy">⽴即升级</a>
</div>
<![endif]-->
/include/footer.inc:
这⾥可以放⼀些全站公⽤的页脚，⽐如版权声明之类。
<div>版权所有 @copy; 2015 xuld</div>
前端页面模板<script type="text/javascript" src="assets/scripts/common/common.js"></script>
/include/stat.inc:
这⾥可以放⼀些⽹站统计代码。
<!-- 在这⾥添加⽹站统计代码 -->
其它⽂件
如果项⽬⾥还有公共的侧边栏、⼴告位等，也可以⾃⾏在 include 添加其它⽂件。
如果⼀个⽹站需要有多种不同版权声明，可以分别做⼀个 footer-full.inc 和 footer-simple.inc，然后公共包含：footer-common.inc。
静态资源引⽤
如果项⽬⾥需要使⽤ less/sass/coffee 等技术，则可以直接引⽤这些⽂件。发布时，发布⼯具完成这些事情：
1. 编译 less/sass/coffee ⽂件，转换为对应的 css/js ⽂件。
2. 更新 HTML ⽂件⾥的资源引⽤地址，引⽤⽣成好的 css/js ⽂件。
3. 为这些资源⽂件引⽤地址添加时间戳。
4. 如果项⽬使⽤了 CDN，则发布⼯具应该⾃动上传⽂件到 CDN，并更改⽂件⾥的路径为 CDN 的地址。
发布前：
<link rel="stylesheet" type="text/css" href="../assets/styles/page1.less"/>
发布后：
<link rel="stylesheet" type="text/css" href="cdn/project/assets/styles/page1.css?_=md5"/>
时间戳问题
静态⽂件由于存在缓存，每次发布如果保持路径不变，很容易导致页⾯不更新。有三种⽅案：
1. 为路径加上 ?_=md5
2. 更新⽂件名为 page1_md5.js
3. 复制到名为 20151021 的⽂件夹
个⼈建议使⽤⽅案1，因为改动量少，不易出错。但如果CDN不⽀持，可以采⽤其它⽅案。
脚本和样式
如果项⽬中，⼀个⼈专门负责 css,⼀个⼈专门负责 js,⼀个⼈专门负责将 html 转换为后台代码，则上述⽂件夹结构是⽐较合理的。
如果是同⼀个⼈负责css和js，则建议不区分 styles 和 scripts ⽂件夹，直接放在 assets ⽬录。
如果连转换html 到后台代码都是同⼀个⼈，则建议将 css 和 js 直接写在页⾯⾥，发布⼯具负责提取出来：
<style __dest="assets/styles/page1.css">
/*  CSS 代码 */
</style>
公共代码依赖
每个HTML页⾯，都必须引3个js和3个css，分别是：
全站公⽤的 js：common/common.js
全项⽬（或类似页⾯，⽐如列表页、详情页）公⽤的js：common/blog.js
页⾯私有的js：common/page1.js
css 和 js处理⽅式⼀致，且⼀⼀对应。
个别页⾯可以引⼊⼀些外部的js和css，⽐如 editor.js 这种⽐较⼤的⽂件。但原则上每个⽂件最多只能引 5个js和5个css。需要引的⽂件多时则需要打包合并。
出于性能考虑，有时候可以将页⾯私有的js和css直接内联到页⾯。
<script src="assets/page1.js?__inline"></script>
模块化组件
所有可复⽤组件、第三⽅框架都放在 libs，libs ⽂件发布时会被忽略掉，项⽬⾥也不能直接引⽤ libs 下的代码。
如果需要引⽤⼀个组件，有三种⽅案：
简单的⽂件包含
基于 CommonJS 模块化⽅案
基于其它模块化⽅案
简单的⽂件包含
如果项⽬较⼩，并不需要太⼤模块化东西，直接使⽤⽂件包含是最⽅便的：
common.js
// #include /libs/3rdlibs/jquery-2.1.0.js
// #include /libs/bile.js
// 其它项⽬需要的公共代码
发布⼯具会处理 #include 。
CommonJS 模块化⽅案
var $ = require('libs/3rdlibs/jquery');
发布后，CommonJs 模块会被转换为标准的 AMD 模块。
打包问题
假设⼀个页⾯需要引⽤ common.js 和 page1.js ，⽽这2个js⼜分别引⽤了 libs 下的若⼲个组件（可能有重复）
那么 page1.js 可以添加如下指令排除掉 common.js 所引⼊的⽂件
// #exclude common.js
var $ = require('libs/3rdlibs/jquery');
最后⽣成的代码，page1.js 将包含所有所需的模块，并删除了 common.js 包含的模块。
项⽬发布和调试
以上所介绍的代码⽅案是不能直接在浏览器运⾏的，这⾥有三个⽅案可以实现本⽂所描述的各个功能：
1. 在浏览器执⾏ JS 实现上⽂所描述的所有功能。优点：兼容性好，缺点：效率低。
2. 监听⽂件改变，⽂件保存后就解析以上指令并⽣成⽂件。优点：兼容性好，处理⽅便，缺点：不稳定。
3. ⾃定义服务器，这个服务器在请求时⾃动完成⽣成任务。优点：效率⾼且稳定，缺点：需要定制服务器，且只在开发时使⽤。
其它⼯具⽀持
占位图
对应经常切页⾯的哥们，占位图是⾮常有⽤的。
<img src="@100x100.jpg">
Ajax 接⼝模拟
a.njs:
writeJsonp({
a: 1
});
写在最后
本⽂所描述的是⼀种建议的做法，也是⼀个发布⼯具所需要提供的功能。每个团队可以针对⾃⼰的需
求做⼀些个别的定制。本⽂所提到的⽰例都是以为原型书写的。不同的⼯具会有稍微不同的写法。但是其解决的问题是⼀样的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。