目前很多网站基本没有明确的前端架构，大多是服务端渲染视图页，输出到浏览器，再配合一些js，来进行交互。

如果只是实现一些简单的效果，没有较复杂的逻辑，那么这种处理是合理的， 尤其是有了jQuery之类的利器，js代码写起来甚至有种随心所欲的感觉。

但一旦网站要改版，或者随着网站的发展，逻辑变得越来越复杂，或者为了更好的用户体验， js要承担更多的任务，这时如果维持现状不变，那js就会变得越来越臃肿，越来越难维护。

解决之道就是采用模块化编程，将页面分成多个模块，模块之间互相独立， 通过发布/订阅方式来进行模块间交互，从而使模块与模块解耦，也就是说移除一个模块不会对当前页面造成影响。

配合模板的话，可以让前端和后端程序员更高效地配合。 前端只负责数据的显示与页面的交互，开发时，可以拟造数据，而不需要服务端程序。 后端程序员也可以专注于提供更易用，稳定的接口，而不需要关心数据的展示。

yahoo的这个视频详细地阐述了前端模块化编程，大致摘录如下：

js架构的4个组成部分

• 模块(Modules)
• 沙箱(Sandbox)
• 应用(App Core)
• 类库(Base Lib)

模块就像孩子一样，他们需要遵守一些规则才能保证不会到处惹麻烦

模块必须在沙箱里，无论条件多么苛刻

模块不知道页面到底是怎样的，他们只知道沙箱

模块之间要解耦

模块的规则

• 管好自己

  • 只能调用自己的或沙箱的方法
  • 不要访问不属于自己的DOM节点
  • 不要访问非内置全局变量

• 先申请，再使用

  • 你需要的任何东西，要向沙箱提出申请

• 不要把玩具放得到处都是

  • 不要创建全局变量

• 不要和陌生人说话

  • 不要直接引用其他模块

沙箱要保证接口的一致性，模块调用时一定要有

模块只知道沙箱，其他的架构对模块而言是不存在的

沙箱就像一个安保员，知道哪些是模块可以调用的

沙箱的职责

...

1.DRY

DRY 是一个最简单的法则，也是最容易被理解的。 但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力， 这并不是一件容易的事）。

它意味着，当我们在两个或多个地方发现一些相似的代码的时候， 我们需要把他们的共性抽象出来，形成一个唯一的新方法，并且改变现有的代码， 让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程界中最通用的法则了。 目前为止，应该没有哪个程序员对这一法则存有异议。 但是，我们却能发现，一些程序在编写单元测试时忘记了这一法则： 让我们想象一下，当你改变一个类的若干接口，如果你没有使用DRY， 那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。

比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法， 而是每个test case自己去构造类的实例，那么， 当类的构造函数被改变时，你需要修改多少个test cases啊。 这就是不使用DRY法则所带来的恶果。

2.短小的方法

至少，我们有下面三个不错的理由要求程序员们写下短小的方法。

• 代码会变得更容易阅读。

• 代码会变得更容易重用（短方法可以减少代码间的耦合程度）

• 代码会变得更容易测试。

3.良好的命名规范

使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护， 当一个类，一个函数，一个变量的名字达到了那种可以“望文生义”的境界时， 我们就可以少一些文档，少一些沟通。

4.赋予每个类正确的职责

一个类，一个职责，这类规则可以参考一下类的SOLID...

浏览器是我们最常用的软件之一，文本又是网页中最主要的元素， 在浏览器显示文本的过程中有许多有趣的细节，值得展开来讲讲，或许能减少一些误解。

这是一个比较粗略的，概括性的介绍，尽可能不涉及过多的技术细节和具体实现，而立足于给 Web 开发者和设计师提供一些正确的概念。

下面的介绍主要根据我对 WebKit 和 Gecko (Firefox) 的印象来谈，其他的浏览器也大致相同，如有阙漏之处欢迎指出。

解码

当浏览器收到来自 Web 服务器的网页数据之后， 第一步是要把它解码成可以阅读的文本，因为历史原因，不同区域和语言的网页可能会使用不同的编码方式，而浏览器判断编码主要是依据以下方法：

• Web 服务器返回的 HTTP 头中的 Content-Type: text/html; charset= 信息， 这一般有最高的优先级；
• 网页本身 meta header 中的 Content-Type 信息的 charset 部分， 对于 HTTP 头未指定编码或者本地文件，一般是这么判断；
• 假如前两条都没有找到，浏览器菜单里一般允许用户强制指定编码；
• 部分浏览器 (比如 Firefox) 可以选择编码自动检测功能， 使用 基于统计的方法 判断未定编码。
...

1 配置git身份信息

git config --global user.name "abc" git config --global user.email "abc@email.com"

2 下载项目代码

在工作目录下，比如 D:/work/

git clone root@abc.com:~/web/projectname

即可在 D:/work/projectname目录下生成一份projectname工程代码

3 目录切换到D:/work/projectname 更新代码至最新版本

git pull root@abc.com:~/web/projectname test

我们的最新代码都会提交到版本库的某个分支上面，所以要从分支pull最新的代码下来

4 修改代码以后，查看改了哪些东西

git status

5 提交修改的代码到本地版本库

通常用户看到的页面的样式(css)会受到三层控制:

1. 第一层是浏览器的默认样式;
2. 第二层是网页定义样式;
3. 第三层是用户自定义样式.

和CSS一样，后面的优先级高于前面的，也就是说网页定义样式可以覆盖浏览器的默认样式， 而用户自定义样式优先级最高。

实际情况是虽然浏览器都或多或少提供了用户自定义样式的功能， 但是极少数会有用户去自定义，一般用也是高级用户。

而浏览器默认的样式往往在不同的浏览器、不同的语言版本甚至不同的系统版本都有不同的设置， 这就导致如果直接利用默认样式的页面在各个浏览器下显示非常不一致， 于是就有了类似 YUI的reset 之类用来尽量重写浏览器的默认设置保证各个浏览器样式一致性的做法。

拿字体来说，各个浏览器默认的字体种类、字体大小和字体行高都不一样， 比如IE8的中文版在Windows XP下显示网页时默认字体是宋体，而英文版肯定不会如此。 所以我们需要统一设置默认的字体样式，以便实现一致的显示效果来保证设计的一致性和提高开发效率。

以后准备使用如下默认字体样式：

body{ font: 12px/1.5 arial; } 

字体：arial

我们页面的绝大部分内容字符都是中文， 毫无疑问目前为止在网页上最常用也是最通用的显示中文的字体是宋体， 但是宋体在显示英文、数字和英文符号时过于糟糕，比如?字符， 所以我们一般期望通过CSS来实现用更好的字体样式来显示它们，然后用宋体来显示中文和中文符号。

之所以选择arial是因为：

• Windows和Mac都预装了这款字体，应该是使用最广泛的网页字体了。 它的潜在对手tahoma和helvetica就没有这么幸运了。

• 视觉设计的专业人士可能会认为在Windows中使用tahoma、在Mac中使用helvetica更好， 比如淘宝的默认字体样式是font: 12px/1 Tahoma, Helvetica, Arial, "\5b8b\4f53", sans-serif; 这是一个很不错的选择，但是你也会发现Google、YAHOO、Youtube、Bing甚至MSN的新版都 使用arial作为第一默认字体。 所以从美观和可读性上来讲arial应该是完全可以接受的。

• 一般情况下设置font-family都会在最后设置通用字体族以保证其安全性， 比如Google的设置为 font-family:arial,sans-serif; 但是至少在非中文版的Win7下当编码是GBK时，IE8会因sans-serif来渲染宋体，...